Frontend Developer Interview: How to Prepare (2026)

Cohesyve · Practice for candidates

Preparing for a Frontend Developer role? Start by finding out where you stand.

Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.

free assessments

no card required

Full

scored report every run

Every

question type included

3 free assessments · No card required · Pro from $16/mo

Overview

Frontend hiring has moved away from framework trivia and towards evidence that you can ship working interface code under a deadline. A typical process now runs from a CV screen through a recruiter call, a timed build or take-home, one or two technical interviews, and a final conversation about how you work with designers and product. Each stage tests something different, and candidates usually lose ground at the stage they prepared for least. This page walks the process end to end and sets out what to practise for each part of it.

The hiring process, stage by stage

Application and CV screen

A recruiter or hiring manager spends a short time deciding whether your experience matches the stack and the level. For frontend, they are scanning for the framework, the type of product (marketing site, dashboard, design system, consumer app) and whether you owned anything end to end.

How to prepare: Rewrite the top third of your CV so the product type and the stack are visible in the first two lines. Replace duty statements with outcomes: what you built, who used it, and what changed. Link a live URL or a repository rather than a PDF portfolio nobody will open.

Recruiter screen

A twenty to thirty minute call covering your background, notice period, salary expectation and a light technical sanity check. The recruiter is usually not an engineer, so they are matching keywords and checking that your story is coherent.

How to prepare: Prepare a ninety second summary of your last two roles in plain language a non-engineer can follow. Have a salary range and a notice period ready so you do not stall. Ask which framework the team uses day to day and how the assessment stage works, so you can plan the rest of your preparation.

Skills assessment or take-home

Either a timed in-browser task or a take-home build, usually a component or small feature with an under-specified brief. Scoring weights working functionality and edge-case handling above styling polish.

How to prepare: Practise scoped builds against a timer rather than doing open-ended side projects. Rehearse the unhappy paths specifically: loading, empty, error and double-submit. Write a short README noting assumptions, trade-offs and what you would do with more time.

Technical interview or pairing session

A live session with one or two engineers. Often an extension of your submission, a debugging exercise in an unfamiliar codebase, or questions about rendering, state and browser behaviour.

How to prepare: Re-read your own submission the night before and be ready to defend every non-obvious decision. Practise narrating while you code, because silence reads as being stuck. Rehearse explaining one rendering bug, one state bug and one layout bug you have actually fixed.

Final interview with the hiring manager

A conversation about how you work with designers, how you handle scope changes, how you handle disagreement about implementation, and whether you fit the team's level expectations.

How to prepare: Prepare three stories: a time a design was not implementable as drawn, a time you shipped something you later had to rework, and a time you pushed back on scope. Keep each to two minutes with a concrete outcome at the end.

What to study

Component design and state placement

Nearly every assessment and follow-up interview probes where you put state and why. It is the fastest way for an interviewer to tell whether you have maintained frontend code or only written it.

Lifting state versus colocating it, and the cost of eachWhen context, a store or a URL parameter is the right home for stateDeriving values during render instead of storing duplicate stateDrawing component boundaries along responsibility rather than file length

Async data and the unhappy paths

Assessors score loading, empty, error and race conditions heavily because they are the states real users hit and the states rushed candidates skip.

Cancelling or ignoring stale responses so results cannot arrive out of orderDebouncing and throttling input-driven requestsDistinguishing "no results" from "not loaded yet" in the interfacePreventing duplicate submissions while a request is in flight

CSS layout and responsive behaviour

You will be given a design at one width and expected to make it work across a range. Reviewers open your submission on a narrow viewport almost immediately.

Flexbox and grid, including intrinsic sizing over fixed breakpointsHandling long content and overflow rather than assuming sample textStacking contexts, z-index and why an overlay sits behind somethingContainer queries and modern units where they simplify a layout

Accessibility fundamentals

Most teams do not expect an audit, but they do expect semantics, labels and keyboard operation. Missing them is treated as carelessness rather than a knowledge gap.

Semantic elements and when an ARIA role is genuinely neededFocus management: trapping, restoring and visible focus stylesLabelling form controls and describing errors programmaticallyKeyboard operation of menus, modals and custom controls

Performance and rendering behaviour

Senior conversations move quickly to why a page is slow. You need vocabulary for both the browser side and the framework side.

What causes unnecessary re-renders and how to diagnose them with profiling toolsBundle size, code splitting and deferring non-critical workCore Web Vitals and what actually moves each oneRendering large lists without freezing the main thread

Cohesyve for candidates

Practise a Frontend Developer assessment before the real one

Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.

Your preparation plan

Four weeks out

Close the gaps you already know about and build a base of timed practice.

•List the stack in the job advert and honestly mark what you have not touched in a year
•Do two timed build tasks a week, forty five minutes each, from a written brief
•Rebuild one component you are proud of with accessibility and error states done properly
•Refresh your CV and portfolio links so applications are not blocked later

Two weeks out

Move from building to explaining, and start rehearsing the conversation.

•Practise narrating your reasoning aloud while coding, recording one session to hear the gaps
•Write two-minute versions of three project stories with a concrete outcome each
•Work through debugging exercises in code you did not write, timing how long diagnosis takes
•Research the company product and note two specific interface decisions you would ask about

The final week

Simulate the real conditions rather than adding new material.

•Run one full mock assessment end to end without pausing, then review it as a reviewer would
•Set up a clean project template so you are not configuring tooling on the clock
•Re-read your take-home submission and prepare a defence for each non-obvious choice
•Draft your six questions for the panel and cut them to the sharpest four

The day before and the day of

Protect your pacing and remove avoidable friction.

•Test camera, microphone, screen share and the editor you plan to use
•Close everything except documentation you would normally have open
•Re-read the job advert once and note the two requirements you most want to evidence
•Plan the first five minutes: clarify the brief, state assumptions, then start on functionality

Questions to expect

“Walk me through how you would build a searchable, paginated list.”

What they're really asking: Do you think about data flow, state and edge cases before you start typing, or do you build the happy path and discover the rest late?

How to answer: Sketch the shape first: where the query lives, where results live, how pagination is represented in the URL. Then name the failure cases you would handle — stale responses, empty results, an error mid-scroll. Finish with what you would defer and why.

“A component re-renders on every keystroke. How do you find the cause?”

What they're really asking: Can you debug systematically in an unfamiliar codebase, or do you guess and change things until it stops?

How to answer: Describe a narrowing process: confirm the symptom with a profiler, identify which component is re-rendering, check for unstable references in dependency arrays or props, then verify the fix removes the cause rather than masking it. Mention that you would not silence a lint rule to make it go away.

“How do you decide when to reach for a state management library?”

What they're really asking: Do you add abstraction by default, or in response to a real problem you can articulate?

How to answer: Give your default position first — local state, then lifted state, then server state handled by a data layer. Then name the specific signal that would change your mind, such as the same state being needed by unrelated branches of the tree. Reference a real project where you made the call.

“Tell me about a time a design could not be built as drawn.”

What they're really asking: How do you handle disagreement with a designer, and do you bring solutions or just objections?

How to answer: Name the constraint concretely — a responsive breakage, an accessibility problem, a performance cost. Explain what you proposed instead, how you demonstrated it (a prototype usually beats an argument), and what shipped. Avoid framing the designer as the problem.

“What does accessible mean to you in practice?”

What they're really asking: Do you treat accessibility as routine work or as a specialist add-on that someone else handles?

How to answer: Answer with habits, not principles: semantic elements first, labels on every control, keyboard operation checked before you open a pull request, focus visible and managed in overlays. Then mention one thing you got wrong once and now check for automatically.

“This page loads slowly. Where do you start?”

What they're really asking: Do you measure before optimising, and do you understand both network and rendering costs?

How to answer: Start with measurement — which metric is bad and on what device and connection. Separate network cost from rendering cost. Then give a shortlist of common causes in order of likely impact, and say what you would do first and how you would prove it worked.

What to bring as evidence

A live URL for at least one interface you built, with a sentence on what you owned
A repository with readable commits, not a single squashed dump
One before-and-after example of a performance or accessibility fix, with the measurement
A short written note on a trade-off you made and would defend
Two references who can describe how you work with designers and product
A tidy take-home submission with a README covering assumptions and next steps

Common mistakes

Spending most of a timed task on styling and running out of time before the functionality works
Skipping loading, empty and error states, which is one of the fastest ways to lose marks
Guessing silently at an ambiguous requirement rather than stating the assumption out loud
Leaving console errors and warnings in a submission you have asked someone to review
Over-engineering a forty minute task with a store, an abstraction layer and a design system
Talking about frameworks in the interview but being unable to explain the browser behaviour underneath

Questions to ask them

?
Who decides what the interface should look like when the design and the constraint disagree?
?
How much of the frontend codebase would you rewrite tomorrow if you could, and which part?
?
What does a typical pull request look like here in terms of size and review turnaround?
?
How is accessibility handled — is it part of the definition of done or a periodic audit?
?
What is the current state of test coverage on the frontend, and who maintains it?
?
What happened the last time a release broke something in production?

Frequently Asked Questions

How much framework depth do I need versus JavaScript fundamentals?

You need enough framework fluency to be productive on day one, but interviews separate candidates on fundamentals. Questions about stale closures, event ordering, references and the browser rendering path come up repeatedly, and framework-only answers run out quickly. Study the framework you will use, but be able to explain what it is doing on your behalf.

Should I finish a take-home even if it takes longer than the stated time?

Treat the stated time as a scoring boundary. Reviewers notice a submission that clearly took four hours, and it makes your work impossible to compare fairly with others. Stop at the limit, make what you have correct, and use the README to say what you would have done next.

Does my portfolio still matter?

It matters for getting a first conversation and much less after that, because reviewers cannot tell which parts you wrote. One or two live examples with a clear statement of what you owned is worth more than a gallery. Depth beats volume.

What if I do not know the answer during a live technical interview?

Say what you do know, name the boundary of it, and describe how you would find out. Interviewers are largely trying to work out whether you can be trusted with unfamiliar problems, and a calm, structured unknown reads far better than an invented answer.

Can I practise the assessment stage before it counts?

Yes, and it is the single highest-return preparation for frontend roles because the failure mode is pacing rather than knowledge. Cohesyve lets you import the job you are applying for, run a role-specific simulation of the assessment, and get a scored report with a learning pathway. The free tier includes three scored assessments with no card required, which is enough to rehearse a real process end to end.

Practice

What a Frontend Developer assessment tests, and how it's scored →

Career guide

What a Frontend Developer actually does, and where the path leads →

Prepare for another role

Backend Developer →Full Stack Developer →Android Developer →iOS Developer →