Also known as: startup, scale-up, seed, series A, early stage
Startups and scale-ups Interview Guide
Small product teams hiring for end-to-end ownership, where the loop is short, idiosyncratic, and usually anchored on a take-home or a paired session in the actual codebase. Use this guide to map the interview rounds, scoring signals, common traps, and high-yield questions for startup, scale-up, seed roles.
How the loop is evaluated & calibrated
There is no calibration to hide behind, so the loop is whatever the founder or lead believes predicts performance - most often a practical build, then a conversation about the trade-offs you chose. Breadth is the bar: the same person is expected to ship the feature, its migration, its metrics, and its on-call. Behavioural rounds are less about principles than about tolerance for ambiguity and whether you make decisions when nobody hands you the requirement.
Scored on top of a correct answer
•What you deliberately left out, and whether you can defend cutting scope to ship
•Operational instinct: how the thing you built is monitored, rolled back, and paid for
•Whether you decide without a spec instead of waiting to be told
Where candidates lose points
•Over-engineering the take-home, which reads as someone who cannot judge stage-appropriate scope
•Deferring every product question to a product manager who does not exist yet
•Depth in one layer with no idea how the thing runs in production
A single threshold on a single window cannot separate a real outage from a brief spike, so it either pages on noise or misses slow burns. Replace it with multi-window multi-burn-rate alerting: a fast rule that pages and a slow rule that files a ticket, each gated by a short window so a spike that already stopped does not keep paging.
CPU is compressible, so the kubelet throttles it rather than evicting for it. Eviction comes from memory, ephemeral storage or inodes - and which pods die is decided by QoS class, not by who caused the pressure. Check node conditions and eviction thresholds first, then fix the requests and limits so critical workloads are Guaranteed rather than BestEffort.
Name the clock and what it was costing, say which facts you had and which you chose not to wait for, classify the call as reversible or not, act at the level you were authorised to and say so, and record the reasoning at the time so it can be judged on what you knew.
Stabilise first and diagnose second, which usually means reverting the change before you understand it. Take one artefact of evidence on the way out, time-box the decision aloud, communicate impact on a fixed cadence, and treat the incident as open until the damage the deploy caused is repaired.
During the event your only levers are the ones already built: fail over, serve degraded from cache, or shed the dependent feature. Beforehand the work is finding your transitive dependencies on foundational services, making the running system statically stable, and choosing which features are allowed to fail alone.
Recovery time is set by how much state diverged, not by how long the fault lasted, so seconds of dual writes can take a day to reconcile. The prevention is a single writer enforced by quorum and fencing; the mitigation is designing the write path so repair is mechanical rather than forensic.
Kubernetes CrashLoopBackOff debugging starts with the previous container logs, exit code and pod events. Then separate application crashes from liveness probe kills, bad configuration, missing dependencies and OOMKilled restarts.
Removing a pod from its EndpointSlice and sending it SIGTERM happen concurrently, and the data-plane update takes time to propagate, so requests keep arriving at a pod that has already begun shutting down. The fix is a preStop delay plus an application that finishes in-flight work before exiting.