Hiring-manager deep dive: your on-call experience and your hardest project

In a hiring-manager round that was scheduled as a system design interview, the conversation instead became a deep dive into the candidate's resume. The interviewer asked about the candidate's on-call experience and about the hardest project they had worked on, and pushed on each with many follow-up questions. The candidate's overall impression was that the loop weighted behavioral answers and trade-off discussion heavily. ### Clarifying Questions - Should the on-call answer focus on one specific incident or on the rotation as a whole? - How technical should the project discussion be: architecture and trade-offs, or mostly scope and impact? ### Part 1 — On-call experience Describe your on-call experience: how the rotation worked, and one incident you handled from the first alert to the follow-up work. ```hint One incident, step by step Choose an incident in which you made the key calls, and be ready to say what you saw, what you tried first, and why. ``` #### What This Part Should Cover - The rotation and your responsibilities in it, with concrete scale - One incident told from detection through mitigation, root cause and follow-up actions - What you changed afterwards to reduce pages or shorten recovery ### Part 2 — Your hardest project Walk through the hardest project you have worked on: why it was hard, what you personally did, and how it turned out. ```hint Hard for a reason Name the specific source of difficulty, whether technical, organizational or ambiguous scope, and prepare the decision you would defend under questioning. ``` #### What This Part Should Cover - The problem, its constraints, and why it was hard rather than merely large - Your own decisions and the alternatives you rejected, with reasons - Measurable results, what went wrong, and what you would do differently ### What a Strong Answer Covers - Specific, verifiable details that hold up through several layers of follow-up questions - Clear ownership, with "I" and "we" used accurately and no overclaiming - Trade-offs explained in technical terms, with the constraints that applied at the time - Honest reflection on mistakes, linked to what you now do differently - Concise answers that leave room for the interviewer's probes ### Follow-up Questions - What was the worst page you received in the middle of the night, and what did you do in the first fifteen minutes? - How did you make sure the same incident did not happen again, and how did you know the fix worked? - If you restarted the hardest project today with the same constraints, what would you change first? - Which part of the project would a teammate say you contributed least to, and why?