Code Review — Engineering Quality Gate

Code review is the practice of having one or more engineers examine proposed code changes before they are merged into the main codebase. It catches bugs, enforces coding standards, spreads knowledge across the team, and improves code design. Modern teams use pull request (PR) workflows on GitHub, GitLab, or Bitbucket to manage code reviews.

Why companies use it

·Code review catches 60–90% of defects before they reach QA or production, at a fraction of the cost
·Spreads knowledge of the codebase across the team — prevents "bus factor" where only one person understands a module
·Enforces coding standards and architecture patterns consistently across a team
·In regulated software (DO-178C, IEC 62304), code review is a required design control activity with documented evidence

What hiring managers look for

·Engineers who give clear, constructive, and specific code review feedback make the whole team better
·The ability to receive code review feedback graciously and make changes efficiently is a professional skill
·Understanding what to look for in a code review (correctness, security, readability, performance, test coverage) shows engineering maturity
·Experience as both reviewer and reviewee in a structured PR process is expected in any modern software engineering role

Typical interview questions

What do you look for when reviewing a pull request?

How do you give constructive code review feedback to a junior engineer who made a fundamental design mistake?

What should you NOT enforce through code review?

How do you handle a situation where you disagree with the reviewer's feedback on your PR?

What is the difference between a code review comment that is a "must fix" and one that is a "suggestion"?

Common mistakes

·Reviewing only for bugs while ignoring design, readability, and test coverage — all four dimensions matter
·Writing vague, negative review comments like "this is bad" — comments should explain why and suggest an alternative
·Nitpicking style issues in code review when a linter or formatter could enforce them automatically
·Reviewing PRs that are too large — PRs with >400 changed lines have substantially lower defect detection rates
·Not reviewing the tests — if the tests are not reviewed, the correctness of the test suite is not guaranteed

Real engineering example

A firmware team discovered through a post-mortem that a field bug causing intermittent motor stops had passed code review undetected. The bug was in a 600-line PR where a race condition in the interrupt handler was buried in one function 450 lines in. After the incident, the team introduced a maximum PR size of 200 lines and required PR authors to write a summary of the expected behaviour change. The next 6 months saw zero field escapes from merged PRs.

Topics covered

code reviewpull requestPRqualityGitHubcollaborationsoftware engineering

Related interview guides

Software Engineer →Embedded Software Engineer →Firmware Engineer →

More in Software Engineering

Git — Version Control for Engineers4 min CI/CD — Continuous Integration and Delivery5 min TDD — Test-Driven Development4 min Software Architecture — Design for Scale6 min DevOps — Development and Operations Integration5 min

Preparing for an interview?

Browse our role-specific interview guides written by engineers who know what hiring managers at ASML, NXP, and Philips look for.

Browse Interview Guides →