Mock Interview Copilot Interview questions by role
Frontend developer interview questions
Frontend developer interviews test three things: whether you understand how the browser actually works (the DOM, the event loop, rendering, the network), whether you can build interfaces that are fast and accessible for real users, and whether you can work well with designers and backend engineers. Expect questions on JavaScript fundamentals, a framework such as React or Vue, performance, accessibility and a project you built.
How the interview usually runs
Most processes start with a recruiter call, then a technical screen that is often a small UI task: build a component, fetch some data, handle loading and error states. Later rounds go deeper on JavaScript behaviour, framework internals, CSS layout and a discussion of past work. Some companies give a take-home and then ask you to walk through it and defend your choices.
The spoken part of the interview is where frontend candidates often stumble. Many can build the component but cannot explain why a page feels slow, how a screen reader would experience their form, or why they chose local state over a global store. Those explanations are what separates a mid-level hire from a junior one.
Common questions and what the interviewer is checking
What happens between typing a URL and seeing the page?
What they are checking: A mental model of the browser: DNS, the request, parsing HTML, building the DOM and CSSOM, layout, paint, and where JavaScript blocks rendering. Depth matters less than a clear order.
Explain the event loop. Why does a long-running function freeze the page?
What they are checking: That you know JavaScript runs on one main thread, how tasks and microtasks are queued, and practical fixes such as breaking up work or moving it to a web worker.
A page feels slow. How would you find out why?
What they are checking: A measuring-first approach: the performance panel, Lighthouse or Core Web Vitals, the network waterfall, bundle size, re-renders. They want diagnosis before fixes.
How do you make a custom dropdown or modal accessible?
What they are checking: Real accessibility knowledge: semantic elements first, keyboard support, focus management, ARIA only where needed, and testing with a screen reader rather than guessing.
When would you reach for a global state library, and when would you avoid one?
What they are checking: Judgement rather than habit. Good answers distinguish server state, URL state and local UI state, and admit the cost of extra libraries.
Why does a React component re-render, and how do you stop unnecessary re-renders?
What they are checking: Understanding of props, state and context changes, plus the restraint to measure before adding memoisation everywhere.
How do you handle a design that is hard to build or does not work on mobile?
What they are checking: Collaboration with designers: raising the problem early, proposing alternatives, and explaining constraints without dismissing the design.
Tell me about a UI bug that only happened for some users.
What they are checking: Debugging across browsers, devices, locales and network conditions, and how you reproduced something you could not see on your own machine.
How do you test frontend code?
What they are checking: A sensible mix: unit tests for logic, component tests that act like a user, a few end-to-end tests for critical journeys, and visual or accessibility checks where they pay off.
How to structure a strong answer
For conceptual questions, give the one-line answer first, then the mechanism, then a practical consequence from your own work. For project questions, tie every technical choice to a user outcome: faster load, fewer errors, a form people can actually complete.
- Start with the short answer, in plain words.
- Explain the mechanism underneath, briefly.
- Give an example from something you built or fixed.
- End with the trade-off or what you would watch for next time.
Example answer
A page feels slow. How would you find out why?
I would start by measuring rather than guessing. On a dashboard I worked on, users said the page felt sluggish after it loaded, so the load time was not the problem. I recorded a session in the browser's performance panel and saw long tasks every time a filter changed: the whole table was re-rendering, including hundreds of rows that had not changed.
I memoised the row component, moved the filtering into a selector so it only recalculated when its inputs changed, and virtualised the table so only visible rows rendered. Filter changes went from a noticeable pause to feeling instant. The lesson I took was to profile first: my first guess had been the API, and it was fine.
Mistakes to avoid
- Answering accessibility questions with "add ARIA labels" and nothing about keyboard use, focus or semantic HTML.
- Suggesting optimisations such as memoising everything before saying how you would measure the problem.
- Talking only about your framework and being unable to explain the plain JavaScript or browser behaviour underneath.
- Describing the design team as an obstacle instead of a partner.
- Walking through a take-home without being able to say what you would change with more time.
Frequently asked questions
What questions are asked in a frontend developer interview?
Expect JavaScript fundamentals such as closures, the event loop and promises, questions on your framework, CSS layout, web performance, accessibility, testing, and a walkthrough of a project or take-home you built.
How much accessibility do I need to know for a frontend interview?
Enough to build common components that work with a keyboard and a screen reader: semantic HTML, visible focus, focus management in modals, labels on form fields, and when ARIA is and is not needed. Being able to describe how you test it is a strong signal.
Should I learn plain JavaScript or focus on React for interviews?
Both. Framework questions are common, but interviewers often probe the JavaScript and browser behaviour underneath, and candidates who only know framework patterns struggle when asked why something works.
How do I talk about a take-home project in the follow-up interview?
Open with the decisions you made and why, name the shortcuts you took because of time, and say what you would improve. Interviewers are checking that you understand your own code and can take feedback on it.