Frontend Developer Interview Questions With Worked Reasoning

Prepare to explain what the user experiences, why the interface behaves that way, and how you would verify a fix. Knowing a framework API helps, but the reasoning should remain understandable without a list of library names.

These are original practice questions, not confirmed questions from a particular employer. Adjust the depth to the job description and ask about the stack and assessment format in advance.

1. Why use a button instead of a clickable div?

A strong answer begins with the intended interaction. A control that performs an action should generally use the native element designed for it. MDN's semantic HTML guidance explains that native buttons provide keyboard interaction that a generic element does not supply automatically.

Then describe verification: tab to the control, confirm visible focus, activate it with the expected keys, and check its accessible name. If the control is inside a form, consider whether its type should submit the form or perform a separate action.

Follow-up: What if the design requires a custom appearance? Explain that styling a native button does not require abandoning its semantics. Do not suggest removing focus indicators merely to match a mockup.

2. A search result belongs to the previous query. What happened?

Consider this fictional sequence: a request for "ca" starts, then a request for "cat" starts. The second finishes first. The first finishes later and replaces the current results.

The issue is response ordering, not necessarily slow rendering. Describe how you associate a response with the request or query that is still current before committing it to the interface. Cancel obsolete work where supported; MDN documents AbortController for aborting supported asynchronous operations such as fetch requests.

Cancellation and a current-request check address different concerns. Your correctness test should deliberately complete responses out of order, not merely type slowly and observe one successful run. Also test an error from an obsolete request so it cannot overwrite a newer success.

3. How would you investigate a slow interaction?

First define the symptom: slow initial loading, delayed click feedback, a long list update, or uneven animation. Reproduce a specific action, measure it, and separate network delay from scripting, layout, paint, and rendering work.

An illustrative answer:

I would record the interaction before changing anything. If filtering a list causes the delay, I would inspect the amount of work and the rendered item count. I would then test a targeted change with the same data and interaction, while checking keyboard navigation and search results remain correct.

Avoid promising that memoization, virtualization, or removing an effect is always the answer. The measurement should identify the bottleneck; the regression checks should protect behavior.

4. A layout works with short English labels but breaks elsewhere. What do you test?

Test longer labels, narrow viewports, zoom, loading and error states, and relevant writing directions. Ask whether the content should wrap or remain on one line. Do not solve overflow by silently truncating essential instructions.

Explain the difference between an intended fixed-size control and a container that must grow with content. A screenshot of one viewport is not evidence that the responsive rules work across states.

5. What belongs in a component test?

Start with observable behavior: a user enters a query, activates a control, receives feedback, and can recover from an error. Test important states and boundaries instead of asserting every internal variable.

For the stale-search example, include an empty query, rapid query changes, a current request failure, and an obsolete request finishing late. Explain what belongs in an integration test when network or routing behavior crosses component boundaries.

Use the technical interview preparation guide to plan practice. Rehearse one bug investigation from symptom to evidence to verification; that is more useful than memorizing isolated definitions without being able to apply them.