Frontend Developer interview questionsCoding Test round

Purpose

Tells a candidate who prepared for algorithm puzzles that the hour is about a component, so the first minutes go on reading it rather than waiting for a problem statement.

Purpose

Hands over the symptoms and the fix already tried, so the first question scores diagnosis rather than the textbook remedy for a search box.

Purpose

Separates candidates who can reason about time in the browser from candidates who hear "search box" and answer "debounce". The debounce is already there and correct, so what they say about it is the first thing to write down.

Signals to score

• Gives a concrete timeline for the wrong results: the request for "la" is still in flight when the request for "lamp" goes out, and the older response lands last and overwrites the newer one
• Explains why the debounce made the report rarer without removing it: the race needs two requests in flight at once, which takes a pause longer than 250 ms mid-typing and a first response slower than the gap
• Says the debounce is correct as written and does not propose a longer delay as the fix
• Finds that one `loading` flag serves every request, so the first success to arrive hides the spinner while the request that matters is still pending
• Traces the endless spinner to the empty `catch`: a failed request never resets `loading` and shows nothing
• Finds the cleared-box path — the old results stay, and a response still in flight lands under an empty input
• Tries the component before theorising — types with a pause, clears the box, forces a failure
• Names the missing label and the click-only results as a separate problem and parks them for later
• Says what is right in the starter — the debounce, the keys, a mock that already accepts a signal — not only what is wrong

Follow-up questions

• The debounce is 250 ms. Why did the wrong-results report get rarer but not stop?
• Type "la", wait half a second, type "mp". Which responses can arrive in which order, and what is on screen after each?
• Two requests are in flight and the older one succeeds first. What does the spinner show?
• Clear the box while a search is still loading. What happens, step by step?
• What in this repository is already right?

Purpose

Makes the test the first deliverable, so the fix is measured against something that failed rather than against the candidate's confidence.

Purpose

Reads whether the candidate controls time in a test or races it. A test built on real timers and the mock's random latency passes most runs against the broken component and proves nothing.

Signals to score

• Writes the test before changing the component
• Replaces the API with calls that return promises the test settles by hand, so the test decides which response lands first
• Uses fake timers to step past the 250 ms debounce instead of waiting in real time
• Types "la", advances past the debounce, types "mp", advances again, then resolves "lamp" before "la"
• Asserts on the result names the user sees, not on component state or on how many times the API was called
• Runs it against the starter and reads the failure — the "la" results on screen — before touching the component
• Adds a case for the cleared box: a response that arrives after the input is emptied must not fill the list
• Keeps the test independent of how fast the machine running it is

Follow-up questions

• How does your test decide which response arrives first?
• Does this test wait 250 ms of real time? Should it?
• It passes. Show me it failing on the starter.
• What does the assertion check — what the user sees, or what the component did?
• What about a response that arrives after the box has been cleared?

Purpose

Scored on one rule and on how the fix fails. Most candidates reach for AbortController; the separator is whether the rule is also enforced at the moment results are written, and whether the fix survives the cleared box.

Signals to score

• Makes only the current query able to write results — a check at commit, effect cleanup, or both — and says which part guarantees it
• Passes a signal to `searchProducts` and aborts the superseded request, and knows aborting alone does not stop a response that is already being handled
• Does not show an aborted request as an error
• Replaces the separate loading flag and results with one status for the current query — idle, loading, results, failed — so the spinner and the list cannot disagree
• Stops the spinner on failure and shows an error the user can act on, with a retry
• Clears the results when the box is emptied, and makes sure a request still in flight cannot refill it
• Decides what stays visible while the next results load, and gives the reason
• If reaching for a data-fetching library, says what it does that fixes this rather than only naming it
• Takes the earlier test to green, with the cleared-box case

Follow-up questions

• You abort the old request. Is that enough without any other check?
• The user clears the box while "lamp" is still loading. Walk me through your code.
• A request fails. What does the user see, and what can they do next?
• Why did you keep, or drop, the previous results while new ones load?
• You reached for a library. What does it do with a response for a query that is no longer in the box?

Purpose

The decision that separates candidates comes before any ARIA: whether choosing a result opens the product page, in which case a labelled input, a list of links and an announcement may be all it needs, or fills the box, in which case it is a combobox and the pattern has to be built whole or not at all.

Signals to score

• Asks what choosing a result does before choosing markup, and says how the answer changes it
• Gives the input a real label, visible or not, instead of relying on the placeholder
• Replaces the clickable `div`s with native links or buttons, or with options inside a listbox — never a `div` with a role and no key handling
• If arrow keys are wanted, keeps focus in the input and points `aria-activedescendant` at the active option, with `aria-expanded` and `aria-controls` on the input
• Says what Enter, Escape and the arrow keys do, including at either end of the list
• Announces the result count through a polite live region that is in the page from the start and changes when a search settles, not on every keystroke
• Announces a failed search as well as a successful one
• Keeps announcements short — a count, not the list — and does not make them assertive
• Shows the active option to sighted keyboard users as well as to screen readers
• Says how they would check it — the keyboard alone, and a named screen reader with a browser — and knows an automated checker cannot tell whether the keys work

Follow-up questions

• When someone chooses a result, does it open a page or fill the box? Does that change your markup?
• Product wants the arrow keys to move through results while the cursor stays in the box. Where is focus, and how does a screen reader know which result is active?
• The count changes several times while someone types "lamp". What do they hear, and when?
• The search failed. What does a screen reader user hear?
• How would you check this before merging, and with what?