Code Review and Engineering Standards
Code review is where quality, knowledge sharing and team culture meet. Learn what to look for in priority order, how to write comments that are specific and kind, the practices that keep reviews fast and useful, and how to set standards a team will follow.
🎯 What you'll learn
- Review priorities from correctness to style
- Writing specific, kind, labelled comments
- Practices for fast, useful reviews
- Setting and measuring team standards
📚 Before you start
Code review is where quality, knowledge sharing and team culture meet. Senior engineers are expected to give reviews that catch real problems and teach, keep review times short, and shape standards. Interviewers ask "How do you approach code reviews?" and sometimes give you a PR to review live.
1What to Look For (in Priority Order)
- Correctness: does it do what it claims? Edge cases, error handling, concurrency, off-by-one errors.
- Design: is it in the right place? Does it fit the architecture? Will it be easy to change?
- Security and data: input validation, authorization checks, secrets, PII in logs, SQL injection.
- Tests: do they cover the behaviour and edge cases? Would they catch a regression?
- Operability: logging, metrics, failure modes, migrations and rollback.
- Readability: naming, structure, comments that explain why.
- Style: should be automated (formatters, linters), not argued about in review.
2How to Comment
| Instead of | Write |
|---|---|
| "This is wrong." | "This throws if items is empty (line 42). Should we return early?" |
| "Why did you do it this way?" | "I'd have expected X here because Y. Was there a reason for Z?" |
| "Use a map." | "nit (non-blocking): a Map would make lookups O(1) here." |
| A wall of 40 comments | The 3 important comments, plus "a few nits, take or leave". |
Label comments: blocking, suggestion, nit, question, praise. Praise good work specifically; it reinforces standards too.
3Healthy Review Practices
- Small PRs (ideally under ~400 changed lines): review quality drops sharply on large diffs.
- Fast turnaround: first response within a few working hours; review time is a top driver of lead time.
- Author context: a description with the why, screenshots, test notes, and what to focus on.
- Automate the boring parts: formatting, linting, type checks, test coverage in CI.
- Two-way learning: juniors reviewing seniors' code is valuable too.
- Talk when it's stuck: after two rounds of back-and-forth, a 10-minute call beats ten comments.
4Setting Standards
Write team conventions down (a short review guide, PR template, definition of done) and enforce what you can with tooling. Revisit them in retrospectives. Measure time to first review, PR size and review rounds to see whether the process is healthy.
⚠️ Common Pitfalls
- Rubber-stamping ("LGTM" on a 2,000-line PR).
- Gatekeeping on personal preferences.
- Style debates that a formatter should settle.
- Slow reviews that block teammates for days.
- Rewriting the PR in comments instead of discussing the approach early.
📋 Quick Reference
Priority: correctness > design > security > tests > operability > readability > style (automate style)
Comment: specific, kind, labelled (blocking / suggestion / nit / question / praise)
Practices: small PRs, first response within hours, good descriptions, call when stuck
Measure: time to first review, PR size, review rounds🧠 Key takeaways
- Review in priority order: correctness, design, security, tests, then readability; automate style.
- Comments should be specific, kind and labelled (blocking, nit, question, praise).
- Keep PRs small and reviews fast; switch to a call when a thread stalls.
- Write standards down, enforce them with tooling, and measure review health.
🛠️ Practice exercises
Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.
✅ Check yourself
Answer the questions — feedback is instant.