A Tabs component is simple state-wise — activeTab — but interviewers grade the accessibility and the API design.

Minimal implementation

function Tabs({ tabs }) {  // tabs: [{ id, label, content }]
  const [active, setActive] = useState(tabs[0].id);

  const onKeyDown = (e, idx) => {
    if (e.key === "ArrowRight") setActive(tabs[(idx + 1) % tabs.length].id);
    if (e.key === "ArrowLeft")  setActive(tabs[(idx - 1 + tabs.length) % tabs.length].id);
  };

  return (
    <div>
      <div role="tablist">
        {tabs.map((tab, idx) => (
          <button
            key={tab.id}
            role="tab"
            id={`tab-${tab.id}`}
            aria-selected={active === tab.id}
            aria-controls={`panel-${tab.id}`}
            tabIndex={active === tab.id ? 0 : -1}     {/* roving tabindex */}
            onClick={() => setActive(tab.id)}
            onKeyDown={(e) => onKeyDown(e, idx)}
          >
            {tab.label}
          </button>
        ))}
      </div>

      {tabs.map((tab) => (
        <div
          key={tab.id}
          role="tabpanel"
          id={`panel-${tab.id}`}
          aria-labelledby={`tab-${tab.id}`}
          hidden={active !== tab.id}
        >
          {tab.content}
        </div>
      ))}
    </div>
  );
}

What's actually being graded — accessibility

This is a WAI-ARIA pattern; getting it right is the point:

• role="tablist", role="tab" on each button, role="tabpanel" on each panel.
• aria-selected on the active tab; aria-controls links tab → panel; aria-labelledby links panel → tab.
• Roving tabindex — only the active tab is tabIndex={0}; the rest are -1. So Tab moves into and out of the tablist as one stop; arrow keys move between tabs.
• Arrow-key navigation — Left/Right (Up/Down for vertical) cycle tabs; Home/End jump to first/last.
• Use real <button>s so Enter/Space work for free.

API design — compound component

For a reusable library version, build it as a compound component sharing state via Context:

<Tabs defaultValue="a">
  <TabList>
    <Tab value="a">First</Tab>
    <Tab value="b">Second</Tab>
  </TabList>
  <TabPanel value="a">...</TabPanel>
  <TabPanel value="b">...</TabPanel>
</Tabs>

Tabs holds active in Context; Tab/TabPanel read it. More flexible than a tabs prop array.

Other considerations

• Controlled vs uncontrolled — support both (value/onChange or defaultValue).
• Lazy panels — optionally only mount the active panel's content.
• Sync active tab to the URL for deep-linking.

The framing

"State is just activeTab. What's graded is the WAI-ARIA tabs pattern: role=tablist/tab/tabpanel, aria-selected, aria-controls/aria-labelledby wiring tabs to panels, and crucially a roving tabindex so the tablist is one Tab-stop and arrow keys move between tabs. Real <button>s give Enter/Space for free. For a library API I'd build it as a compound component — Tabs/TabList/Tab/TabPanel sharing state via Context — and support controlled and uncontrolled modes."