Software Engineer interview question
What do you look for in code review?
Review correctness and missing cases first, then security, data consistency, failure handling, concurrency, performance, tests, clarity, and compatibility. Explain impact and propose a concrete change instead of debating personal style.
Direct answer
What a strong answer covers
How it works
A review starts by understanding what the change is supposed to do, then checks whether it does that in every case, including the empty, concurrent, and failing ones. Next come the things tests rarely catch: authorisation gaps, data that can end up inconsistent, resources that leak, backward compatibility of APIs and schemas, and performance on realistic data sizes. Only then readability and naming. Comments state the impact and suggest a concrete alternative; style debates go to a linter. The reviewer’s job is to catch what will hurt in production, not to rewrite the change in their own taste.
Example
A pull request adding an export endpoint looked correct until the review asked what happens for a user with 500,000 rows; the loop loaded everything into memory. The comment proposed streaming with a cursor and a hard row limit with a link to the pagination helper, and the author shipped that instead of a reformatted version of the original.
Common mistakes
- Approving because the tests pass without reading what the tests actually assert.
- Leaving twenty style nits and missing the missing authorisation check.
- Blocking a change over personal preference with no impact on behaviour.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.