Frontend Developer interview questionsComponent API review — a dialog for the design system round

Purpose

Puts the candidate in a reviewer's seat with real consumers, so the review is about the people calling the component rather than how its code looks.

Purpose

The load-bearing question. Two of the plants are visible only through the call sites, so the separator is whether the candidate reads the consumers as carefully as the component.

Signals to score

• Finds the copied `isOpen` state, and uses the two call sites to explain why Account's dialog will not reopen after Escape while Billing's works
• Gives open state one owner — the caller, through a value and a change callback that cannot be left out — with any uncontrolled default made explicit
• Reads Billing's empty `footerButtons` and hand-drawn buttons as the configuration API failing its first real consumer
• Traces the backdrop bug to where the click is dispatched: a press that starts in the form and ends over the backdrop fires the click on the backdrop, so the check passes
• Flags that the dialog has no accessible name when `title` is left out, and that `title` is not connected to the dialog even when present
• Flags that Tab leaves the dialog, the page behind stays interactive, and focus is not returned on close
• Sorts the findings by what gets more expensive after merge — API shape before anything else — and says what that means for the two teams already on the branch
• Says what is right — the portal, and the scroll lock that restores the previous value — so the review is not a rewrite
• Asks about the consumers before the code: which flows each team built, and what they needed that the component did not give them

Follow-up questions

• Account says that after Escape the dialog won't open again until they reload. Billing says it works. Who is right?
• Billing passes an empty `footerButtons` and draws its own buttons. What is that telling you?
• Someone selects text in the address field and lets go over the dark background. What happens, and why?
• Which of your comments block the merge, and which get more expensive if they wait?
• What would you ask the author before writing any of this down?

Purpose

Fixes the flow before the question, so the answer comes as a sequence of focus positions rather than a list of rules.

Purpose

Reads accessibility where it is hardest to fake: focus over time, across a flow that removes the elements focus came from. Saying "trap focus in the modal" is common; knowing what to do when there is nothing left to return focus to is not.

Signals to score

• Walks the flow as focus positions: the "More" button, the menu item, the dialog, Confirm, the row removed
• Puts initial focus somewhere deliberate — Cancel for a destructive confirmation, the first field for a form — and says why not the confirm button
• Keeps Tab from reaching the page behind, naming the native `<dialog>` opened with `showModal()` or the `inert` attribute rather than a hand-written trap
• Names the dialog by its heading and describes it by its consequence, so a screen reader user hears what they are confirming
• Returns focus on Escape or Cancel to the row's "More" button, noticing that the element that actually opened the dialog — the menu item — no longer exists once the menu closes
• On confirm, recognises that the "More" button goes with the row, and chooses where focus lands instead of letting it fall to the page
• Tells a screen reader user the outcome — the subscription was cancelled — in a way that is not lost when focus moves
• Turns the flow into API: the caller can say where focus goes on close, with a default of the element focused before opening when it is still in the page
• Checks it with the keyboard alone, then with a named screen reader

Follow-up questions

• The menu closed when "Cancel subscription" was chosen. Which element opened the dialog, and does it still exist?
• Which button has focus when the dialog appears, and why that one?
• The user presses Escape. Where does focus go?
• The user confirms and the row disappears. Where does focus go now, and what does a screen reader user hear?
• What does the component have to accept so Billing can get this right?

Purpose

Makes the call sites the test of the API, which is how the teams using it will judge it.

Purpose

Moves from critique to design. The API is scored on whether it makes the wrong use hard — an unnamed dialog, two owners for open state, a busy confirm nobody can show — and on whether the candidate uses the two call sites as its test.

Signals to score

• Writes the API as types before prose, and rewrites both call sites with it
• Gives open state one owner — a value and a change callback — and says whether an uncontrolled default is offered and who it is for
• Makes an accessible name hard to leave out — a required title part connected to the dialog, or a development warning when no name is present — and says why types alone cannot enforce it
• Composes the dialog from parts — title, description, body, footer — instead of configuring buttons through an array
• Lets Billing keep the dialog open with its buttons busy while the confirm runs, and show the error inside the dialog if it fails
• Tells the caller why the dialog wants to close — Escape, backdrop or a close button — so Account can refuse while its form has unsaved changes
• Makes initial focus and focus on close part of the API, with defaults that are right for most callers
• Keeps styling hooks narrow — a size, a class on the panel — and says what they are refusing to expose
• Plans the move from thirty hand-rolled modals without a big-bang: which go first, how the old ones are marked, and what would show it worked
• Names the smallest version they would merge this week

Follow-up questions

• Show me Account's call site with your API. What did it lose, and what did it gain?
• Billing's confirm takes two seconds and sometimes fails. Walk me through that with your API.
• Under your design, how does someone ship a dialog with no name?
• Account's form has unsaved changes and the user presses Escape. Who decides what happens?
• Thirty hand-rolled modals exist today. Which do you move first, and how do you know the migration is working?

Purpose

Candidates who have maintained shared components ask how changes reach the teams using them and who decides; others ask about the styling approach. The bracketed fact should be one you would tell a new hire anyway.