How Frontend Interviews Work
Frontend interviews are broader than many people expect. You may be asked to build a UI component live, answer questions about the browser and JavaScript, debug a layout, write a utility function, and design a whole client-side system. This chapter maps the rounds, shows what each one checks, and gives a preparation plan you can follow before reading the rest of the track.
1. The rounds you will meet
| Round | What it checks | Typical prompts |
|---|---|---|
| JavaScript fundamentals | closures, this, prototypes, scope, equality, coercion, modules | "What does this snippet print?", "Explain closures." |
| Async and the event loop | promises, async/await, microtasks versus macrotasks, race conditions | "Order the logs.", "Implement Promise.all." |
| Utility coding | small, precise functions | debounce, throttle, deep clone, curry, memoise, event emitter, flatten |
| UI machine coding | building a component in 45 to 90 minutes | autocomplete, star rating, accordion, modal, tabs, todo list, infinite scroll, data table |
| HTML/CSS | layout, specificity, responsive design, centring, positioning | "Build this layout.", "Why is this element not centred?" |
| Framework knowledge (usually React) | rendering, hooks, state, effects, keys, performance | "Why does this effect run twice?", "When to use useMemo?" |
| Browser and performance | rendering pipeline, Core Web Vitals, caching, bundling | "Why is this page slow?" |
| Accessibility, security, testing | semantics, ARIA, XSS, CORS, unit and integration testing | "How would you make this dropdown accessible?" |
| Frontend system design | architecture of a real product | "Design a news feed", "Design a collaborative editor UI." |
| Behavioural | collaboration with design and backend, ownership, quality | standard STAR questions (see the HR track) |
Companies vary. Product startups lean toward machine coding and React; large companies add data structures and algorithms, plus system design; agencies emphasise CSS and accessibility.
2. What interviewers look for in a UI coding round
- Clarifying questions before typing: required features, edge cases, browser support, accessibility, data size.
- A plan: component breakdown, state shape, events.
- Working software first, then polish. Get a minimal version running in the first 20 minutes.
- Clean code: meaningful names, small functions, no duplication.
- Correctness at the edges: empty states, loading and error states, rapid clicks, long text, keyboard use.
- Semantics and accessibility: real buttons, labels, focus management, keyboard support.
- Communication: narrate trade-offs, not just keystrokes.
A good habit: after the basic version works, say "next I would handle loading and error states, keyboard navigation, and debouncing", then do as many as time allows.
3. The map of this track
| Chapter | Use it for |
|---|---|
| HTML, CSS and layout | semantics, the box model, flexbox, grid, specificity, responsive design |
| JavaScript core | scope, closures, this, prototypes, equality, modules |
| Async JavaScript | the event loop, promises, async/await, cancellation |
| Utility functions | the coding questions that come up again and again |
| Browser rendering and performance | the critical path, layout thrash, Core Web Vitals, bundles |
| React fundamentals and hooks | rendering model, effects, keys, memoisation |
| State and data fetching | where state lives, caching server data, forms |
| Accessibility | semantics, keyboard, ARIA, focus, testing |
| Web security | XSS, CSRF, CORS, CSP, token storage |
| TypeScript | types that help, generics, narrowing |
| Frontend testing | what to test and how |
| Frontend system design | a framework and worked examples |
4. A four-week plan
| Week | Focus | Output |
|---|---|---|
| 1 | JavaScript core and async; write the utility functions by hand | 15 snippets explained aloud, 10 utilities implemented |
| 2 | HTML, CSS, layout, accessibility; rebuild three real page layouts | three responsive pages, keyboard-checked |
| 3 | React and state; build five components (autocomplete, modal, tabs, infinite list, form) | working code with edge cases |
| 4 | Performance, security, testing, system design; mock interviews | two timed machine-coding rounds, one design walkthrough |
Throughout, practise without autocomplete in a plain editor, and say your reasoning aloud.
5. Answering conceptual questions well
A reliable structure:
- Define it in one sentence.
- Show a tiny example.
- Say why it exists (the problem it solves).
- Name a pitfall or when not to use it.
For instance, "What is a closure?" A closure is a function together with the variables from the scope where it was created. function counter(){ let n = 0; return () => ++n; } keeps n alive. It lets you create private state and callbacks that remember context. The classic pitfall is capturing a loop variable declared with var, so every callback sees the final value.
6. Common mistakes
- Coding immediately without clarifying.
- Ignoring semantics: a
divwith a click handler instead of abutton. - No keyboard path in a component.
- Memorised answers with no ability to reason about a variation.
- Premature optimisation (
useMemoeverywhere) with no measurement. - Not handling the empty, loading and error states.
- Treating the framework as the whole of frontend, and not knowing the browser underneath.
7. Practice questions
- Describe the last UI component you built from scratch and its trade-offs.
- What happens between typing a URL and seeing a page?
- What are the differences between
var,letandconst? - How would you build an accessible modal?
- Explain the event loop in two minutes with an example.
- How do you decide where state should live?
- What would you check first on a slow page?