Frontend Engineer interview
Frontend Engineer interview practice, out loud
Frontend interviews have quietly moved past "reverse a string" into how you actually build interfaces: state that doesn't tangle, a render you can explain, and a page that stays fast and accessible under real data. The panel finds out with follow-ups, not a quiz — and that's the part you can't cram.
This rehearsal is a spoken interview built around a real frontend posting. It moves from a UI you've built, into how you'd structure a component and its state, a bug where the screen re-renders too much, and the performance and accessibility calls most candidates skip.
The report tells you where your reasoning was sharp, where you reached for a library before understanding the problem, and how clearly you explained a tricky rendering decision.
Frontend Engineer interview at a glance
- Rounds
- Three or four — a screen, a JavaScript fundamentals round, a component build, and a discussion round on performance and craft
- Length
- 45–90 minutes; the component build is the long one and is standard at Indian product companies
- What is actually tested
- The language and the browser more than the framework — closures, the event loop, promise ordering
- Accessibility
- Usually one question, and the semantic element is the expected first answer, not ARIA
- Where candidates actually lose
- Building before asking what the empty, loading and error states should do
- Prep that pays
- One deployed link you can open and talk through, because they will open it
What actually happens in a Frontend Engineer interview
Screen~20 min
Framework, how much TypeScript you have actually written, whether anything you built is in front of real users, and a link. Keep the link live — a portfolio that fails to load during the screen is a worse first impression than not having one.
JavaScript fundamentals~45 min
Closures, what this binds to, the event loop, the order two promises and a timeout resolve in, and a debounce written by hand. Almost none of it is framework-specific, which is deliberate: a team that migrates its framework in three years still keeps the people who understand the language.
The component build~75 min
A working component from a loose spec — an autocomplete, a nested comment thread, a table with paging and sorting. The spec is loose on purpose, and the questions you ask about the states it does not describe are part of the assessment rather than an interruption to it.
Rendering and performance discussion~40 min
Why a component renders more than it should, what you would open the profiler for, why a long list stutters, and which page metric you would try to move. This round rewards having measured something once far more than having read about optimisation many times.
Craft and collaboration round~35 min
A design handed over with a gap in it, a code review you gave or received, and how you work with a designer who has drawn something expensive to build. Frontend sits on a seam between two crafts, and this round is about whether you can hold that seam.
What this interview assesses
Frontend Fundamentals
Do you understand how the browser and your framework actually render — state, re-renders, the DOM — rather than only wiring up components by pattern?
Debugging & Problem Solving
When a UI misbehaves — a stale value, an extra render, a layout break — do you isolate it methodically instead of sprinkling changes until it looks right?
Craft & Communication
Do you care about accessibility and performance, and can you explain a UI trade-off (this state here, that render there) plainly to a reviewer?
Sample Frontend Engineer interview questions
A feel for the kind of questions you’ll face. The real interview reacts to your answers with live follow-ups — these are examples, not the exact set.
1.Walk me through a frontend feature you built. How did you structure the components and state?
What lands: Show where state lived and why, and one trade-off you made — lifting state, a context, memoisation — that you can defend.
2.A component re-renders far more than it should. How do you find out why?
What lands: Reach for the profiler and reason about what changed — props identity, context, keys — before adding memo everywhere.
3.How would you make a long list of thousands of items scroll smoothly?
What lands: Virtualise, and think about keys, stable references and avoiding work per row — not just 'add pagination'.
4.What does making this form accessible actually involve?
What lands: Labels, keyboard flow, focus management and error announcement — concrete things, not just 'add aria-labels'.
5.The page loads slowly on a mid-range phone. Where do you look?
What lands: Bundle size, images, render-blocking work and hydration — measure first, and know what Save-Data and a slow network change.
The job description it’s built around
The free taster rehearses against this realistic Frontend Engineer posting. In a full rehearsal you can paste the exact job you’re targeting instead.
Read the sample job description
Frontend Engineer (0–3 yrs) · Product Startup · Bengaluru / Remote About the role We build a fast, polished web app used daily by thousands of users. As an early-career Frontend Engineer you'll turn designs into responsive, accessible interfaces and own features end to end with a small product pod. What you'll do - Build UI in React (TypeScript) from designs, with clean, reusable components - Manage state sensibly and keep renders predictable and fast - Make pages responsive and accessible (keyboard, ARIA, contrast) - Integrate REST/GraphQL APIs and handle loading, error and empty states - Write component tests and take part in code review - Profile and fix performance issues — bundle size, re-renders, slow lists What we're looking for - 0–3 years building web UIs (strong projects and internships count) - Solid JavaScript/TypeScript, HTML and CSS fundamentals - Working knowledge of React and its rendering model - An eye for detail and basic accessibility awareness - Clear communication about trade-offs Nice to have - Exposure to Next.js, testing libraries, or a design system - A portfolio or side project you can walk through
Frontend Engineer interview — the specifics worth knowing
- The component build is scored on whether it works and covers its states, not on how much of the spec you got through. A half-built feature that handles loading, empty and error beats a complete happy path.
- How we know: The states nobody drew are where production bugs actually come from, so an interviewer watching you skip them is watching a preview of your pull requests.
- The fundamentals round is about the language and the browser rather than the framework — closures, the event loop, promise ordering, the value of this in a callback.
- How we know: Framework knowledge decays and language knowledge does not, so it is the part of your skill set the team is buying for the longest. Interviewers say this out loud when asked.
- Accessibility usually gets exactly one question, and answering it with ARIA attributes is the wrong opening. A native element, a properly associated label, and a sane focus order come first; ARIA covers what has no native equivalent.
- How we know: The specification's own guidance is that no ARIA is better than bad ARIA, and a native control arrives with keyboard behaviour and semantics already correct. Reaching for an attribute first inverts that.
- Performance questions have moved onto named metrics — largest contentful paint, layout shift, interaction latency — so an answer that never names one reads as something you have read about rather than measured.
- How we know: These metrics are published, reported in browser tooling, and feed search ranking, so teams track them by name and expect a candidate to speak the same vocabulary.
- A re-render question wants the profiler and the reason — a prop whose identity changes each render, a context that updates too broadly, a key that is an array index — before any mention of memoisation.
- How we know: Memoising everything is a recognised anti-answer because it adds comparison work and hides the cause. Interviewers ask this specifically to find out which instinct comes first.
- The ambiguous design handoff is a real interview question, and the expected answer is to ask, then decide, then write the decision down — not to build the happy path and wait for someone to notice.
- How we know: A designer cannot draw every state and does not expect to, so the interface between the two roles is a stream of small decisions. Whether you make them visibly is what is being checked.
- CSS is still asked, and it is layout rather than trivia: flex against grid, why a container overflows its parent, how specificity resolved something unexpectedly, and how you would centre a thing.
- How we know: These are the four that break a build in a review, and a candidate who reaches for a utility class without knowing what it emits gets stuck when the layout misbehaves.
- Your portfolio is opened during the call, on their machine, and sometimes on a phone. What it does on a narrow viewport and how fast it loads become part of the interview whether or not anyone mentions it.
- How we know: You published a frontend artefact and applied for a frontend job. It is the only piece of evidence in the process that was not written to be persuasive.
- TypeScript is assumed rather than a bonus in most current postings, and saying you have used it a little invites a question about a type you actually had to write yourself.
- How we know: Consuming types someone else wrote and writing a generic of your own are different skills, and the second is what a team relies on. Say which one you have done.
Common mistakes — and what to do instead
Building the happy path first and running out of time before the other states.
Put the loading, empty and error branches in early, even as one-line placeholders you fill in later. It costs three minutes and it moves the assessment.
Answering the accessibility question by listing ARIA attributes.
Start with the native element and the label association, then name the one place ARIA is genuinely required — a widget the platform has no element for.
Answering a slow-page question with a general intention to optimise images.
Say what you would measure and which metric would move. A specific measurement you once took beats a plausible list of optimisations every time.
Telling a design-collaboration story where the designer turned out to be wrong.
Tell one where a question you asked changed the design. That answers the question actually being asked, which is whether you improve the seam or defend your side of it.
Preparation checklist
- Deploy one project and confirm the link opens and works before the call
- Write a debounce by hand, with no framework, until it is automatic
- Explain a promise-ordering puzzle out loud rather than on paper
- Rehearse building a component starting from its empty, loading and error states
- Name one page metric and one change you made that moved it
- Prepare an ambiguous design handoff and the question you asked about it
- Have a re-render you diagnosed with a profiler rather than with memoisation
- Decide honestly how much TypeScript you have written, and say that
Frontend Engineer interview — FAQs
Is this a live coding round?
No — it's the spoken half of a frontend loop: how you'd structure a component, debug a render, and reason about performance and accessibility. There's no editor; you talk through your approach.
Which framework does it assume?
It's React-leaning because that's what most Indian frontend roles use, but the reasoning — rendering, state, performance, accessibility — transfers to Vue or Angular. Bring examples from whatever you actually use.
I'm mostly self-taught with projects. Is that enough?
Yes. A project you can explain in depth beats a certificate here. The interview targets the 0–3 year range and rewards understanding over titles.
How long is it?
The free taster is about five minutes across three areas. A full rehearsal runs 15 or 30 minutes and reviews every question afterwards.
What does a frontend interview actually assess?
Whether you understand the language and the browser underneath the framework, and whether you build for the states nobody drew. The fundamentals round is deliberately framework-independent — closures, the event loop, promise ordering — because teams migrate frameworks and keep the people. The round that decides most outcomes is the component build, and it is not scored on how much you finished: a component that handles loading, empty and error states incompletely scores above a polished happy path, because the missing states are what turns into production bugs. Accessibility gets one question, and the expected first answer is the semantic element, not an ARIA attribute.
Related interviews
How to rehearse this exact thing
The questions you should ask before you build anything
The rehearsal hands you a deliberately loose interface spec and follows up on what you never clarified. The report names the states you never asked about.
Explaining a render out loud, with no diagram
Frontend reasoning leans on pointing at things, and a spoken round removes that. The report shows where your explanation stopped being followable.
The accessibility answer that starts with semantics
You get the one accessibility question a real loop asks, with the follow-up that separates a memorised list from an understanding. The report quotes your opening back to you.
Ready to rehearse for real?
Start a free five-minute Frontend Engineer interview now. You’ll get a spoken interview with live follow-ups and a feedback report that quotes your own answers back.