Platforms
Repository-based vs whiteboard interviews
Short answer
Practise repository navigation, tests, and incremental changes for a repository-based interview; practise requirements, diagrams, and verbal trade-offs for a whiteboard interview. If the company gives you code, reading and verifying it matter more than presenting a perfect architecture from memory.
Written and reviewed by Sahil Srivastav
What each one actually is
A repository-based interview gives you an existing codebase and asks for a fix or feature. The evidence is executable: can you find the relevant path, preserve contracts, and verify the change?
A whiteboard interview gives you a problem and evaluates how you clarify requirements, decompose a system, and reason about trade-offs without relying on a full development environment.
The formats can discuss similar domains but expose different behaviour. A repository constrains you with existing decisions; a whiteboard gives you freedom but demands explicit assumptions.
Side by side
| Repository-based interviews | Whiteboard interviews | |
|---|---|---|
| Starting material | Existing code, tests, and configuration | Prompt, whiteboard, and conversation |
| Core evidence | Working change and diagnostic path | Reasoning, structure, and trade-offs |
| Constraints | Existing contracts and dependencies | Requirements and stated assumptions |
| Feedback | Runtime and test results | Interviewer questions |
| Typical failure | Changing the wrong boundary | Ignoring scale or unstated requirements |
| Time use | Inspect, implement, run checks | Clarify, estimate, draw, defend |
| Best preparation | Timed debugging sessions | Design prompts and capacity drills |
| Communication | Explain while investigating | Make the model legible verbally and visually |
Choose Repository-based interviews when
- The interview includes starter code or a Git repository
- The role values practical backend implementation
- You need evidence that your fix works across integrations
- Your main gap is reading unfamiliar code under time pressure
Choose Whiteboard interviews when
- The interview is explicitly architecture or system design
- There is no runnable environment
- You need to practise requirements and capacity estimation
- The assessment focuses on verbal reasoning and trade-offs
The trade-off in detail
A repository gives stronger feedback about implementation but less freedom to redesign. A whiteboard gives freedom but makes it easy to skip the hard details. In both, state the invariant before choosing the design.
Repository preparation should include a first-pass workflow: run the smallest test, trace the request, locate the boundary, and change one thing. Whiteboard preparation should include a first-pass requirements and scale workflow.
A polished diagram cannot compensate for an unverified repository fix, and a passing test cannot answer a fleet-capacity question. Match evidence to the question.
Things that are commonly said and are wrong
- “Whiteboard interviews are less practical.” They test a different layer of judgement and can reveal assumptions before implementation.
- “Repository interviews are only syntax tests.” Good ones test diagnosis, ownership, compatibility, and verification.
- “The same answer works in both formats.” The format changes what must be made explicit and what can be demonstrated.
FAQ
How do I prepare for a repository interview?
Practise small changes in unfamiliar projects, read tests first, use focused diagnostics, and explain the contract you are preserving. Do not begin with a broad refactor.
How do I prepare for a whiteboard interview?
Practise clarifying requirements, estimating traffic and storage, drawing request and failure flows, and defending one recommendation with explicit trade-offs.
Which format is better?
Neither universally. Choose preparation based on the company’s actual format; a repository is more predictive for a practical coding round and a whiteboard for architecture discussion.