What is asked in a frontend interview, how to answer about React, CSS, and performance, and how to rehearse the conversation with an AI trainer.
A frontend interview differs from other technical interviews: here they test not only API knowledge but also how you think about the user. The same component can be written in three ways — and the question “why exactly this way” weighs more than the implementation itself.
Usually there are four stages, and each requires its own preparation:
| Stage | What they assess | How to prepare |
|---|---|---|
| Recruiter screening | experience, motivation, salary expectations | three sentences about yourself + salary range |
| Technical interview | JavaScript, CSS, browser, framework | review of the questions below |
| Live coding | how you write code and reason | talk through your solution process out loud |
| System design / architecture | how you design the interface and state | structure your answer: context → options → choice |
This is where they check your role, not the scale. Bad: “we rewrote the frontend in React.” Good: “I was responsible for the transition to the new API — I had to maintain compatibility; here’s how I did it and what it delivered in metrics.”
Typical set: event loop, promises vs async/await, event bubbling, delegation, `this`, closures, differences between `var`/`let`/`const`, the difference between copying by reference and by value. They expect not definitions but an example of use.
Flexbox vs Grid, selector specificity, how `position: sticky` works, what margin collapse is, how responsive design is done without media queries. They test the ability to explain, not to remember syntax.
The difference between state and props, why keys are needed in lists, what a re-render is and how to avoid it, `useEffect` and its dependencies, memoization, context vs a state manager. They often ask to find a bug in a code snippet.
What Core Web Vitals are, how to measure LCP and CLS, what to do with extra JS in the bundle, why code splitting and lazy loading are needed, how caching works. Here it is important to name specific tools: Lighthouse, Performance API, Chrome DevTools.
Semantic tags, ARIA, focus and keyboard navigation, contrast. A screening question for many candidates.
They check whether you can see states (e.g., hover, disabled, no data), not just the ideal mockup.
The same structure works for technical questions as for behavioral ones: thesis → rationale → example → limitation. The last step is most often forgotten, yet it is precisely this that distinguishes a senior from a middle.
«For this case I would use list virtualization. The reason is that the DOM can't handle ten thousand nodes: scrolling starts to stutter. In a past project we cut time to interactive by about three times this way. Limitation: virtualization works poorly with variable row heights — then measurement is needed».
Note: there is a solution, a reason, a concrete result, and an honest boundary of applicability. Such an answer cannot be «memorized» — but it can be rehearsed.
| Day | What to do | Time |
|---|---|---|
| 1 | Write down your 5 projects: role, task, result in numbers | 40 min |
| 2 | Go through the 7 topics above and mark where the answer does not add up | 40 min |
| 3 | Answer 10 questions aloud, record yourself on a voice recorder | 30 min |
| 4 | Review the recording: where the pauses are, where structure is lost | 20 min |
| 5 | Run a full dialogue with the AI trainer for your vacancy | 30 min |
| 6–7 | Repeat problematic answers, repeat the run | 20 min |
What changes: the speed of assembling an answer, the ability to keep structure on an unexpected question, the skill of naming the limitation of your solution. This is noticed after just three or four runs.
What won't happen: preparation doesn't replace knowledge of the technology. If you don't understand the event loop, a beautiful answer structure won't help. First comes knowledge, then the skill of presenting it.
If your technical foundation is solid, a week of 30–40 minutes a day: structuring your answers, saying them out loud, and one full run-through of the dialogue. If your foundation is weak on a specific topic (for example, the event loop or the CSS cascade), close that gap first; otherwise, answer structure won't help.
It depends on the company: product teams more often give practical tasks (write a component, debug an issue), while large tech companies give classic algorithms. Ask the recruiter about the format in advance — it's a reasonable question.
Say so directly and show how you would find out: “I haven't worked with this directly, but the logic is similar to X — I would check the documentation and a prototype.” This is valued higher than a made-up answer: the interviewer can almost always tell when a candidate is floundering.
Yes, it is a separate skill. Practice saying your solution out loud, writing code in an editor without autocomplete, and starting with clarifying questions. Even a confident developer gets lost in the first session without this practice.
Give a range rather than a single number, and base it on the market. How to do this without awkwardness is covered in the article salary negotiations.
Describe the situation in one phrase — “interview for a frontend developer, React, three years of experience” — and go through the dialogue in the simulator. The coach will ask questions about your role and review your answers after the conversation.
Start with five projects: role, task, result in numbers. Then run the full dialogue — open HintMeTalk AI, “Coach” mode, describe the situation. After the review, it will be clear which answers fall short: usually it’s two or three out of ten, and those are the ones that decide the outcome.
General principles for preparing for any interview — in the article interview preparation. And if a conversation about money is coming up — salary negotiations.
Practise this skill in HintMeTalk AI
Open the app
HintMeTalk