Interview guide
A seven-day React interview study plan
This plan is for engineers who already ship React UI and now need to explain it under interview pressure. Each day has a short reading target, one coding drill, and a spoken explanation you should be able to give without opening the docs.
How to use the week
Block 60–90 minutes a day. Write code first, then explain the result out loud as if a reviewer is on the call. If you skip the spoken pass, you are practicing editing, not interviewing.
Keep a single notes file. Capture one sentence per topic: the rule, a counter-example, and the trade-off you would mention if the interviewer pushes.
Day 1 — components, props, and state
Redraw one production screen as a tree of components. Mark which data is owned, which is passed down, and which is derived. Interviews go wrong when candidates store derived values in state and cannot explain why a render looped.
- Lift state only when two siblings must share it. Otherwise keep it local.
- Prefer a key that is stable and unique for lists. Index keys hide insert/delete bugs.
- Explain controlled versus uncontrolled inputs with one form you actually built.
Day 2 — Rules of Hooks
Hooks must run in the same order every render. Conditional hooks, hooks in loops, and hooks after an early return are the usual interview traps. Be ready to walk through why React associates hook state with call order, not with function names.
Practice on Interview Horizon’s Rules of Hooks question after you can recite the rule and a failing snippet from memory.
Day 3 — effects and cleanup
Write a tiny subscriber: fetch on mount, abort on unmount, and resubscribe when an id changes. Then break it on purpose by omitting the cleanup and describe the bug you would see in Strict Mode.
Do not reach for an effect to transform data that can be computed during render. Interviewers use that distinction to separate API familiarity from actual UI modeling.
Day 4 — accessibility
Take one modal or dropdown you have shipped. Tab through it with the keyboard, check focus restore on close, and confirm the trigger has a name a screen reader can speak.
Be ready to talk about labels versus placeholders, button versus div, and why aria-label is a last resort when visible text already exists.
Day 5 — performance trade-offs
Measure before memoizing. memo, useMemo, and useCallback hide costs; they do not delete them. Pick one list that re-renders too often and decide whether the fix is a better key, a split component, or virtualization.
Have a one-minute story about a real slowdown: what you measured, what you changed, and what you refused to micro-optimize.
Day 6 — tests you can defend
Write one user-centric test: render, click, assert visible text. Skip implementation details such as internal class names. If you use React Testing Library, explain why querying by role is closer to how people use the page.
Day 7 — mock interview
Give yourself 45 minutes. Build a searchable list with loading, empty, and error states. Narrate as you go: data ownership, hook order, keyboard path, and what you would load later.
End with a self-assessment: which day still needs another pass, and which topic you can teach without notes.