Production engineering interview guide

Tests · Whether the candidate treats CI as a feedback system with a latency budget, or as a list of tasks that must all be run.

Tests · Whether the candidate reasons about blast radius and reversibility before reasoning about mechanism, and whether they can say what would make them stop.

Tests · Whether the candidate understands that during any rollout two versions of the code run against one database, and can sequence changes so both are always valid.

Tests · Whether orchestration is treated as a requirement to be established, or as the thing production is assumed to mean.

Tests · Whether the candidate reduces user impact before seeking understanding, and whether they can run the response as a coordinated activity rather than as a debugging session.

Tests · Whether the candidate can name the operational properties it buys, rather than describing it as the modern way to do things.

Tests · Whether the candidate separates the backup from the restore, and connects both to a recovery objective and an actual procedure.

Tests · Whether the candidate can identify what actually saturates first, and whether they treat autoscaling as a control loop with lag rather than as elasticity.

Tests · Whether the candidate reasons about the whole lifecycle — issuance, delivery, rotation, revocation, audit — rather than about where to hide a string.

Tests · Whether the candidate has a decision rule that survives time pressure, and whether they know what makes rollback unavailable.

Tests · Whether the candidate treats "nothing changed" as a claim to be tested, and whether they have an ordered search rather than a hunch.

Tests · Whether the candidate knows the limits of pre-production evidence and can say what only production can reveal.

Tests · Whether the candidate connects artifact identity to the ability to reason about what is running and what was tested.

Tests · Whether the candidate can enumerate the inputs a build depends on, including the ones that are invisible.

Tests · Whether the candidate understands the process and signal model inside a container and the timing relationship between routing and termination.

Tests · Whether the candidate designs alerts from user impact and required action, and treats noise as a reliability problem rather than an annoyance.

Tests · Whether the candidate can hold contributing factors rather than a single cause, and whether the outputs actually change the system.

Tests · Whether the candidate writes procedures for a tired stranger with partial information, and knows what a runbook must not contain.

Tests · Whether the candidate can reconcile least privilege with the reality that emergencies require access, without pretending either away.

Tests · Whether the candidate can separate moving code to production from exposing behaviour to users, and can use that separation deliberately.

Tests · Whether the candidate treats configuration as a deployable with its own blast radius, testing and rollback story.

Tests · Whether the candidate can derive headroom from failure requirements rather than picking a comfortable number.

Tests · Whether the candidate can reason about the path from dependency to running process as attack surface, and about what a scanner finding actually means.

Tests · Whether the candidate treats the platform as a product with users, and can distinguish a guardrail from a gate.

Tests · Whether the candidate can identify toil precisely and recognises that automating a misunderstood process scales the mistake.

Tests · Whether the candidate reasons about a shared, finite resource across the whole fleet rather than per instance.