How the interviewer opens it
“Design a platform that maintains the desired application state across a cluster of machines. Support container placement, failure recovery, and rolling deployments.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Applications
- Scale
- Read and write traffic
- Placement rules
- API latency
- Failure recovery
- Consistency, availability, and durability
- Deployment behavior
- Capacity and startup
- Existing systems and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Accept an application image, replica count, and resource requests.
- Place containers on machines with enough resources.
- Restore the desired replica count after container or machine failures.
- Deploy new versions within application availability limits.
Usually out of scope
- Stateful applications and persistent volumes
- Container runtime implementation
- Custom network design
- Image builds and registry implementation
- Automatic changes to the machine count
- Isolation for untrusted customers
What interviewers ask about
- Placement decisions
- Free cluster capacity does not guarantee a valid placement. Concurrent decisions can claim the same resources before containers start.
- Machine failures and return
- A missing heartbeat does not prove that containers stopped. Replacements can restore service while isolated machines retain obsolete containers.
- Deployment progress
- A container can run without serving traffic. Deployment decisions must respect readiness, spare capacity, small replica counts, and containers that have not stopped.
- Desired-state durability and authority
- Accepted application changes must survive failures. Old controllers must not override newer decisions when a partition separates control-plane members.
Common mistakes
- The design places containers once but does not restore the requested application state.
- The scheduler checks current utilization but ignores resource reservations.
- The controller treats a missing heartbeat as proof that a container stopped.
- Returning agents never compare their containers with current assignments.
- The deployment controller states limits but ignores pending instances, terminating instances, or readiness when it applies them.
- The API acknowledges desired-state changes before durable storage confirms them.
The bar by level
- Senior (L5/E5)
- Enforces resource reservations and deployment budgets through retries and controller restarts. Handles unreachable machines and obsolete assignments. Preserves healthy containers during control-plane outages.
- Staff (L6+/E6+)
- Defines authority across partitions and explains the limits of session epochs. Quantifies recovery after 500 machine failures. Distinguishes authorized counts from physical duplicates. Plans control-plane growth and future stateful safety without unnecessary scheduler shards.