A frontend interview can move from JavaScript closures to keyboard navigation to a product decision in roughly the time it takes a build to fail for an unrelated reason.
Prepare the fundamentals, but also prepare to explain how your choices affect users. A component is not good merely because it has an elegant prop name.
Six areas to prepare
- HTML and the browser: Semantic elements, forms, loading, rendering, events, and storage.
- CSS and layout: Responsive design, layout systems, cascade, specificity, and maintainable styling.
- JavaScript: Scope, asynchronous work, data handling, errors, and performance.
- Accessibility: Keyboard use, focus, labels, text alternatives, contrast, and testing with assistive tools.
- Components and state: Clear boundaries, data flow, reusable APIs, and avoiding state that has wandered into every corner.
- Testing and product work: Useful tests, trade-offs, measurement, and collaboration with design and backend teams.
Questions that reveal how you work
QUESTION 01
A page feels slow. What do you check first?
Why they ask: This tests whether you measure before changing code.
- Clarify which interaction feels slow
- Use browser tools and real metrics
- Separate network, rendering, and JavaScript costs
Likely follow-up: Which metric matters here? · How would you test a low-end phone?
QUESTION 02
How do you decide where state should live?
Why they ask: This tests component design and your ability to keep data flow understandable.
- Start with the smallest owner that needs it
- Explain who reads and changes the state
- Name the cost of moving it global
Likely follow-up: What would make you change the decision?
QUESTION 03
How would you make a custom menu accessible?
Why they ask: This checks whether accessibility is part of implementation rather than a final audit.
- Begin with a native element when possible
- Cover keyboard behaviour and focus
- Test names, states, contrast, and screen reader output
Likely follow-up: Why not add ARIA to a div?
Turn ‘improve performance’ into a real answer
| Weak move | Better move | Reason |
|---|---|---|
| Immediately add memoisation | Measure the slow interaction first | The bottleneck may be network, layout, or too much JavaScript |
| Quote one Lighthouse score | Use a metric that matches the user problem | A score is a clue, not the whole experience |
| Test on your laptop only | Include slower devices and connections | Users have the irritating habit of owning different hardware |
| Optimise everything | Fix the largest user-visible delay | Small code wins do not always create noticeable product wins |
Example: explain an accessibility improvement
Problem, change, and user effect
“Our custom checkout dialog trapped mouse users correctly but keyboard focus could move behind it. I replaced the hand-built focus logic with the native dialog element where supported, added a tested fallback, and checked the flow using only a keyboard and a screen reader. The change fixed the audit issue and let keyboard users complete checkout without losing their place.”
The answer explains the actual barrier, implementation choice, testing, and user result.
Prepare one frontend project as a story
- 1
Start with the user problem
Explain what was difficult for the user or business before discussing the component tree.
- 2
Name the constraint
Include time, browser support, design system rules, data limits, or team boundaries.
- 3
Explain your choice
Compare the options and say why your solution was appropriate then.
- 4
Show the result
Use a user, performance, accessibility, quality, or delivery measure.
Frontend interview checklist
- Browser and JavaScript basics are fresh
- You can explain one component trade-off
- Accessibility appears in a real project story
- Performance answers begin with measurement
- You can connect code choices to users
- Testing examples include what the test protects
Sources and further reading
These links support the advice above and give you somewhere useful to continue reading.
Frontend answers should work outside localhost
Practise connecting browser knowledge to real user problems
Try a frontend mock interview with technical questions, project follow-ups, and no tab containing the perfect answer.
Start a frontend interview