Turn an SLO Into an Interview Answer With a Small Node.js Error-Budget Drill

Most SRE interview answers go wrong before the candidate says a word about Kubernetes, queues, or databases. They start with architecture when the interviewer is listening for a decision: what users are experiencing, how much reliability budget remains, and what you would do first.

An SLO is useful in an interview because it turns a vague reliability opinion into a bounded trade-off. You do not need a production observability stack to practice that move. This tiny Node.js script calculates a monthly error budget and gives you three prompts to answer aloud.

What an interviewer is actually testing

Take a common prompt: “Latency is up and the checkout service is timing out. What do you do?” A weak answer begins with a long list of tools: dashboards, traces, logs, packet captures. Those are useful tools, but the list does not explain how you will make a decision.

A stronger answer has four observable moves:

1. State the customer impact and scope: which journey is broken, for whom, and since when?
2. Name the reliability guardrail: the SLO, the error budget, and the current burn rate.
3. Choose the smallest reversible mitigation: pause a deploy, shed nonessential traffic, roll back, or add capacity.
4. Separate mitigation from investigation: restore safety first; identify root cause and prevention second.

That order matters. A 99.9% monthly availability objective permits about 43.2 minutes of unavailability in a 30-day month. That is not a magical threshold that dictates one action, but it gives you a concrete way to explain why an action is proportionate.

A dependency-free error-budget drill

Save this as slo-interview-drill.mjs, then run node slo-interview-drill.mjs 99.9 30. The first argument is the target percentage and the second is the window in days. It uses only Node’s standard runtime.

const [targetArg = "99.9", daysArg = "30"] = process.argv.slice(2);
const target = Number(targetArg);
const days = Number(daysArg);

if (!(target > 0 && target < 100) || !(days > 0)) {
  console.error("Usage: node slo-interview-drill.mjs <target-percent> <days>");
  process.exit(1);
}

const totalMinutes = days * 24 * 60;
const budgetMinutes = totalMinutes * (1 - target / 100);
const scenarios = [
  { name: "checkout API", spent: 9, change: "pause a risky deploy" },
  { name: "search", spent: 18, change: "roll back a cache change" },
  { name: "login", spent: 2, change: "keep investigating before changing traffic" },
];

const percent = (value) => `${value.toFixed(1)}%`;
const minutes = (value) => `${value.toFixed(1)} min`;

console.log(`\nSLO target: ${target}% over ${days} days`);
console.log(`Error budget: ${minutes(budgetMinutes)} of downtime\n`);

for (const scenario of scenarios) {
  const spent = scenario.spent / budgetMinutes * 100;
  const remaining = Math.max(0, 100 - spent);

  console.log(`${scenario.name}: ${minutes(scenario.spent)} spent`);
  console.log(`  Budget consumed: ${percent(spent)} | remaining: ${percent(remaining)}`);
  console.log(`  Interview prompt: Would you ${scenario.change}? Why?\n`);
}

console.log("Answer structure: state the user impact, name the SLO/budget,");
console.log("choose the smallest safe mitigation, then describe the follow-up.");

Here is the useful part of the output for a 99.9% target over 30 days:

SLO target: 99.9% over 30 days
Error budget: 43.2 min of downtime

checkout API: 9.0 min spent
  Budget consumed: 20.8% | remaining: 79.2%
  Interview prompt: Would you pause a risky deploy? Why?

Do not treat the calculated percentage as an automatic “yes” or “no.” Nine minutes in checkout can be more serious than 18 minutes in an internal search service. The value is in making the missing context explicit: customer path, blast radius, rate of deterioration, reversibility, and what the last deployment changed.

Turn each prompt into a spoken answer

Use a two-minute timer. Read one generated prompt, answer it aloud, then grade the answer against this compact rubric:

Signal	What a good answer makes clear
User impact	The affected journey and whether the failure is partial or global
Guardrail	The objective, remaining budget, and whether consumption is accelerating
Mitigation	The smallest safe action that limits more harm
Evidence	The next metric, trace, or experiment that could change the decision
Follow-up	Ownership for root cause, alerting, and a prevention item

For the checkout example, a concise answer might sound like this:

“I would first confirm whether checkout failures are regional or global and freeze the deployment pipeline while I check the error rate and latency burn. We have used about one-fifth of a 43-minute monthly budget, but checkout is revenue-critical and the rate may be increasing. If the spike lines up with the cache rollout, I would roll it back because that is fast and reversible. Once the error rate stabilizes, I would compare traces before and after the rollout, write the incident timeline, and add a rollout guardrail if we did not already have one.”

Notice what this does not do: it does not pretend the exact cause is known. It commits to an action conditional on evidence and explains why the action is safe. That is much more credible than naming every monitoring tool you have used.

Change the inputs, not just the wording

Run the script with three targets: 99.5, 99.9, and 99.99. For a 30-day window, their approximate budgets are 216 minutes, 43.2 minutes, and 4.32 minutes. Now repeat the same scenario. Your rollback decision may be unchanged, but the urgency, escalation path, and acceptable experiment size should not be identical.

Then replace the hard-coded scenarios with incidents you have actually handled. Keep them anonymous, but use real constraints: a regional dependency, a recently changed flag, a stuck queue, an exhausted connection pool. Candidates often practice system design as if every question starts from a blank canvas. Senior reliability interviews frequently start with a running system and ask whether you can make a safe call with incomplete information.

A useful distinction: target versus policy

An SLO is a target for service behavior, not a universal permission slip. A team can have budget remaining and still halt a release because the affected path is safety-critical, contractual, or rapidly worsening. Conversely, a team can exhaust budget without making every engineer stop working; the response may be to defer risky work while the service is stabilized.

Say that distinction in an interview. It demonstrates that you understand error budgets as a communication mechanism between product, engineering, and operations—not a calculator that replaces judgment. The Google SRE Workbook’s chapters on service-level objectives and error budgets are a good primary reference for the underlying model.

If you want a second practice format, use the same rubric in a mock session. aceround.app — an AI interview assistant’s SRE preparation guide has role-specific prompts; bring your own incident context and use it to pressure-test the reasoning rather than memorize a script.

A five-minute practice loop

Before an interview, run this loop once per scenario:

1. Calculate the budget for the stated objective and window.
2. Name the customer-facing symptom in one sentence.
3. Choose one reversible mitigation and name the evidence that would make you reverse course.
4. Explain the investigation only after the service is safer.
5. End with one prevention change: an alert, rollout check, capacity limit, or runbook update.

The point is not to produce an SRE-sounding monologue. It is to make the decision process easy for an interviewer to follow. When you can state constraints before components, your system-design answer stops sounding like a diagram tour and starts sounding like operational judgment.

Sources

• Google SRE Workbook, “Service Level Objectives” and “Error Budgets”
• Google SRE Book, “Embracing Risk”

Disclosure: AI assisted with editing and code review. The author reviewed the final tutorial and verified the example calculations locally.