What Do Frontend Engineer Interviews Actually Test?

Who you'll actually talk to

A frontend engineer interview loop usually runs through three or four distinct conversations, and each one is checking something different. A recruiter screen first, mostly logistics and range. Then a hiring manager call, which is really about whether you can describe your own work clearly — what you built, what you owned, what you'd change. Then one or two technical rounds, usually with a working engineer from the team you'd join, sometimes two engineers in the same call so one can watch while the other drives. For senior roles there's often a separate architecture or system design conversation, sometimes with a staff engineer or tech lead who won't be your manager. If there's a take-home exercise, the review of it is a distinct round in itself — someone reads your code before you ever speak to them, and the follow-up conversation is built entirely around your decisions, not the fact that it ran.

The person running the technical round is almost never HR. That matters, because the questions stop being about your CV and start being about whether your explanations hold up when someone who does the job pushes on them.

The technical screen: what it's checking

Most technical screens for this role sit on shared editors — CoderPad, CodeSandbox, a shared VS Code Live Share session — and cover a mix of vanilla JavaScript and framework-specific work. A common pattern: a small vanilla JS exercise first (write a debounce, flatten a nested array, implement a simple event emitter), then a component task in whatever the team actually uses — React, Vue, Svelte. The vanilla part exists precisely because frameworks hide fundamentals. An interviewer who has you write debounce by hand isn't testing whether you can write it from memory; they're checking whether you understand closures and the event loop well enough to reason about why debounce needs them, which shows up the moment they ask "what happens if the user unmounts the component while the timer's still pending?"

On the framework side, a typical task is: build a small piece of UI with state, an API call, loading and error states, and maybe a list with keys. What's being scored is rarely whether it renders. It's whether you handle the boring parts — race conditions if the API call resolves out of order, what happens on an empty list, why you put the key on the list item and not the index. A candidate who gets a working component but can't explain why they used key={item.id} instead of key={index} has produced output without understanding, and that gap is exactly what this round exists to find.

CSS and layout: the part people underprepare for

Frontend interviews still test CSS directly, often separately from JavaScript, because it's the part candidates most often fake their way through with a framework's utility classes. Expect to be asked to lay something out with Flexbox or Grid live, on a whiteboard or in a shared editor, sometimes with no framework and no preprocessor. The real question behind "how would you centre this" is never centring — it's whether you understand the box model, stacking contexts, and specificity well enough to fix a layout bug you've never seen before, on a page you didn't write, under a bit of time pressure. "Why would you reach for Grid here instead of Flexbox" is a judgement question. There's a real, defensible reasoning to it — Grid for two-dimensional layout, Flexbox for one axis with content-driven sizing — and an interviewer who works in this daily will notice immediately if you're repeating a rule you read rather than one you've actually applied.

The questions that sound like conversation but aren't

A few questions recur across frontend loops precisely because they're hard to answer well without real experience, however smooth they sound as small talk:

• "Walk me through what happens from typing a URL to the page appearing on screen." This is checking whether you understand DNS, the request/response cycle, parsing, the critical rendering path, and where things like render-blocking scripts or defer/async fit. A shallow answer stops at "the browser fetches the HTML and renders it." A real answer mentions the difference between parsing and rendering, why CSS blocks rendering and JS can block parsing, and where hydration fits if the app is server-rendered.
• "Tell me about a memory leak you've debugged." This one filters fast. People who've actually done it name the tool — Chrome DevTools' Memory tab, a heap snapshot, detached DOM nodes, an event listener never removed on unmount — and describe a specific fix. People who haven't say "I'd check for memory leaks in the code" and go no further.
• "Why did you choose [Redux / Context / Zustand / whatever you used] for state here?" The interviewer already knows the answer to "what does Redux do." They're asking whether you weighed it against alternatives for that specific problem — was the state shared across many distant components, did you need time-travel debugging, or did you reach for it out of habit. "Redux is good for global state" restates a fact everyone in the room already knows.
• "How would you make this list keyboard-navigable / how would a screen reader read this component?" Accessibility questions are a strong signal round because so few candidates have actually used a screen reader or read WCAG beyond a blog summary. Naming ARIA roles you've memorised without explaining what native HTML element would have made them unnecessary reads as surface knowledge, not practice.

What a shallow answer sounds like from the inside

Someone who reviews frontend candidates regularly can hear a rehearsed answer within a sentence or two. It tends to have three features: it names the tool without describing the mechanism ("React uses a virtual DOM for performance" with no mention of reconciliation or when diffing actually helps versus when it doesn't), it treats a tradeoff question as a factual one ("CSS-in-JS is better because it's scoped," with no acknowledgement of runtime cost or build-time alternatives like vanilla-extract), and it can't survive one follow-up question. If you say "I improved load time," and the honest next question — "by how much, and what did you measure it with, Lighthouse or something else?" — makes you go vague, that's the gap the interview was built to find. The same applies to security basics: naming XSS and CSRF is not the same as explaining why React escapes values by default and where that protection stops (raw dangerouslySetInnerHTML, third-party scripts, innerHTML from an API response).

The contested bit: algorithms and take-homes

There's genuine disagreement inside the industry about whether frontend engineers should face LeetCode-style algorithm rounds at all, given the job is mostly UI, state, and browser behaviour rather than data structure design. Some companies keep them because they're easy to score consistently across candidates; others have dropped them in favour of pairing on realistic UI tasks, arguing the algorithm round measures interview practice more than job skill. Neither view has settled the argument, and you'll meet both kinds of interviewer, so it's worth asking the recruiter directly what the technical round actually contains rather than guessing. Take-home exercises have a similar split: some teams use them to respect candidates' time relative to live coding, others have abandoned them because unpaid multi-hour exercises filter out people with less spare time rather than less skill. If you're given one, the follow-up conversation about it usually matters more than the exercise itself — expect to be asked why you structured the components the way you did, not just whether it works.

What to do next

Read the actual job advert again and note every framework, tool, and pattern it names — React versus Vue, TypeScript, a specific state library, SSR versus CSR, a design system. Interviewers ask about what's on the page in front of them. Pick two or three of your own past projects and rehearse, out loud, the specific tradeoffs you made in each — not what the project did, but why you chose one approach over the alternative you didn't take. Practise explaining one real debugging session in detail, naming the tool you used. If CSS layout questions make you nervous, spend an hour building a layout with Grid and Flexbox from nothing, no framework, until you can explain the choice without checking anything.

jobmarket.pro reads the advert for you, matches it against your actual project history, and prepares the application from that — so what goes in front of the interviewer already lines up with what you can defend when they push on it.