Frontend Engineer Interview Questions — Entry 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.

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.

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.

This is not the same question as "what have you built." They are going to read it with you, and the measurement starts the moment you scroll.

Pick the project you can still explain, not the one that looks best. A plain list you understand completely interviews better than an ambitious app assembled from four tutorials whose folder structure you cannot navigate under mild pressure.

Before the call, open it yourself and find the three places you would be embarrassed by. Have a sentence ready for each: what it does, why it ended up like that, what you would change now. An interviewer who finds one first and gets a shrug has learned something. One who is told about it before they ask has learned something better.

Asked gently, and it is not a gentle question. It is the fastest way to find out whether a portfolio is a record of work or a record of following instructions.

Answer it straight, because tutorials are how this work is learned and the room knows it. What loses the job is the claim, not the copying.

The strong version names the source and then names the departure: which video or template you began from, what you changed, and what forced the change. A candidate who says "the layout is the course project, the filtering is mine because the course version refetched everything on every keystroke and it was unusable on my phone" has just described engineering. The tutorial is no longer a liability; it is the baseline the work is measured against.

For a junior frontend role, expect a screen rather than a puzzle: a list you can filter, a form that validates, a panel that opens and closes and returns focus properly.

What is scored is the narration, not the finish. Say what you are about to do before you do it, say when you are stuck, and say when you are guessing. Silence is read as not knowing, even when you are simply concentrating.

One practical move that buys you the whole exercise: ask what happens when the list is empty, and what happens when it is long. Neither is in the brief, both come up in real work, and asking is how you convert a coding test into a design conversation you can win.

const by default, let where the value genuinely has to change, and var in nothing you wrote this decade. If they push, the textbook difference is scope and hoisting; the difference that matters at a keyboard is that const removes a whole class of accidental reassignment before it exists.

They are checking whether you learned HTML or skipped past it on the way to a framework, and the answer that lands is three concrete things rather than a definition. Assistive technology gets the page's structure without being told. Keyboard behaviour arrives free with the real elements. And the outline is what a search result or a share preview is built from.

Then give the concrete example: the div with a click handler on it. It looks identical, and it silently loses keyboard focus, the Enter and Space behaviour, and the announcement that this thing is a button at all. Saying that you have shipped one and had to go back and fix it is a better answer than any list.

Content, then padding, then border, then margin, from the inside out. By default a width applies to the content alone, so padding and border are added on top — set a width of 300, add 20 of padding either side, and you have a 340-wide box and a layout that wraps one column early.

border-box makes the width mean the whole box, padding and border included, which is what people expect the first time and why it is worth setting once at the top of the stylesheet. Say that you set it globally and stop thinking about it. Pretending you calculate it per element reads as revision rather than practice.

The most useful question on a junior CSS screen, because there is no way to revise for it. Either you have argued with a layout or you have not.

Go in order and say the order out loud. What is the parent's display — because if it is block, the children are stacking and nothing you do to the children fixes that. Then the children's own display, since an inline element ignores width. Then: has something been floated or positioned absolutely, which takes it out of the flow entirely. Then the arithmetic — a width plus a gap plus a margin that exceeds the container will wrap, and it will look like a mystery until you add the numbers up.

Now the part that separates someone who has done this: say you would open the inspector rather than keep guessing, and say which panel. The computed styles, and the box diagram beside them, will tell you in four seconds what the stylesheet takes four minutes to reason about. Naming the tool and what you look at in it is the answer; reciting properties from memory is not.

Timing is where junior bugs live, so this question is really asking whether you can reason about what has and has not happened yet.

A promise is a value that is not here yet, with a hook for when it is: pending, then either fulfilled or rejected, once, permanently. `await` pauses that function at that line and hands control back — the rest of the program keeps running, the browser keeps painting. Say the second half. It is the part that gets left out, and it is the part that explains why your loading spinner works at all.

Two follow-ups are waiting behind it. An error inside an awaited call throws at the line where you awaited, so it needs a try/catch or a rejection handler and it will not be caught by anything wrapped around the original call. And awaiting inside a loop makes the calls happen one after another — which is correct when each depends on the last, and is a page you accidentally made much slower when they do not.

Two panels, in order. The network tab to confirm the response actually arrived and to look at its real shape rather than the shape you assumed. Then the console, for the error you scrolled past.

Three causes are worth naming because they are the ones you can check fastest: the payload is nested a level deeper than the code expects, so the array you are mapping is undefined; the render ran before the data landed and nothing told it to run again; or the rows render and are invisible because the key or the field name is wrong and every row is empty.

Then say the habit: log the value where it is used, not where it is fetched. Saying it out loud shows you have done this rather than read about it.

Do you use git · what is a merge conflict and what do you do with it · what actually goes in a pull request. These are one question in three costumes, and it is not about git. It is whether you have ever worked alongside another person.

Answer with what you have actually done. If your history is forty commits all called "update", say so and say what you would do differently, because an honest small history beats a claim about a workflow you have not used. A conflict is not a failure, it is two people editing the same lines and being told about it before it ships — read both sides, keep what belongs, and run the thing before you commit the resolution.

The pull-request part is the one worth preparing properly, and it is the one that transfers to the job on day one. A title that says what changed. A description that says why, in two sentences a stranger can follow. A line about what you tested and what you did not. On a distributed team that description is the visible product of your week, and a reviewer who has to open the diff to find out what it does has already been slowed down by you.

The highest-signal question in a junior interview, and the easiest one to walk into unprepared.

What is being measured is how long you struggle before you ask, and whether the ask is answerable. Both are expensive to get wrong, and a manager hiring a junior is buying an unknown on exactly this axis.

So give the sequence with a clock on it. Read the error properly rather than skimming it. Reproduce it in the smallest file that still shows it. Check the documentation for the exact function rather than a blog about the general topic. Search the exact error string. Then ask — and put a wall-clock limit on that whole loop, an hour, and say the number, because the number is the answer.

Then the half that gets left out: what a good ask looks like. What you expected, what happened instead, what you already tried, and a link to the code. Someone who arrives with that gets an answer quickly; someone who arrives with "it doesn't work" gets a conversation first, and everyone learns to dread the message.

Asked everywhere, and asked more directly where the route into this job runs through bootcamps, courses and unpaid client work as well as through a computer-science degree.

It is not hostile. They have already chosen to interview someone without the standard credential and they are asking what they get instead — so the answer is evidence, not reassurance.

Decide this before you are asked, because the room is a bad place to work out where your line is.

The distinctions are worth holding separately. A paid probation is an ordinary employment term. A scoped take-home of a few hours is a reasonable ask. Two unpaid weeks on something that ships is not a trial, it is work, and the word trial is doing a job in that sentence.

What to say: ask what the trial produces, whether it is paid, how long it runs, and what decision it feeds. "I'll do a day, unpaid, on something that isn't going into the product" is a complete position and it is reasonable in both directions. If they will not put a length or a decision on it, you have your answer about how the company will treat your time once you are inside it.