Effective Code Reviews: What Senior Engineers Look For

Code review is the highest-leverage engineering practice. It catches bugs before they reach production, spreads knowledge across the team, maintains code quality standards, and mentors junior engineers. But bad code reviews — nitpicking style, bikeshedding naming, or rubber-stamping complex changes — waste time and create friction. Here's what experienced engineers actually focus on during review.

The Review Hierarchy

1. Correctness: Does the code do what it's supposed to? Are edge cases handled? Do error paths work correctly?
2. Security: Are there injection vulnerabilities, auth bypasses, or sensitive data exposures? Does it follow the principle of least privilege?
3. Architecture: Does this change fit the existing codebase patterns? Will it be maintainable? Are the abstractions at the right level?
4. Performance: Are there obvious inefficiencies (N+1 queries, unbounded loops, missing indexes)? Are expensive operations appropriate for the context?
5. Readability: Can another engineer understand this code in 6 months? Are names clear? Is the logic straightforward?
6. Style: Formatting, naming conventions, and consistency. These should be automated (Prettier, ESLint) — not manual review items.

How to Give Good Feedback

• Ask questions instead of making commands: 'What happens if this API call fails?' is better than 'Add error handling here.'
• Explain the why: 'This could cause a memory leak because...' teaches more than 'Fix the memory leak.'
• Distinguish between blocking and non-blocking: Prefix non-blocking comments with 'Nit:' or 'Optional:' so the author knows what must be addressed.
• Praise good work: When you see an elegant solution, clean refactoring, or thorough testing, say so. Positive feedback reinforces good practices.
• Be timely: Review within 24 hours. Code review delays compound into blocked developers, context-switching costs, and merge conflicts.

What to Automate

Everything that can be automated should be. Formatting (Prettier), linting (ESLint), type checking (TypeScript), security scanning (CodeQL, Snyk), test coverage, and build verification should run in CI before a human ever looks at the code. This frees reviewers to focus on the things that require human judgment: design decisions, business logic correctness, and code clarity.

“Code review is not a gate — it's a conversation. The goal isn't to prove you're smarter than the author. It's to make the code better, share knowledge, and build a codebase that the whole team can maintain confidently.”

— Thomas Weber, Vaarak Architecture