Frontend Engineer Interview Questions

Say the boundary out loud in the first sentence. "I owned the checkout flow — three screens, the address form and the payment step. I did not build the payment integration itself." That single move separates you from the majority of the shortlist, because most people answer this in "we".

Then pick one thing that was hard and say why it was hard. Not the feature list. The hard part — the form that had to keep half-finished input across a page refresh, the table that had to stay usable at four hundred rows, the component two other teams also depended on so you couldn't change its props.

Interviewers are listening for scope and for honesty about it. Overclaiming is caught in the technical round twenty minutes later, and it costs more than the smaller true answer would have.

Answer in one sentence and move on. The long answer always sounds like a grievance no matter how carefully it is worded.

Something about the work is safest and usually true: "I've been maintaining the same admin panel for two years and I want to be closer to a product people actually use." Do not describe a manager. Do not describe a salary, even if the salary is the reason — that conversation has its own question and this is not it.

Give a range with a floor you would actually accept, and say what the range is anchored on — the local market, the market for the client's country, or the currency you're paid in. Those are three different numbers for the same job and this role is the one where they diverge most.

If you're working from your own market for an employer based in another, the honest position is that you're being paid against a third market. Say which one you're quoting. A number with no stated basis reads as a guess, and it invites the employer to supply the basis themselves.

One thing you're entitled to ask before you answer, and asking it costs nothing: what band is this role in, and what does the band top out at?

The trap is claiming full-stack because the job ad says it. Name the layer you would be trusted with unsupervised, then name the one you can work in with review. Two honest sentences beat one impressive one.

Answer factually and completely in one pass — status, transferability, and the realistic date you could start. Employers ask because a transfer and a fresh visa are different problems with different timelines, and a vague answer here is read as an attempt to postpone a bad fact.

If your position is awkward, say the awkward thing plainly and immediately follow it with the date. An employer can plan around a date. They cannot plan around ambiguity.

In markets without statutory pay-transparency rules this is asked directly and is not considered rude. In markets with them, applicants have a right to pay information for the role before the interview and employers are not to ask about pay history — the universal screening guide covers the scope of that properly, and it is narrower than people assume.

Practically: know your all-in number including housing and transport allowances, because where the package is split that way the base salary alone understates it badly, and an employer comparing your base against their total package will "beat" your current pay while cutting it.

Ask what the role actually requires before you answer: full relocation, a rotation, or three onsite days a quarter. Those are different lives and the job ad usually says only one word about it.

The wrong move is to start naming optimisations. The right move is to measure, and to say so before you do anything else.

Order it: confirm the re-render is real with the framework's own profiler or a render counter, because half the time the slowness is elsewhere entirely and you are about to optimise a component that was never the problem. Then find what changes identity on every keystroke — an object or function or array created inline in the parent, a context whose value is a fresh object each render, a key that isn't stable. Then ask whether the state is in the right place at all: input state that lives three levels above the input is the single most common cause of this, and moving it down beats memoising anything.

Only after those three would I reach for memoisation, and I would say why out loud — memoisation has a cost, it can be defeated by an unstable dependency, and a memo wrapped around a component whose props genuinely change every render is pure overhead with a comment on top.

The answer that impresses is the one where you name the thing you would check and what result would make you abandon that line.

Start from who needs to read it. State that only one subtree reads belongs in that subtree. State that two siblings need belongs to their nearest common parent. State that survives navigation, or that must match what the server thinks, is not really component state at all — it's cached server data or it's the URL, and treating it as component state is how you end up writing a sync loop nobody can debug.

Say the URL part explicitly. Filters, tabs, pagination and search terms belong in the URL because a user expects to share and reload them, and half the state-management pain in this job comes from having learned that late.

Asked open-ended on purpose; how far you get is the measurement. The spine: the event fires and your handler runs on the main thread, sets state, which schedules work rather than doing it; the framework computes what changed and writes to the DOM; the browser recalculates styles, computes layout, paints and composites. Some property changes skip layout; some force it.

The part worth landing is the one with consequences: reading a layout value immediately after writing one forces synchronous layout, and doing that inside a loop over a list is how a smooth page becomes a stuttering one. And if you don't know a stage, name it and say so — a confident wrong sequence costs more, and the interviewer already knows which parts you're guessing at.

By measuring, and by saying what the threshold was. The honest answer is that most components do not need it and that the cost of memoising everything is a codebase where nobody can tell which optimisations matter.

Two cases are worth naming as genuinely justified: an expensive derived computation over a large collection, and a value passed to a memoised child where identity stability is the entire point. Everything else is "I profiled it and it was measurable."

Windowing — render only the rows in view plus a buffer — is the expected answer, so get there quickly and then spend your time on what it costs. Variable row heights break naive windowing. Search and keyboard navigation inside a windowed list need care because the target row may not be mounted. Accessibility gets harder because assistive technology cannot see rows that aren't there, which is what the row-count attributes exist for.

The stronger version of the answer asks a question back: does the user actually need five thousand rows, or do they need to find one? Pagination and better filtering solve the same problem without any of the cost, and proposing that first is a product instinct interviewers notice.

Two failures live here and a good answer names both. The response arrives and writes to a component that is gone. And two responses arrive out of order, so the older one wins and the screen shows results for a query the user has already replaced.

Cancellation handles the first — an abort signal tied to the effect's cleanup. The second needs a sequence check or a request key, because cancellation is best-effort and a race can still resolve backwards. Say the second one; most candidates only say the first.

Answer in terms of what you assert, not which library you use. Test what the user can observe — the text on the screen, the accessible role and name of the control, what happens after a click — and never assert on internal state or class names, because a test that breaks when you rename a CSS class is a tax with no benefit.

Then name the boundary: unit tests for logic with no DOM, component tests for behaviour, and a small number of end-to-end tests for the flows whose breakage would be an incident. Say the number is small and say why — they're slow and flaky, and a suite people ignore is worse than no suite. Asked what you'd test first in an untested codebase, the answer is the flow that makes the money, not the file that looks worst.

Say where validation lives and when it runs, because that is the actual question. Validate on blur rather than on every keystroke for anything a person is still typing; show errors after a field has been touched, not before; and never let the client be the only place a rule exists, because the server will be handed the request directly sooner or later.

Then mention the two things that get skipped and that a reviewer will look for: what happens when the submit fails halfway, and whether the form is usable with a keyboard alone.

Because something took up space after the fact. Images and embeds without dimensions reserved, a web font swapping in at a different metric, content injected above what's already rendered, an ad or banner slot that grows.

The fix is boring and worth saying plainly: reserve the space in advance — width and height or an aspect ratio on media, a fixed container for anything asynchronous, and font loading configured so the fallback and the real face are close enough in size that the swap doesn't reflow.

Because z-index only orders siblings inside the same stacking context, and an ancestor with a transform, a filter, or an opacity below one has created a new one. The element is at the top of a box that is itself underneath. Say that, then say you would look up the tree rather than raise the number.

One call stack, a queue of tasks, and a separate microtask queue that is drained completely after each task and before the browser renders. Promise callbacks are microtasks; timers and most events are tasks.

The consequence is the part worth saying, because it's why the question is asked: a promise chain that never yields will starve rendering just as effectively as a long loop, and awaiting something that resolves immediately does not give the browser a chance to paint.

That the browser made the request, got a response, and refused to hand it to your code because the server did not say your origin was allowed. It is a server configuration answer, not a client one — which is why nothing you change in the fetch call will fix it, and why the proxy people reach for is a workaround rather than a solution.

This one rewards first-hand experience of mid-range hardware and weak networks, and it is worth preparing properly wherever your users are on exactly that device on exactly that connection — a page tuned on a laptop over office wifi has never met them.

Work in order of what actually costs: ship less JavaScript — split by route, defer anything not needed for the first screen, and check whether a dependency is worth its weight rather than assuming it is. Send images that fit the device, in a modern format, with dimensions reserved. Get the first meaningful paint off the server rather than after a bundle downloads, parses and hydrates.

Then say the thing most candidates don't: parsing and executing JavaScript is the expensive part on a slow device, not downloading it. A 300KB bundle on a fast connection and a weak CPU is still a frozen page for a second and a half. Finish with how you'd know — throttle the network and the CPU in the browser's own tooling, and test on a real mid-range handset rather than a simulator.

Be concrete or don't answer. The generic version of this answer — that accessibility is important and we should follow the guidelines — is worth nothing and every interviewer has heard it forty times.

Concrete looks like: every interactive thing is reachable and operable with a keyboard alone, and the focus ring is visible rather than removed. Every control has an accessible name that isn't just an icon. Colour is never the only way information is conveyed. Headings are in order and describe the structure rather than being chosen for their size. Form errors are associated with their fields and announced, not just coloured red. Anything that appears on top — a dialog, a menu — traps focus while it's open and returns it when it closes.

The best single answer to this question is a story: something you found because you actually tried to use your own screen with the mouse unplugged, or with a screen reader on for ten minutes. "We ran an automated checker" is a weaker answer than it sounds, and saying so out loud — that automated tools catch a minority of real problems — is a mark of someone who has done it.

Go to the designer with a specific cut, not with the problem. "The animated transition is two days and the rest is one. Ship it without the transition and add it next sprint, or drop the filter panel and keep the animation." Two options and a recommendation.

The failure interviewers are listening for is the engineer who either silently builds a worse version of it or silently misses the date. Both are decisions taken alone that were not theirs to take alone.

Yes, in one place, at the boundary — and then go and ask for the API to change. Both halves matter. Reshaping scattered through components is how a shape becomes permanent; reshaping in one adapter keeps the cost visible and the change cheap when the endpoint improves.

Say when you would not ask: if the endpoint serves three other consumers who are happy with it, the awkwardness is yours to absorb, and knowing which case you're in is the actual judgement being tested.

There is no answer they want and there is definitely an answer they don't want, which is a ranking. What is being tested is whether you can hold a preference without being religious about it.

Decide out loud from constraints: what the team already knows and can hire for locally, whether the product needs to be indexed by search engines or is behind a login, how much of it is genuinely interactive versus mostly content, and what the rendering requirement is on a slow device. Then name your pick and, in the same breath, name what it costs you.

The single strongest thing you can add: say what would change your mind. "If most of the team came from a different ecosystem I'd pick theirs, because a framework I like and nobody can review is worse than one I tolerate." That sentence is what a lead sounds like. And if you have only ever worked in one, say so — faking breadth is caught in one follow-up question.

Ship the deadline first, and say that plainly — an engineer who arrives and starts a refactor is a real hiring risk. Then: get the app running locally and write down every step that was undocumented, because that list is the highest-value thing you will produce in week one. Add tests only around what you are about to change, so the tests are load-bearing rather than decorative.

Name the trap: the code that looks worst is usually the code that has survived contact with the most edge cases, and rewriting it is how you reintroduce five years of fixed bugs.

Ask the policy before you start the exercise, not after. Employer positions on this differ sharply — some ask candidates not to use assistance at all during an assessment, some allow it in preparation but not in the room, some actively want to see how you use it. Nobody minds being asked; plenty of people mind finding out afterwards.

When it is allowed, the thing being measured is not whether you used it. It is whether you can tell the difference between output that works and output that only looks like it works. So narrate the review, not the generation: which part you took as written, which part you rejected and why, what you tested about it, and where you checked the documentation because you weren't sure.

The answer that fails is either extreme — pretending you write everything unaided in a job where nobody does any more, or handing over code you cannot defend line by line. Both are the same failure wearing different clothes: claiming ownership you can't back. So say what you don't delegate. Almost everyone who has thought about this has a line — the security-sensitive part, the thing that touches money, the code review itself — and naming yours is a strong answer.

Pick one that reached users and that you found or fixed. The instinct is to choose something small and safe; the small safe one is exactly the answer that sounds rehearsed.

Either side is fine, but the version where you were the reviewer is more revealing and fewer people tell it. What's being checked is whether you can separate a disagreement about code from a disagreement with a person.

The useful shape: what the actual technical disagreement was, what you did when the comment thread passed about four replies, and what the resolution was. The correct move at four replies is a fifteen-minute call, and saying so is a small thing that reads as experience.

Do not answer this as a complaint, which is the trap it is set as. Answer it as a process question: when you get involved (before the design is final, not after), what you flag early (the states nobody drew — empty, loading, error, too-long text), and what you agree is frozen once build starts.

Name one specific thing and what you built with it. A course you started counts for nothing; a small thing you finished counts for a lot, even if it is ugly.