Prepare for your interviews

Put all four shifts on a single 24-hour line in UTC and look for the hours nobody is on it. Then look at where neighbouring shifts overlap.

1. Coverage runs continuously from 00:00 to 22:00 UTC: Manila to 09:00, Mumbai from 03:30, London from 08:00, New York from 13:00 until 22:00. Nobody covers 22:00–24:00 UTC, a two-hour gap every day.
2. Manila–Mumbai overlap 03:30–09:00, Mumbai–London 08:00–12:30, London–New York 13:00–17:00: all long enough. New York to Manila has no overlap at all: New York leaves at 22:00 and Manila arrives at 00:00. That is the broken handover, and it sits exactly on the gap.
3. 22:00 UTC is 09:00 in Sydney (UTC+11). A Sydney shift of about 08:30–17:30 local (21:30–06:30 UTC) covers the gap, overlaps New York by 30 minutes and Manila by six and a half hours, so both handovers work.

The point of the puzzle: a schedule can look complete team by team and still fail at the joins. Our handovers are formal briefings, which is why the overlap matters as much as the coverage.

A 30-day month has 30 × 24 × 60 minutes. The error budget is the share of that the target allows you to miss.

1. 30 × 24 × 60 = 43,200 minutes. 0.1% of that is 43.2 minutes.
2. 31 minutes are already used, leaving 12.2. The upgrade’s worst case is 15 minutes, so a bad outcome would break the target. Options: wait until next month’s budget, make the upgrade safer (a tested rollback, a replica to fail over to, doing it in a low-traffic window), or agree with the client that this change is worth the risk. “No” is rarely the whole answer; “not like this” usually is.
3. At 99.95% the budget is 21.6 minutes, and the service has already missed its target at 31 minutes. The conversation is no longer about the upgrade; it is about the two incidents and what the client is owed under its service levels.

Add up each row. Then look at the month-to-month changes, row by row and column by column.

January, February and April add up. March’s branches add to 4,301 + 3,198 + 2,688 = 10,187, not 10,287: the total is 100 too high.

Which figure is wrong? If the total is right, one branch would be 100 short. But then that branch would jump by about 140 in a month and fall back the next, while the others move by 25 to 60. If the branches are right, the totals rise steadily: 10,005, 10,103, 10,187, 10,296. A single-digit typo in the total (10,187 written as 10,287) is much the likelier story. Branch B’s small dip in March is real and worth a question, not a correction.

What we look for: you checked every row, not just the one that looked odd; you said how confident you are; and you would confirm with the client rather than silently “fix” their data.

Work out requests first, then minutes (first submissions plus resubmissions), then hours, then people. Keep each step on its own line so someone else can check it.

1. Requests: 12% × 18,000 = 2,160 plus 30% × 2,400 = 720, so 2,880 a month, or 2,880 × 12 ÷ 52 ≈ 665 a week. Time: 2,880 × 20 = 57,600 minutes, plus 15% × 2,880 = 432 resubmissions × 20 = 8,640 minutes, so 66,240 minutes = 1,104 hours a month, or 1,104 ÷ 140 ≈ 7.9 full-time staff.
2. With the tool: 2,880 × 12 = 34,560 minutes; resubmissions fall to 7.5% = 216 × 20 = 4,320 minutes; total 38,880 minutes = 648 hours, or about 4.6 staff. It saves 456 hours a month, about 3.3 full-time staff. Before recommending it, you would want to know whether the 20-minute and 15% figures were measured or guessed, and what happens to the people whose time is freed: in most health systems that time goes to the backlog and to patients waiting for an answer, not to cuts.

Find the longest chain of changes that have to happen one after another. That chain sets the earliest finish.

1. The longest chain is A → B → E: 90 + 45 + 40 = 175 minutes. D (60) runs alongside A and finishes long before B needs it; C (30) fits in after D. One plan: engineer 1 does A 01:00–02:30, B 02:30–03:15, E 03:15–03:55; engineer 2 does D 01:00–02:00 and C 02:00–02:30. Everything is done by 03:55, leaving 65 minutes of slack.
2. No. Found at 03:55, rolling back B (30) then A (60) takes until 05:25, 25 minutes past the window. The fix is a check, not more speed: verify A properly at 02:30, before B starts, and make that a go/no-go point. If A fails there, rolling it back alone ends at 03:30, well inside the window.

The lesson travels: put checks where a failure is still cheap to undo.

The app can’t tell “the payment failed” from “the payment worked and I didn’t hear back”. What could the request carry so the server can tell?

1. The request was not idempotent: the server treated the retry as a new payment. Blame doesn’t help; retries on unreliable networks are normal, and the API has to expect them.
2. The app creates a unique idempotency key for the payment once, before the first attempt, and sends it with every retry. The server stores the key with the result in the same database transaction as the payment. A repeat key returns the stored result instead of paying again. A repeat key with a different amount or account is refused, because that is a bug, not a retry. Keys are kept long enough to cover every retry (say 24 hours). If two copies arrive at the same moment, a unique constraint on the key makes one of them wait or fail cleanly.
3. An alert on duplicate payments (same member, amount and payee within a short time), a daily reconciliation against the ledger, and a log of every refused key mismatch. In a bank, you also want an easy way for staff to see what happened and reverse it.