Preparing Stories From Past Projects
The final stage of a hiring process is a conversation that looks like a discussion of your background but is really assessing one question about your experience.
A Conversation That Looks Casual
Imagine you have passed every earlier stage of a hiring process and only one remains. The final stage is a conversation with the hiring manager or with the head of the FDE function. Many candidates expect a relaxed chat about where they have worked and what they have built. On the surface, that expectation is accurate. Underneath, the meeting has a more specific purpose, and preparing for it well means understanding that purpose before you think about your résumé.
What do you think happens?
Two candidates describe the same project. Candidate A lists the technologies and the final outcome. Candidate B describes a production problem, the decision they made about it, and what they changed afterward. Which one gives the interviewer what the final conversation is looking for?
Reveal answer
Candidate B
The source says specific stories matter more than polished summaries. A strong answer names a real production system, a concrete challenge, your reasoned response, and a lesson you now apply. A list of outcomes alone does not show what you learned, and that is the part the interviewer is trying to assess.
Tracing the Hidden Question
The source describes the final conversation in two layers. The surface layer is a discussion of your background: your past roles, your projects, and your decisions. The layer beneath it contains one question the interviewer wants answered. Do you have scars from shipping production systems in messy customer environments, and what did you learn from them? Every surface question is a way of bringing that single question into focus.
The practical consequence is that a polished tour of your career is not enough. You can describe every project in detail and still leave the interviewer without the answer they came for, because the question underneath is about your hands-on experience and what it taught you, not about the list of things you have done. When you hear a surface question, ask yourself which part of the hidden question it is probing, and let your answer address that part directly.
What Scars Means in Practice
Having scars means having hands-on experience shipping production systems and learning from the challenges, ideally in messy customer environments. The word describes experience that left a mark: you were responsible for a system that real users depended on, and the difficulties you met changed how you work.
The source places this experience specifically in messy customer environments. The point is not only that a system went live. It is that it went live under conditions where real customers, real data, and real constraints made the work harder than a clean demonstration would suggest. A system that worked in a controlled setting tells the interviewer less than one that had to survive real use.
The source frames the conversation around two things you must demonstrate. The first is evidence: specific, concrete proof that you were responsible for a production system operating in a customer setting. The second is the lesson: a clear account of what went wrong or what was hard, what you did about it, and what you now understand differently. Evidence without a lesson is a description, and a lesson without evidence is a claim. The conversation needs both.
The Evidence Chain Behind a Good Story
The source describes what a strong answer contains: a real production system, a concrete challenge, your reasoned response, and a lesson you now apply. These four elements form a chain. Each one depends on the one before it. The system gives the challenge its setting, the challenge gives your response its reason, your response produces the outcome, and the lesson is what you carry forward from that outcome.
Turning a Task List Into an Evidence Chain
A candidate writes: I built a reporting feature and fixed some bugs. The candidate wants to rewrite this as a story the hiring manager can use as evidence. This example is hypothetical and written for teaching purposes.
- 1Name the production system
Replace the vague reporting feature with the specific system it lived in, such as a customer-facing dashboard that real clients used every day.
- 2State the concrete challenge
Describe the actual problem, for example that reports slowed down badly once a large customer loaded months of data, which the clean test data had never shown.
- 3Describe the reasoned response
Explain the decision and its reasoning, such as why the candidate chose to change how the data was queried rather than simply adding more servers.
- 4Close with the lesson
State what the candidate now applies, such as always testing with production-scale data before a release, and say where that habit has been used since.
The rewritten story contains a real system, a real challenge, a reasoned decision, and a lesson. It gives the interviewer the evidence and the lesson the source says they are looking for, where the original version gave only a list of tasks.
Scars Versus Untested Experience
The difference between a story with scars and one without is not the size of the project. It is whether the story shows contact with real production conditions and a lesson drawn from them. The comparison below sets the two side by side. The signal the hiring manager receives changes accordingly: one story points to hands-on responsibility and learning, while the other points only to activity.
A story with scars gives the interviewer evidence of responsibility and a lesson they can weigh. A story without them, however detailed, leaves the hidden question unanswered. The interviewer may conclude you have worked on systems but has not learned how they behave when they are under real pressure from real customers.
Mistakes in the Final Conversation
Common mistake Treating the conversation as a career summary
What it looks likeWalking through every role in chronological order without naming a single hard problem.
Why it failsThe source says a polished tour of your career is not enough, because the hidden question is about hands-on experience and what it taught you.
Do this insteadPick one or two real production stories and tell them in full, with the challenge, your response, and the lesson.
Common mistake Describing outcomes without the decision behind them
What it looks likeSaying the system now handles high load without explaining what caused the original failure or why you chose your fix.
Why it failsAn outcome shows that something changed, but not that you reasoned about the change. The interviewer assesses how clearly you can reason about the project.
Do this insteadAdd the reasoned response: what you considered, what you chose, and why.
Common mistake Using a clean demonstration as the example of hard work
What it looks likePresenting a project that only ran in a test environment as proof of production experience.
Why it failsThe source places scars in messy customer environments where real data and constraints make the work harder than a clean demonstration.
Do this insteadChoose a story where a real system faced real customers, or be clear about the conditions in which the work was done.
Common mistake Leaving out the lesson, even when the story is strong
Reflecting on Your Own Past Work
The source asks you to be able to tell a story that answers the underlying question. You can begin with a single project you have worked on. Do not try to cover everything. Focus on one production system and one moment when it was hard.
Choose one project you have been responsible for in a real or customer-facing setting. Write four short sentences: name the production system, describe one concrete challenge it presented, explain the response you chose and why, and state one lesson you now apply. Then check whether the lesson is something you genuinely changed in your work, not a general statement.
Hints
- If you cannot name a production system, consider whether the project reached real users or only ran in a test environment, and say that honestly.
- A challenge is specific when a stranger could picture the problem. Replace general words like issues or problems with the actual symptom.
- A lesson is strong when you can point to something you do differently now, not only something you now believe.
Key Takeaways
- The final conversation in a hiring process looks like a discussion of your background, but it assesses one underlying question about your experience.
- Having scars means hands-on experience shipping production systems and learning from the challenges, ideally in messy customer environments.
- The hiring manager looks for evidence of that experience and for the lessons you learned, so specific stories matter more than polished summaries.
- A strong answer names a real production system, a concrete challenge, your reasoned response, and a lesson you now apply.