Frontend developer interview guide

What the process usually looks like

Frontend processes vary, but most companies run some version of the same five stages. Knowing which stage you are at tells you what is being assessed, which is more useful than a list of questions.

1. Recruiter screen (20–30 minutes): motivation, salary expectations, notice period, and a sanity check on your experience.
2. Technical screen (45–60 minutes): a small coding exercise, often in a shared editor, or a discussion of your past work.
3. Take-home or live build (1–4 hours): build a small feature. This is the stage that most often decides the outcome.
4. System and craft discussion (60 minutes): component architecture, state management, performance, accessibility.
5. Team and values conversation: how you collaborate, handle disagreement, and give feedback.

JavaScript questions you should be able to answer cold

Interviewers are not testing recall. They are testing whether you have debugged something with these mechanics involved. Answer with the concept, then immediately give a case where it bit you.

• What is the difference between == and ===, and when would you deliberately use the loose one?
• Explain closures with an example from real code, not a counter function.
• What does the event loop do with a promise versus a setTimeout callback, and in what order do they run?
• How does prototypal inheritance differ from classical inheritance?
• What are the practical differences between var, let and const in a loop?
• What is event delegation, and why does it matter for a list of a thousand rows?
• How would you deep clone an object, and what breaks with JSON.parse(JSON.stringify(x))?

React questions and what a good answer contains

• When does a component re-render, and how do you find out why one did? A good answer mentions profiling before optimising.
• What problem do keys solve in a list, and what goes wrong with array indices as keys?
• When would you reach for context, and when is it the wrong tool? Look for an answer that mentions re-render scope.
• How do you handle data fetching, loading and error states? Strong candidates mention what the user sees during each.
• What is the difference between server and client components, and what determines which you choose?
• How do you test a component? The expected answer is testing behaviour a user can observe, not implementation details.

CSS and accessibility — where most candidates lose points

Frontend candidates routinely prepare JavaScript thoroughly and CSS not at all, then meet a layout question in the live exercise. Accessibility is the same story, and it is increasingly a hard requirement rather than a bonus.

• Be able to build a responsive layout with flexbox and grid without looking anything up.
• Understand the cascade, specificity and stacking contexts well enough to debug someone else's stylesheet.
• Know what semantic HTML buys you: a button is focusable, keyboard-activatable and announced correctly; a div with an onClick is none of those.
• Be able to explain focus management in a modal, why aria-label is a last resort, and what a visible focus indicator is for.
• Know how to check colour contrast and roughly what the thresholds are.

The take-home exercise

This stage is where offers are won and lost, and the differentiator is rarely cleverness. Reviewers are looking for code they would be happy to maintain.

1. Read the brief twice and write down the acceptance criteria before opening an editor.
2. Commit in small, meaningful steps. Reviewers read the history.
3. Handle the unglamorous states: empty, loading, error, and long text that breaks the layout.
4. Write a README explaining your decisions, what you would do with more time, and what you deliberately left out. This single file changes reviewer perception more than any feature.
5. Include a few tests of behaviour. Two good tests beat twenty shallow ones.
6. Respect the stated time budget and say what you spent. Going far over is not a positive signal.

Behavioural questions in a technical interview

Use STAR — situation, task, action, result — and keep each answer under two minutes. Prepare three stories that can be reshaped to fit most questions rather than trying to have one per question.

• Tell me about a technical decision you got wrong. What did it cost, and how did you find out?
• Describe a disagreement with a designer or product manager and how it resolved.
• What is the hardest bug you have debugged? Interviewers want method, not heroics.
• How do you handle a code review comment you disagree with?
• Tell me about something you shipped that users noticed.

Questions to ask them

• What does the first 90 days look like for this role?
• How does work get from idea to production here, and how long does that usually take?
• What is the test and review culture like? Who reviews frontend work?
• What is the most frustrating part of the codebase right now?
• How is the team measured, and by whom?