Loading…
Debug Intermittent Login Failures in Production is a medium troubleshooting interview question covering troubleshooting, intermittent failure, blast radius, incident response, monitoring and alerting — the kind asked at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies like Anthropic, OpenAI, and Nvidia.
Support has escalated a handful of reports: customers say the login page does not work sometimes. There is no error rate attached, no start time, and no list of affected accounts. You have access to the request logs, the dashboards and the deploy history. Work out what is wrong - and decide what you would do first.
That's it. No further details. This is intentional — your first job is to scope the problem by asking the right clarifying questions.
The interviewer has a specific cause in mind and will not volunteer it. What they are assessing is whether you can turn "some customers say login is broken sometimes" into a bounded problem before you touch a dashboard. Almost every candidate who does badly here does the same thing: they start listing plausible causes and asking to check logs, which means every answer they get tells them nothing, because they never established what fraction of logins are failing or when it started. The candidates who do well spend their first two minutes on scope — how many, which users, since when, correlated with what change — and treat every subsequent step as an elimination rather than a search. The second thing being assessed is whether you separate stopping the damage from finding the cause: if a deploy went out an hour ago and logins are failing, the answer is to roll it back and then investigate, and a candidate who works toward root cause while customers cannot log in has the priorities of someone who has never been on call.
Work through the Clarify phase by asking questions one at a time — just like a real interview.
Each answer reveals why that question matters and how it changes your design decisions.
Once you've clarified enough, unlock the narrowing ladder, the causes it is usually consistent with, and how to tell them apart.
The round is scored on method, not on the answer. Establish the blast radius before forming a theory: what percentage of login attempts fail, since when, is it the same users repeatedly or a random scatter, and did anything change at the start time. A stable small percentage that repeats per user points at something not uniform across the fleet or across accounts - one bad instance behind a health check that does not test the broken path, or one session-cache shard. A deploy the same morning makes a rollback the correct first action regardless of whether it turns out to be the cause, because it is fast and reversible. Then group failures by instance and by shard before reading any logs: log reading is unbounded until the scope is known.
A full interview loop is more than one round. These are the others, each with what is on the site for it.