Frontend Engineer Interview Questions — Senior Level

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.

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.

The question is looking for a bus factor of one, and for whether you know that you are it.

The trap is to answer proudly. Indispensability sounds like seniority for about four seconds, and then it sounds like a team with a single point of failure that the candidate has been comfortable being.

So name the thing honestly — the build configuration, the one component every screen depends on, the release process that lives in your terminal history — and then spend the rest of the answer on what you have done to make it less true. The document you wrote. The person you paired through it. The part you deleted so it stopped needing an owner at all. That last one is the strongest ending available here.

Say early that a frontend incident is a different animal, because that sentence alone separates you from candidates reciting a generic runbook. There is no machine to log into, the errors come from browsers you cannot reproduce, and a page somebody already loaded stays broken no matter what you deploy.

The order: confirm it from real-user data rather than from the report — one screenshot in a channel is not an incident until the error rate says it is. Is it everyone or something? One browser, one locale, one route, one device class; that split narrows the search space fast, and it is where frontend incidents differ most from backend ones, because "only Safari" and "only Arabic" are both real answers. Was anything shipped? Your deploy, a dependency, a content change somebody made in a CMS, a third-party script that updated itself without asking you.

Then restore before you diagnose, and name the frontend versions of that: roll back the bundle, turn the feature flag off, and — the one that gets forgotten — deal with the cache. A rolled-back deploy that a service worker is still happily serving is not a rollback, and finding that out late in an incident is the kind of story frontend leads tell each other.

Keep a written timeline while it happens. Nobody remembers the order afterwards, and the post-mortem is only as good as the notes somebody took at the time.

Anyone can define one. The word doing the work in that question is enforced, and the answer wants three things: the number, where it was checked, and what happened the first time it failed.

Checked in the build, not on a dashboard — a budget that lives on a dashboard is a chart. Failing the build is what makes it a budget, and the first time it fails is the moment it either becomes real or quietly becomes advisory. Say who you had to argue with, because there will have been somebody, and the argument is the interesting part.

If you have never had one, say so and say what you would set first. A defensible first budget is a size cap on the initial bundle and a tail-latency number on a mid-range device, and knowing that is more convincing than a budget you cannot describe the enforcement of.

A management question wearing engineering clothes, and it is asked at this level because review latency is one of the few things a senior engineer controls that the entire team feels.

What is being tested is whether you treat review as your work or as an interruption to it. The answer that fails is any version of "I'd remind them to chase the reviewers," which puts the cost back on the person with the least power to fix it.

Name the real causes, because they are diagnosable. It is too big, so nobody wants to start it. It touches an area only one person understands and that person is busy. Or the first round of comments was long enough to read as a rejection, and the author quietly stopped.

Then say what you do about the class rather than the instance: a size at which you ask for it to be split before it is opened, a rule that the first pass happens same-day even if it is only "I've read it, here's the one thing that worries me", and marking which comments block and which are opinions. The last one costs nothing and changes how a junior reads every review they get from you afterwards.

The rule that survives contact with a real team: it goes in when it has been built the same way three times, not when somebody thinks it might be reusable. Reusability predicted in advance is how a shared library fills with components with eleven props and one consumer.

Then say the cost out loud, because that is the senior half. Anything in there is yours forever: every change is a breaking change for somebody, every consumer's edge case arrives at your door, and the version bump is now a coordination problem. That cost is worth paying for a button and not worth paying for a screen.

The tell you can offer as a finishing line: a design system with components nobody outside the owning team uses is not a design system, it is a hobby with a release process.

This is not really a framework question. It is whether you can plan work that cannot be finished in one release and cannot be abandoned halfway.

The shape: get onto the last minor of the current major first, so the deprecation warnings become your to-do list rather than a surprise. Read the actual upgrade notes and sort every breaking change into mechanical and judgement — the mechanical ones go in as their own reviewable commits, ideally one per kind, and the judgement ones go in front of the team before anybody writes code. Where the ecosystem allows both versions to run side by side, use that, because a migration you can pause is a migration that survives a quarter with other priorities in it.

The detail that reads as experience: find out about the abandoned dependency first — the one with no recent release. Whether it has a maintained replacement is the single fact that decides if this is a fortnight or a quarter, and discovering it late is how this work goes wrong.

Then say what you would tell the business, because you will have to. This buys no features. What it buys is security updates, the ability to hire people who know the current version, and not doing a much larger version of the same job in eighteen months. Say the number of weeks and say what you would stop doing to get them.

Your job is not to pick the better argument. It is to end the argument at a price the team can afford, and the interviewer is checking whether you know those are different tasks.

What actually settles it: which choice can be undone cheaply, which one the people who will maintain it can already read, and whether either is genuinely irreversible. Then decide, write down the decision with the reason and the date, and say that the reason is the part that matters — a team that can find out why can revisit it without relitigating it.

The failure being probed is the lead who lets it run because both positions are reasonable. Two weeks of a reasonable disagreement is more expensive than either option, and everyone downstream is blocked on a conversation they are not in.

No standard answer exists, which is why it is asked, and there is a very clear bad one: reciting a ladder document back at somebody who has read more of them than you have.

Answer from what changed in your own week, or from watching someone else make the step. The shape that holds up: senior is measured on what you deliver and on whether the people near you got better at delivering. The step after it is measured on problems that do not belong to any one team — the thing three squads each half-own, the decision nobody has authority to make, the migration that needs a person whose job is to care about it for six months.

Then say which one you are, out loud, and say what you are missing. Candidates reach for the higher description and are immediately asked for an example; a candidate who says "I'm solidly senior, and the part I haven't done is carrying a decision across teams who don't report to anyone I know" is more credible, and more hireable for it.

If your company has no such ladder, say that too, and describe the work instead of the title. That is a stronger answer than borrowing somebody else's ladder to sound calibrated.

This tells the room what you value faster than any answer about your own work, and it comes up once the title has senior in it, which catches candidates out.

Give two questions and say what each is for. Something diagnostic that cannot be revised for — a broken layout, a stuttering list — because it separates practice from reading. And something about a decision they now think was wrong, because it is the only reliable way to find out whether they revise.

The addition that lands: say what you would not ask, and why. Trivia with one right answer tests recall and correlates with nothing, and asking a candidate to implement a sorting algorithm on a whiteboard for a job that is entirely screens is a filter for people who prepared for the wrong interview.

Say the real number and do not apologise for it. Both extremes are answers a good interviewer can work with; what they cannot work with is a figure that contradicts everything else you have described about your last two years.

The question exists because saying yes to everything is the ordinary way a senior engineer becomes a slow one, and the people around them become blocked on someone who is always busy.

Name the thing, who asked, what you offered instead, and how it landed — including if it landed badly. "Nothing, we found a way to fit it all in" is not the answer being hoped for, and it is heard as either a very quiet quarter or somebody who has not yet had to choose.

A green build tells you the code compiled. It says nothing about a person in another country on a four-year-old handset, which is the population this question is about.

What you would look at: real-user timings at the tail rather than the average, the JavaScript error rate per session rather than per event, and one business number that says people are getting what they came for — a completed checkout, a submitted form, a played video.

Then the frontend-specific traps, and these are what the question is really fishing for. Your error reporting only sees the sessions where the reporting script itself loaded, so the worst-off users are systematically missing from your data. An ad blocker, an old browser or a bad network can each remove exactly the people having the worst time. And an average is a lie on a long-tailed device distribution — a page that is fine at the median can be unusable for the people on the slowest devices, and only the tail shows you that.

Finish with who gets told. A dashboard nobody is paged from is a dashboard, and naming what would actually wake someone up is the difference between having observability and having charts.

Something you championed that did not work · a rewrite you regret · a decision you would take back. One question, three angles, and at this level it is asked with more weight than it is at any other, because a senior engineer's wrong calls are expensive in a way a junior's are not.

The version that fails is the one where the failure turns out to be someone else's — the team did not adopt it, the business changed priorities, the deadline moved. Those things are all true and all of them are the answer to a different question.

Include four things: what you predicted, what actually happened, the moment you knew, and how long it took you to say so out loud. That last gap is what is being measured. Everyone has been wrong; the senior signal is a short distance between knowing and admitting, and a candidate who says "I knew in week three and I said it in week seven, and the four weeks were mine" has answered better than one whose story has no such number in it.

Then be specific about what you would change, because "communicate earlier" is the generic ending and it is worth nothing. "I'd have written the success criteria down before we started, so there was something other than my judgement to check it against" is a real change, and it is checkable.