Correctness of the data flow first: where state lives, whether effects are necessary and have honest dependencies, and whether keys are stable. Then the user facing edges, which are loading, empty and error states, plus keyboard and screen reader access. Then performance only where it is measurable. Style and naming are last, and anything a linter or formatter can decide should not be a review comment at all.
Why interviewers ask this
Review habits tell an interviewer how you will affect the rest of the team. They want to see priorities, since a reviewer who leads with naming nitpicks and misses a missing dependency array is a net negative. They are also listening for tone and pragmatism: asking questions rather than issuing orders, distinguishing blocking issues from suggestions, and knowing what to automate instead of policing by hand.
How to structure your answer
- Give your priority order, correctness before cosmetics.
- Name the specific React traps you check for.
- Cover the states and accessibility most pull requests forget.
- Say what you never comment on because tooling handles it.
Example answer
I read the description and the tests first, then the diff, because I want to know what the change is meant to do before I judge how it does it. My first pass is data flow. Where does this state live, could it live lower, is that effect actually needed or is it derived state, are the dependencies honest or has somebody quietly silenced the lint rule, and are the list keys stable. Second pass is the edges, which is where most bugs ship: what does this render while loading, when the list is empty, and when the request fails, and can I operate it with a keyboard. Third is performance, but only if I can point at a real cost, not a vibe. I try to mark comments as either blocking or just a thought, because unlabelled nitpicks stall pull requests for days. And I never comment on formatting or import order; if it matters, it belongs in the linter, not in my opinion.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you handle a disagreement with a senior engineer in review?
- What would make you request changes rather than leave a comment?
- How do you review a two thousand line pull request?
Related react developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions