Follow-Up Questions
Why interviewers dig into every story, the follow-ups they ask most, and how to prepare so your answers hold up when they do.
How It Works
Your first answer is the opening, not the whole answer. Many interviewers spend as long on follow-ups as on the story itself, because a prepared story is easy to tell. The follow-ups test three things a polished first answer can hide:
- Depth. Do you understand why things happened, or only what happened?
- Ownership. Which parts did you personally do, decide or push for?
- Truthfulness. Does the story hold together when someone pulls on it?
A rehearsed story that isn't real, or isn't really yours, rarely survives three follow-ups. The details get vague, the numbers shift, and "I" quietly turns into "we". A true story you know well gets better under questioning, because each answer adds something the first telling had no room for. The follow-ups themselves are predictable, so have an answer to each of these for every story in your story bank:
- "What did you do specifically?" Your part, separate from the team's, in concrete steps.
- "Why that approach?" The constraint, risk or data that made you choose it.
- "What else did you consider?" At least one real alternative, and why you turned it down.
- "How did you measure it?" Where the number came from, and what it was compared to.
- "What would you do differently?" A real change, not "nothing" and not a boast in disguise.
- "What did your manager or teammates think?" Who agreed, who didn't, and how you know.
To prepare, go through each story and write down what a follow-up will reach for: the numbers and where they came from, the before and after, the alternatives you rejected and why, the people involved and what each of them did, and what went wrong along the way. You won't say most of it in your first answer. It's there so the third answer comes as easily as the first.
You won't remember everything, and that's fine. When you don't know a detail, say so, then give the estimate you can stand behind and how you know it: "I don't remember the exact figure. It was at least 30 percent, because it got us under the limit we'd set." Don't invent a precise number on the spot. If it changes in a later answer or doesn't fit the rest of the story, it costs you more credibility than "I don't remember" ever would.
Stay consistent. Your interviewer is taking notes, and other interviewers in the loop may hear the same story or a related one. The team size, the timeline, your role and the result should match every time you tell it. That's easy when the story is true and you've written its facts down once, and hard work when you're improvising.
What Interviewers Listen For
- Details that come easily and fit together: numbers, systems, the order things happened in.
- A clear line between what you did and what others did, held steady under questioning.
- The reasoning behind your choices, including the options you turned down.
- Honesty about what you don't remember and what went wrong.
- A story that stays the same each time you're asked about it.
Sample Answers
The Question
After a story about fixing a slow report page, the interviewer asks: "What did you do yourself, and how do you know it worked?"
Try drafting your own answer first, then compare. Both answers are invented.
Show Sample AnswersHide Sample Answers
A Common Answer
I was pretty involved in all of it, honestly. I did a lot of the backend work and helped out with the frontend and the testing. We checked our monitoring afterward and the page was way faster, I think something like 70 percent faster. The customers stopped complaining, so it definitely worked.
A Strong Answer
My part was the database side. The page ran a separate query for every account a customer had, so our biggest customers set off a few hundred queries on each load. I found that with query logging in staging, then replaced them with one grouped query and an index on the two columns it filtered on. Dana, a frontend engineer on my team, paginated the table so the browser stopped drawing thousands of rows.
To know it worked, I tracked load time for the slowest 5 percent of loads, since those were the complaints. For our largest accounts it went from about 9 seconds to under 2, and those numbers are in the release notes. Database load in the morning rush dropped too. I don't remember by how much, only that it was enough to cancel the database upgrade we'd planned that quarter. Our two changes shipped together, so I can't split the load time gain between us, but the database savings were all from the query work.
Why It Works
- The strong answer draws a clear line between the candidate's work and a teammate's, and names both. "Pretty involved in all of it" is the kind of answer that makes an interviewer dig harder.
- It says where each number came from. The weak answer's "something like 70 percent" invites the next question, "70 percent of what?", with nothing behind it.
- When the candidate doesn't remember a figure, they say so and offer what they can stand behind instead: the upgrade they no longer needed.
- The caveat shows the candidate understands the result well enough to know its limits, which earns more trust than a tidier claim would.
Common Pitfalls
- Preparing only the two-minute version. The first answer is the part you control, and the follow-ups are often where the score is decided.
- Inventing a precise number on the spot. If it shifts later or doesn't fit the story, it costs you more than "I don't remember" would have.
- Getting defensive. A follow-up isn't an accusation, and an irritated "like I said" reads as someone who's hard to work with.
- Retreating to "we" when asked what you did. That's exactly what the question was checking.
- Telling a story that isn't yours. A teammate's project retold in the first person tends to come apart at the second "why".