So you got head-hunted. A recruiter from a large company wanted to talk to you about a React front-end position.
You are excited, but at the same time nervous about the one-hour code review exercise. You got seven days. What would you do?
This is exactly the situation I've found myself in!
Past Experiences
From my previous experiences, it was rarely a lack of technical knowledge that caused me difficulty. The bigger problems were uncertainty, unfamiliarity with the interview format, and the pressure of having to think clearly while someone watched me.
So I asked myself:
If I were the interviewer, what would I use to evaluate a senior React developer?
The exercise couldn’t be impossibly difficult because that would filter out almost everyone. It would probably focus on realistic problems that appear in production React code:
- Incorrect useEffect dependencies
- Stale closures
- Race conditions
- Unstable keys
- Incorrect state updates
- Misused hooks
- Unnecessary or unexpected re-renders
These are not obscure pieces of syntax. They reveal whether someone understands React’s underlying mental models.
Building Muscle Memory
Understanding these ideas wasn’t enough. I also needed to recognise them while nervous, tired, or unsure of myself. After all, there could be many unexpected issues on the day of the interview.
My solution was repetition.
I practised the same interview format several times, using small but realistic React applications containing 5- 6 intentional problems. I reviewed the code, identified each issue, and explained my reasoning aloud.
The goal was to develop a kind of muscle memory.
The Actual Interview
I received three or four screens of production-looking React and TypeScript code. I was asked to identify its bugs and design problems.
It was approximately three times more complicated than my mock exercises — but the format was almost exactly what I had practised.
More importantly, many of the problems came from the same React mental models I had been studying.
I was able to find the main issues and explain why they mattered. There were also moments when I became quiet or uncertain, which showed me that thinking aloud is another skill I need to practise.
What I Learned
The preparation did not make the interview easy. It made the situation familiar.
What worked:
- Repeating realistic code review exercises
- Studying React’s central mental models
- Practising clear explanations
- Learning to recognise common problems quickly
What I still need to improve:
- Thinking aloud when I’m uncertain
- Reading larger, more complicated React files
- Practising with production-style code rather than only small demos
Over the next few articles, I’ll share some of the mock code review exercises I wish I had before this interview—along with the problems hidden inside them.
Question
How do you prepare for interviews? Have you tried repetitions and rehearsals? Please comment and share!:)
Top comments (0)