Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
What they are really testing: Whether you design for the organisation, not just the technology. The hard parts are consistency without central bottlenecks, and what happens when service A must deploy before service B.
A real interview question
Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
What most people say
drag me
“Set up Jenkins with a job per service and a shared library.”
It names a tool and a folder structure but answers none of the design questions: how services stay independently deployable, how a security fix reaches 15 pipelines, or what happens when two services must ship together.
The follow-ups they ask next
Two services genuinely must deploy together. How do you handle it?
First try to remove the coupling with backward-compatible changes and feature flags, which is nearly always possible. If it is truly atomic, they may belong in one deployable unit, since the boundary is wrong.
How do you roll out a breaking change to the shared template?
Version the template, let teams pin, announce with a deadline, migrate the easy ones yourself, and only then remove the old version. Forcing an immediate break makes teams fork the template and you lose central control entirely.
What the interviewer is listening for
- Asks about coupling before designing
- Templates centrally without blocking teams
- Raises contract testing for independent deploys
What sinks the answer
- Names tools instead of design
- Central team becomes an approval bottleneck
- No answer for cross-service compatibility
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.
“First I ask [whether any services are coupled]. Then [a shared pipeline template owned centrally so security changes land once], [build once and promote the artifact with GitOps per environment], [contract tests so services stay independently deployable], and [automated policy as guardrails rather than manual approval gates].”
Keep going with system design
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.
Senior
Design a system giving every pull request its own preview environment, for a team of 30.
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