Site Reliability Engineer (SRE) interview questionsCoding Test round

Purpose

Tells a candidate who prepared for algorithm problems that the hour is about operational code, and that the script is real enough to have consequences.

Purpose

Makes running the code and searching explicitly allowed, so reading time is not mistaken for hesitation.

Purpose

Safe automation is read here. Separates a candidate who reads the script as an operation on a live fleet from one who reviews it as code. The first reads the batch order against the inventory and the health check against the README; the second finds the bare `except` and the unused flag and stops.

Signals to score

• Runs the script against the stub, or reads `list_instances()`, to learn what order the batches come out in rather than assuming it
• Connects the zone-sorted batches to the README's latency alerts, which fired one zone at a time, without being pointed at it
• Names the missing drain as requests failing on restarted instances, not as a style problem
• Notices that `/healthz` answers before the instance is ready, and that the script moves on to the next batch while the last one is still warming
• Notices that the `False` from `wait_healthy()` is thrown away
• Says that the swallowed exception and the final count together mean the script reports success whatever happened
• Finds that `--dry-run` is parsed and never read, and says why that is worse than having no flag
• Orders the findings by what a checkout customer feels first, and can say why that order
• Says the stale filter is correct rather than rewriting it
• Does not spend long on the batch size of 20 once the order and the readiness wait are understood

Follow-up questions

• The README's p99 alerts fired for zone-a, then zone-b, then zone-c, a minute apart. Which lines explain that?
• `wait_healthy()` returned for every instance. What was each instance doing for the next minute and a half?
• An instance fails to restart. What does the script do next, and what does it print at the end?
• Someone runs it with `--dry-run` to check the plan first. What happens?
• Twenty instances at a time is 11% of the fleet. Is that the problem?

Purpose

Capacity and dependencies are read here. Tests whether the candidate treats capacity as a number with a failure scenario attached rather than as headroom to spend. The separator is whether they ask what happens if a zone is lost while the script is running.

Signals to score

• Derives 20 per zone at peak from 60 instances and a need of 40, and says it out loud
• Asks what happens if a zone is lost mid-run, and works out that the other two zones then need 60 ready instances each at peak
• Concludes that at peak any instance out of service turns a zone failure into an outage for someone
• Moves the run to the daily low and redoes the arithmetic with the 35% figure — 14 ready per zone normally, 21 if a zone is lost
• Counts every instance that is not ready against the limit, including one that failed to come back, not only the current batch
• Wants the limit computed from the live ready count and live traffic when the script runs, not copied from the README
• Proposes working one zone at a time, and says why that keeps a failure to one zone
• Leaves a margin for instances that do not return, and says how big and why

Follow-up questions

• Zone-b is lost at 09:13, halfway through the run. How many ready instances does zone-a need now?
• Would you rather this ran at 09:00 or at 03:00, and what does the arithmetic say at 03:00?
• Three instances from the first batch never came back. Do they count against your limit?
• Where does the script get these numbers the day the traffic doubles?
• Why one zone at a time rather than an even spread across all three?

Purpose

Warns that the environment will change on purpose, so a candidate does not spend minutes doubting their own code when an instance hangs.

Purpose

Safe automation is read here. The load-bearing exercise. Most engineers who have run fleet operations have written a script like this and learned its missing safeguards one incident at a time; the separator is whether the stop conditions are built in before the stub forces them, and whether the script leaves the fleet in a known state when it stops.

Signals to score

• Makes a dry run the default and needs an explicit flag to act, and the dry run prints the whole plan: which instances, in what order, per zone
• Drains each instance before restarting it and bounds how long it waits for the drain
• Waits on `/ready` rather than `/healthz`, with a timeout, and treats the timeout as a failure rather than carrying on
• Enforces the per-zone limit by reading the zone's live ready count before each restart, not by choosing a batch size
• Stops the run when an instance does not come back, or after a failure budget small enough to state and defend
• Takes the zone's error ratio as a baseline before starting and checks it before each restart, with a threshold tied to the SLO rather than to zero
• Stops when the metrics call fails, and says why continuing blind is the wrong default
• Leaves nothing drained and forgotten when it stops, and prints what it did, what it did not do, and which instance needs a human
• Keeps a rerun safe — instances already restarted are no longer stale, so the filter skips them — and says so
• Reports counts from what happened rather than from the plan

Follow-up questions

• `ck-a-017` never becomes ready. What does your script do next, and what state is zone-a in when it exits?
• Zone-a's error ratio is 1.8% and the next restart is due. What happens?
• The metrics call just timed out. Carry on or stop?
• The run stopped halfway at 03:20. What does the person who started it see, and what do they do?
• Why that threshold and not zero?

Purpose

Safe automation is read here. Tests whether the candidate treats recurring operational work as a cost to be driven down or as a job to be done well forever. A candidate who has owned a service's toil has an answer with a date and an owner in it; one who has not proposes to schedule the script.

Signals to score

• Says the script treats a symptom, and that making it safe also makes the leak easier to live with
• Wants the leak measured — memory growth per instance per day, and how long an instance would last without restarts
• Hands the leak to the team that owns `checkout-api`, with that data, rather than absorbing it quietly
• Puts a condition or a date on deleting the script and writes it down beside the script
• If restarts must continue, restarts on memory crossing a threshold rather than on age, and says what that changes
• Counts what the restarts cost: someone's time each week, and requests put at risk against the error budget on every run
• Asks how anyone would notice the leak getting faster after a release, since the weekly restart hides the trend
• Says what has to alert if the script is scheduled and quietly stops running

Follow-up questions

• The checkout team says the leak is low priority because your script handles it. What do you say to them?
• Next month's release doubles the leak rate. How would you find out, and when?
• What would have to be true for you to delete this script?
• It moves from someone's Monday to a scheduler. What has to page when it fails?
• Age or memory — which should decide when an instance restarts, and why?