The Menu Technique
Letting your interviewer choose stories so you don't have to
🙋♂️ Hi there, I’m Austen, a former Senior Engineering Manager and Hiring Committee Chair at Meta where I did over 1,000 interviews and trained 100s of interviewers. I’m also the author of the upcoming book, Mastering Behavioral Interviews, which gives you the coaching and tools to get the roles that matter most in tech.
This is an short excerpt from the book’s Refine and Practice section. It’s timely this week, as I think I’ve discussed this topic with multiple Principal/L7 candidates in practice sessions. It tends to be a technique more
BOOK UPDATE: I’ve incorporated feedback from the last round of reviewers (thank you!) and still waiting on the physical book proof to arrive in the mail. Book website is live, check it out!
Sometimes the best way to ensure you’re delivering the signal an interviewer is looking for is to let them choose from your available stories. The Menu Technique is simply offering 2–3 relevant stories and their key takeaways, then asking the interviewer which one they’d like to hear in detail.
Time is short in an interview and this approach transforms you from someone guessing at what the interviewer wants, potentially spending precious minutes on sub-optimal stories, into someone who adapts in real-time to deliver maximum signal.
When to Use the Menu Technique
Interviewers don’t want options for every question they ask. If there’s an obvious story choice go with that one. But there are some situations where the Menu Technique will be well received:
You have stories with very different takeaways. When your available stories demonstrate different aspects of your capabilities, offering options ensures you showcase the skills the interviewer wants to see. For example, one conflict story might demonstrate technical leadership while another shows cross-functional relationship management.
The interviewer has shown an inclination for specificity. If an interviewer has already asked for “another example” or “something different,” they’re signaling that they want particular types of evidence. Rather than guessing again, offer them choices.
You’re in a time-sensitive part of the interview. When you sense the interview is running short and you want to maximize signal delivery in the remaining time, the Menu Technique ensures you don’t spend precious minutes on a story that doesn’t address their core concerns.
You don’t understand what the interviewer really wants. Sometimes interview questions are ambiguous or could be interpreted multiple ways. Instead of picking the wrong angle, present options that cover different interpretations.
Follow-up interviews or targeted signal gathering. When you know an interviewer has been specifically tasked with assessing certain competencies, offering a menu helps them efficiently gather the exact signal they need.
How to Structure a Menu
When presenting options, briefly describe each story and explicitly state what signal areas or insights the interviewer will gain. This helps them make an informed choice rather than just picking randomly.
Tell me about a time when you resolved a conflict.
❌ Well, I resolved a conflict while working at the fintech startup and a conflict I had in my most recent job. Which one would you like to hear?
Here the interviewer has no context on which one would provide the signal they’d like to collect.
✅ I have a couple of examples I could share that demonstrate different aspects of conflict resolution.
First, I have a story about resolving a technical disagreement with another senior engineer over our microservices architecture—this would show you how I handle peer-level conflicts using data and prototyping to drive decisions.
Second, I could tell you about a conflict I had with a product manager over feature prioritization during a tight deadline—this one demonstrates how I navigate cross-functional disagreements while balancing business and technical constraints.
Which one would you like to hear?




Hi Austen, Thank you for your inputs.
As a senior engineer candidate sometimes I have good story about 4 years old. Is it ok to use it?
For example: During my first project as lead developer I missed something during development but my manger pointed out that helped me learn something and now using that learnings till now. (Critical Feedback ). Thanks