# Frontend engineering interview preparation: JavaScript, browser, and UI Anchor your preparation in the role's stack, then practise explaining JavaScript behaviour, how the browser renders and where work is expensive, component design in your framework, how you measure and improve performance, and how you make interfaces accessible. Explain trade-offs aloud; implementation claims you cannot justify are a common failure mode. About 6 min read. ## On this page - [Anchor preparation in the role's stack](https://preprole.com/guides/frontend-engineering-interview-preparation#scope) - [Explain JavaScript behaviour, not just syntax](https://preprole.com/guides/frontend-engineering-interview-preparation#javascript) - [Know what the browser does with your code](https://preprole.com/guides/frontend-engineering-interview-preparation#browser) - [Discuss component design as API design](https://preprole.com/guides/frontend-engineering-interview-preparation#components) - [Treat accessibility as a correctness topic](https://preprole.com/guides/frontend-engineering-interview-preparation#accessibility) - [Speak about performance with measurement attached](https://preprole.com/guides/frontend-engineering-interview-preparation#performance) - [Rehearse explanations with a visible artifact](https://preprole.com/guides/frontend-engineering-interview-preparation#practice-plan) ## Anchor preparation in the role's stack Frontend interviews split roughly into JavaScript fundamentals, browser and rendering knowledge, framework-specific questions, and practical UI building. The mix depends on the team: a design-systems role weights accessibility and component API design, while a product role may weight state management and data fetching. Read the job post for the named stack and ask the recruiter which format to expect before dividing your preparation time. Do not let framework vocabulary substitute for fundamentals. Interviewers regularly test whether you understand what the framework abstracts: event handling, rendering, and network behaviour. If you can explain a React effect in terms of what the browser is doing, you can adapt to a different framework question. If you can only repeat hook rules, a small twist breaks the answer. ## Explain JavaScript behaviour, not just syntax Expect questions on closure, this binding, prototypal behaviour, event-loop ordering of synchronous code, microtasks and macrotasks, and the difference between == and === in the places it actually bites. The interviewable skill is predicting behaviour on a snippet and explaining why, not listing features. Practise by reading a short snippet aloud and tracing it line by line, naming what prints and in what order. Then change one thing, such as moving an await or wrapping a callback, and re-trace. That variation exercise is what the follow-up questions feel like. If you get a prediction wrong, say what you now understand rather than defending the first answer. - Event loop: what runs synchronously, what queues, and in which order - Closures and scope: what a function captures and when it surprises - Equality and coercion: where implicit conversion changes a result - Async: what await actually pauses and what it does not ## Know what the browser does with your code A senior-sounding frontend answer connects code to rendering: parsing, layout, paint, and where JavaScript blocks or batches that work. You do not need to recite the full pipeline, but you should explain why forced synchronous layout is expensive, what requestAnimationFrame is for, and why long tasks freeze interaction. Also prepare the network layer candidates forget: caching headers at a practical level, what debouncing a request saves, and how you'd diagnose a slow first render with the tools you actually use. Interviewers want the debugging story you would follow, not a performance checklist. ## Discuss component design as API design When asked to build a component, treat its interface as a decision: what props it takes, what state it owns versus receives, and how consumers extend it. Naming that boundary aloud before writing code is itself part of what is being evaluated. Prepare to compare controlled versus uncontrolled components, lifting state versus composition, and render props versus children in your framework of choice. The strong version of each answer includes when you would not use the pattern. A component that does everything via props is not flexible; it has just moved complexity to the consumer. ## Treat accessibility as a correctness topic Accessibility questions are increasingly part of frontend evaluation, and a dismissive answer is a visible signal. Know the practical core: semantic elements before ARIA, keyboard operability for anything clickable, focus management in dialogs, labels for form controls, and contrast that survives real displays. If you implemented accessibility work, prepare the specific story: what was broken, how you found it, and how you verified the fix. If you have not, say what you would check first rather than pretending expertise. Reviewers can distinguish tested claims from recited guidelines quickly. ## Speak about performance with measurement attached A credible performance answer starts with how you would measure: what the user experiences, which tool shows it, and what you would change first. Candidates who jump to memoization or code splitting before identifying the bottleneck signal that they optimise by pattern-matching. Have one real example ready: a slow interaction you profiled, what the bottleneck turned out to be, and what improved after the change. If the interview asks hypothetically, walk the same reasoning aloud. The measurable claim is always stronger than the theoretical one. > The list re-rendered on every keystroke because the filter ran inside the render path and every row subscribed to the store. I memoized the filtered result and moved row subscriptions to a derived selector, then re-measured: input latency dropped enough that the interaction felt immediate. The point was measuring first, not guessing which optimisation mattered. ## Rehearse explanations with a visible artifact Frontend answers improve fastest when you practise on real artifacts: a component from a project you built, a snippet you trace aloud, a performance trace you narrate. Choose two or three and rehearse the explanation, not just the implementation. The interview rewards the narrated reasoning. Keep a gap list. Frontend spans wide enough that nobody covers it all; interviewers accept a stated boundary far better than a bluff. If a question lands outside your experience, say what you would check first and how, which turns a gap into a demonstration of how you learn. ## Frequently asked questions ### Do frontend interviews still ask algorithm questions? Many do, especially at larger companies, though often at a different depth than backend rounds. Confirm with your recruiter. Prepare fundamentals either way; they transfer. ### Which framework should I say I use? The one named in the job post that you can defend in depth. A shallow answer in the fashionable framework loses to a confident, well-reasoned answer in the one you actually shipped. ### How much CSS do interviews really test? Enough to check whether you can build the layouts the role produces: flexbox and grid behaviour, positioning, and responsive strategy. Knowing when and why layout breaks matters more than memorising property lists. ### What if the live-coding environment is unfamiliar? Ask what is available before you start and say what you would do differently in your normal setup. Interviewers account for environment friction; what they watch for is whether you stay communicative when the tooling fights you. ## Practise the next answer Use a Technical Deep-Dive Mock Session to rehearse explaining a UI you built: the rendering model, the state approach, and one performance or accessibility decision. Where a session includes the Code Pad, the AI Interviewer reads it but never executes code, so verify implementations and browser behaviour in your own environment. Practise for your job: https://preprole.com/setup ## Sources and scope Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria. - [Atlassian: engineering interview handbook](https://www.atlassian.com/company/careers/resources/interviewing/engineering) - [Microsoft Careers: interview tips for all roles](https://careers.microsoft.com/v2/global/en/hiring-tips/interview-tips.html) ## Related guides - [Practise the live coding portion](https://preprole.com/guides/coding-interview-preparation) - [Prepare the full-stack questions that follow](https://preprole.com/guides/backend-engineering-interview-preparation) - [Rehearse explaining your own projects](https://preprole.com/guides/technical-deep-dive-interview) AI feedback can be wrong. A practice Verdict is not a hiring decision.