Project deep dives

Why it matters

A deep dive tests whether you understand your own work, and it is hard to fake. Interviewers ask "why did you choose X?", "what happens if Y fails?", "how do you know it was faster?" and "what would you do differently?", and each answer leads to the next question. Candidates often struggle not because the project was small but because they never wrote down the reasoning: the alternatives they dismissed, the numbers they measured, the incident that changed the design. For you, natural candidates are your cloud computing coursework, Agaria, and any thesis or research project from your master's. Each can support a strong conversation if you reconstruct it carefully, using only facts you can stand behind.

Core ideas

Context. One or two sentences on the problem and who it was for, then the constraints that shaped the design: team size, time, budget, required technologies, data volume, latency, cost or privacy requirements. Constraints explain decisions that otherwise look arbitrary.

Your contribution. State precisely what you designed, built, measured or decided, and what others did. "I designed the scheduler and wrote its tests; a teammate built the frontend" is credible; "we built a platform" is not. If someone else made a decision, say so and explain whether you agreed.

Decisions and alternatives. For each major decision (datastore, queueing, model provider, synchronous versus asynchronous processing, build versus buy), prepare the options, the criteria, the choice and what you gave up. Lightweight decision records with context, decision and consequences, as described in Michael Nygard's post on architecture decision records, are a good format for these notes, even when written after the fact.

Measurements. For every quantitative claim, know how it was measured: workload, environment, baseline, number of runs and what varied between them. Distinguish measured, estimated and remembered numbers, and drop any you cannot reconstruct. "We did not measure that; this is how I would measure it" is a respectable answer.

Failures and lessons. Prepare at least one thing that went wrong: a production bug, a design that did not scale, a missed deadline, an abandoned approach. Describe detection, diagnosis, fix and what changed afterwards, in the blameless style of a postmortem.

Unresolved limitations. Every real system has them: missing tests, a single point of failure, manual steps, unvalidated assumptions about users, costs that grow faster than usage. Naming them yourself, with what you would do next, signals judgment; being surprised by them signals the opposite.

Depth levels. Prepare a 2-minute version (problem, approach, your role, one result), a 10-minute version with the architecture and two decisions, and enough material for 30 minutes of questions. Let the interviewer choose where to go deeper.

Record all of this in the app's Project notes page, one entry per project. Fill it in from your own records (repositories, reports, commit history, dashboards), and mark anything uncertain until you have checked it.

Common misconceptions

• "The project must be impressive." A modest project explained with precise reasoning and honest limits beats a large one described vaguely.
• "Admitting limitations weakens the story." Interviewers probe until they find the limits anyway; naming them first shows you understand the system.
• "Round numbers up to sound credible." Inflated or unverifiable figures collapse under one follow-up and damage trust in everything else you said.
• "Tour the whole stack." Depth on the decisions that mattered beats a list of technologies, but be ready to explain anything you named on your CV.
• "Confidential work cannot be discussed." You can usually describe problems, decisions and lessons abstractly without revealing secrets; check what your agreements allow.

How to approach it

Pick two or three projects, starting with the one most relevant to your target roles. Gather primary material (code, reports, design notes, commit history), then complete the Project notes page: context, contribution, architecture, decisions with alternatives, measurements with method, failures, lessons and open limitations. Draw each architecture from memory and time your 2-minute and 10-minute versions. Then ask a peer to interrogate one decision for ten minutes with "why?" and "what if it fails?", and add every question you could not answer to your notes. Graduate candidates are judged mostly on clarity and honesty about their role; mid and senior candidates are expected to discuss tradeoffs, operations and what they would change with hindsight.