Responsive Tabs with one consistent API

WHAT THIS TESTS The interviewer checks whether you can hide implementation variance behind a stable interface, a core design-system skill. The trap is leaking the responsive complexity to consumers.

A GOOD ANSWER COVERS Define one public API: a list of tab items, a selected value, and an onChange callback, modeled as a controlled component with a single source of truth for selection. Internally, detect the environment with a breakpoint or media query (or a capability like touch) and render the appropriate presentation: a horizontal tab bar with keyboard arrow navigation on desktop, and a swipeable, paged view with snap on mobile. Both presentations read and write the same selection state, so switching viewport sizes keeps the active tab correct. Factor shared concerns, accessibility roles like tablist/tab/tabpanel, focus management, and the selection reducer, into a common hook reused by both renderers. Consumers write the same JSX everywhere.

COMMON WRONG ANSWERS Shipping two components, TabsDesktop and TabsMobile, with different props, pushing the branching onto consumers. Duplicating selection state per mode so the swipe view and the bar can fall out of sync. Forgetting accessibility, which differs but must be handled in both modes.

LIKELY FOLLOW-UPS How do you keep ARIA roles correct in both presentations? How do you decide between a breakpoint and a touch-capability check? How do you avoid layout shift when switching modes?

ONE CONCRETE EXAMPLE The public Tabs takes items, value, and onChange. A useTabsState hook owns selection and ARIA wiring. Above a breakpoint it renders TabBar (clickable headers, arrow-key navigation); below it renders SwipePager (horizontal snap, swipe updates value). Both call onChange with the same value, so a user who resizes from mobile to desktop keeps the same active tab and the consumer code never changes.