Code reviews are a social and psychological craft disguised as a technical exercise. Mastering empathy, clarity, and conventional comment tagging makes PR merges 3x faster.
In high-velocity engineering teams at companies like Flipkart, Atlassian, Razorpay, and Microsoft, code reviews are the primary mechanism for maintaining code quality, enforcing architectural patterns, and sharing domain knowledge.
However, poorly worded review comments ("Why did you write this trash code?") trigger defensiveness, delay deployments, and damage team psychological safety. Communicating effectively in PRs means giving empathetic, objective critique, writing descriptive PR headers, and receiving feedback without personal ego.
Apply the Conventional Comments framework (`nit:`, `suggestion:`, `blocking:`, `praise:`) in PR code reviews.
Depersonalize code critiques by focusing on system behavior rather than personal programmer ability.
Write high-clarity PR descriptions with background context, test plans, and UI recordings.
Execute self-review audits before assigning PR reviewers to catch low-hanging issues.
Handle critical or contradictory review feedback constructively during software engineering internships and full-time roles.
Ensures group project repositories don't break main branch builds right before assignment submission deadlines.
Writing clean PR descriptions and thoughtfully reviewing peer code is the #1 signal managers evaluate for PPO (Pre-Placement Offer) conversions.
Accelerates sprint velocity, eliminates deployment blockers, and keeps microservices compliant with security standards.
Provides transparent client updates via GitHub/GitLab PR logs so non-technical clients see tangible project progress.
Helps maintainers review your PRs faster and prevents your pull request from sitting unmerged for months.
In Machine Coding and System Design rounds, walking interviewers through code cleanliness demonstrates senior engineering instincts.
Enables Tech Leads and Staff Engineers to mentor junior developers asynchronously without micromanagement.
Maintains healthy team psychological safety across remote engineering organizations.
Prefix every review comment with clear intent tags: `nit:`, `suggestion:`, `question:`, `blocking:`, `security:`, or `praise:`.
Pro Tip: Example: `nit: rename usr to user for naming consistency.` or `blocking: this query causes an N+1 database call inside the loop.`
Frame critiques around system behavior using "we" or passive voice instead of personal attacks using "you".
Pro Tip: Instead of "You forgot to handle null checks here," write: "We should add a null check here so the API does not throw 500 when `user.address` is undefined."
Always review your own diff on GitHub/GitLab before assigning reviewers.
Pro Tip: Check for left-over `console.log` statements, commented code, or missing test cases yourself first.
Keep pull requests focused on a single logical change. Mega-PRs (>1,000 lines) sit unreviewed for days and receive superficial reviews.
Pro Tip: If a feature is large, split it into 3 stacked PRs: 1) DB Migration, 2) Service Logic, 3) API Route / UI.
Developer loaded 5,000 orders in a loop to fetch user profile details. Reviewer commented: `blocking: This creates 5,000 DB round-trips. Use `JOIN` or batch `WHERE IN` query.`
Intern added unit tests, step-by-step Loom video recordings, and benchmark numbers to every PR description.
Contributor submitted a PR fixing a memory leak in a custom hook. Reviewer praised clean hook implementation with `praise: Excellent unit test coverage for edge cases!`
✕ Bad Approach
Reviewer: "This loop is O(N^2) and super inefficient. Rewrite this completely."
Why it failed: Aggressive, vague tone that offers no constructive alternative or severity context.
✓ Better Approach
Reviewer: "`blocking:` Since `userList` can contain over 50,000 items in production, performing `.find()` inside this map loop creates an O(N^2) bottleneck. We can convert `userList` to a Map key-value lookup before the loop to achieve O(N) linear time. What do you think?"
Why it works: Provides explicit tag (`blocking:`), production scale context, performance math, and actionable fix.
✕ Bad Approach
Developer: "This pattern works fine in local dev, why are you making me change it? You always find problems in my code."
Why it failed: Defensive, personalizes critique, and ignores production reliability.
✓ Better Approach
Developer: "Thanks for highlighting the race condition under concurrent requests! I see why `setTimeout` isn't reliable here. I have replaced it with a Redis atomic lock in commit `a8f912c`. Could you take another look?"
Why it works: Welcomes feedback, validates engineering concern, updates code, and links commit reference.
✕ Bad Approach
Reviewer: "Fix indentation here and add semi-colon on line 12, 15, 18, 22, 34..."
Why it failed: Wastes manual human review time on trivial formatting that automated linters should handle.
✓ Better Approach
Reviewer: "`nit:` Looks like Prettier didn't run on save for this file. You can run `npm run format` to auto-fix styling."
Why it works: Uses `nit:` tag and points to automated script.
`blocking:` On line 84, we are committing JWT secret keys directly in the `.env.staging` tracking file. We should use AWS Secrets Manager or environment variable injection instead.
Great catch! I accidentally committed that while testing local Docker build. I have revoked the staging secret, removed the hardcoded key from git history using `git filter-repo`, and injected it via environment variables in commit `c4d92a1`.
`praise:` Excellent response and security cleanup! Verified commit `c4d92a1`. Approving and merging now.
Fix: Stop wasting human review time on indentation or quotes. Enforce code formatting automatically via Prettier / ESLint pre-commit hooks.
Why it happens: Frustrates developers and distracts from core architectural logic bugs.
Fix: Break massive features into atomic pull requests (<300 lines) with feature flags.
Why it happens: Large PRs take days to review, increase merge conflict risk, and receive superficial approvals.
Fix: Never click "Resolve conversation" without leaving a comment explaining how or why it was addressed.
Why it happens: Creates confusion and destroys reviewer trust.
Fix: Aim to review assigned peer PRs within 24 hours to keep team deployment pipelines flowing.
Why it happens: Unreviewed PRs cause team sprint bottlenecks.
Use `praise:`, `nit:`, `suggestion:`, `question:`, `blocking:`, `security:` consistently.
Tip: Eliminates ambiguity about whether a change is required before merging.
Include UI screenshots, Loom video recordings, or benchmark outputs in every PR description.
Tip: Visual proof gives reviewers instant confidence that UI/logic works as expected.
Find at least one well-written function, clean test case, or elegant refactor to praise in every code review.
Tip: Builds positive team culture and reinforces good engineering habits.
## 📌 Title: [FEAT/FIX/REFACTOR]: Brief 1-line description ### 📝 What changes does this PR introduce? - Added OAuth2 authentication middleware for Google/GitHub logins - Refactored session verification logic to use Redis cache ### 🔗 Related Ticket / Issue Fixes #[Issue Number] / Jira: [PROJ-123] ### 🧪 How was this tested? - [x] Unit tests written and passing (`npm run test`) - [x] Tested locally on Chrome & Firefox - [x] Verified rate limits under load via Postman collection ### 📸 Screenshots / Video Recordings | Before | After | | ------ | ----- | | [Image/GIF] | [Image/GIF] | ### ⚠️ Special Deployment Notes Requires setting `OAUTH_CLIENT_SECRET` in staging environment variables.
💡 Usage Guidance: Use this template as your standard `.github/PULL_REQUEST_TEMPLATE.md` file in engineering repositories.
Conventional Comment Conversion: Take 3 past PR comments from your project repository and rewrite them using Conventional Comments tags (`nit:`, `suggestion:`, `blocking:`).
PR Description Template Setup: Create a standard `.github/PULL_REQUEST_TEMPLATE.md` in your personal repo containing: Summary, Motivation, Screenshots, Test Plan.
The "Praise First" Challenge: Leave at least one genuine `praise:` comment on the next 3 peer PRs you review.
PR Self-Review Exercise: Open a draft PR for your latest project and leave 3 self-comments explaining complex design choices before asking peers to review.
Common behavioural and technical interview questions testing this competency across experience levels.
💡 Model Answer Framework:
I perform a self-review first: checking for left-over logs, unused variables, and formatting. I ensure all unit tests pass. Then I write a structured PR description using our template, outlining motivation, architectural changes, screenshots/GIFs for UI, and special deployment notes. Finally, I tag code owners and add appropriate scope tags.
Code review excellence combines technical rigor with emotional intelligence.
Clear PR descriptions and empathetic review comments build strong team culture.
Automating style checks frees developers to focus on architectural reliability during reviews.