Design a system giving every pull request its own preview environment, for a team of 30.
What they are really testing: Cost and lifecycle thinking. The naive design works and then quietly costs a fortune, and the data layer is where most candidates stop thinking.
A real interview question
Design a system giving every pull request its own preview environment, for a team of 30.
What most people say
drag me
“Spin up a full copy of production infrastructure for each pull request and tear it down when it merges.”
A full production copy per PR for 30 engineers is both slow to create and extremely expensive, and it ignores the hardest question entirely: what data lives in it and how it arrives quickly enough to be useful.
The follow-ups they ask next
A PR needs to test a database migration. How does that work?
That is a strong argument for a per-PR database: the environment runs the migration against its own seeded copy, which tests the migration itself, and the cheap clone makes it affordable.
How do you stop preview environments becoming a cost problem?
TTL by default, scale to zero on idle, cost attribution per PR so it is visible, and a dashboard of running environments with age. Anything without an open PR should be automatically destroyed.
What the interviewer is listening for
- Names shared versus duplicated as the key lever
- Solves data seeding with fast clones
- Designs TTL and scale-to-zero for cost
What sinks the answer
- Full production copy per PR
- No data story
- No TTL for abandoned branches
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“The lever is [what is duplicated versus shared]. Per-PR [namespace with app services], and the deciding question is [data: a fast seeded clone, not a production-sized copy]. Lifecycle is [created on open, updated on push, destroyed on merge, hard TTL for abandoned branches]. Cost control is [scale to zero on idle and cost attribution], and it must be [genuinely useful: URL on the PR, realistic data].”
Keep going with system design
Senior
Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
Senior
Design an observability stack for a system where nobody can currently answer why a request was slow.
Senior
Design secret management for 40 services across 3 environments, with an audit requirement.
Principal
Design multi-region failover for a system that currently runs in one region, targeting 15 minutes recovery.
Senior
Leadership asks you to prove the platform investment is working. What do you measure?
Senior
You inherit 200 Jenkins jobs with no documentation and are asked to migrate to a modern CI system. How do you approach it?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free