What makes a good pull request?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Small focused scope, clear title/description explaining what and why, self-review before requesting reviewers, passing CI, linked issue, screenshots for UI changes — and prompt responses to feedback. Reviewers' time is the scarcest resource.
Detailed explanation
PR quality determines review speed. Scope: under ~400 changed lines review meaningfully; large features ship as stacked PRs or feature-flagged increments. Description answers three questions — what changed, why (link the ticket), how to verify (steps, test evidence) — with before/after screenshots for visual work. Self-review catches debug leftovers, stray formatting, and forces you to reread your own diff; it's also where you add comments guiding reviewers through tricky sections. Hygiene: branch rebased/current with main, CI green, no unrelated commits mixed in (that's what cherry-pick/rebase are for). During review, respond to every comment (even just 'done'), push follow-up commits rather than force-pushing mid-review so incremental diffs stay readable, then squash-merge per team convention. As reviewer: small PRs get thorough reviews within hours; giant ones get rubber-stamped within days — size is kindness.
Example
## What
Adds pagination to /api/orders (cursor-based).
## Why
Closes #482 — endpoint times out beyond ~5k orders.
## How tested
- Unit tests for cursor encoding
- Verified against 50k-row staging DB (screenshots)
- p95 latency: 1.2s → 140ms
## Note for reviewers
Cursor logic in `src/pagination.ts:40` is the subtle part.Interview tip
Frame everything around reviewer efficiency, volunteer a concrete number (~400 lines), and show a mini description template — practical experience speaks loudest here.
Common mistakes
- Giant mixed-concern PRs nobody reviews properly.
- 'Fixed' replies without pushed commits addressing feedback.