“Premature optimization is the root of all evil,” and while Don Knuth, writing in 1974, surely didn’t mean the hyperoptimization we apply to our lives in this AI-pilled age, he was surely right. If you live in a tech hub, you know everyone around you is anxious about accomplishing more with their agents and dominated by a fear of being left behind. Like a gas, work expands to fill whatever container we put it in, and it’s exhausting.

Nothing has broken that spell for me like our recent trip to Ethiopia to visit my wife’s family. Life is slower here: the taxi may or may not come inside the two-hour window the driver gave you. If he does come, you’re likely to get stuck in a traffic jam produced entirely by drivers refusing to yield to each other. You wait constantly, even for simple things. At the National Palace, it took thirty minutes for our guide to negotiate an entrance fee, something that would take thirty seconds of computer-assisted purchasing in America.

Of course, slower life isn’t always bad. Coffee here is made from scratch, the beans roasted right in front of you, and it’s the best coffee I’ve ever had. It doesn’t make me anxious and I don’t experience an emotional crash at the end of the day.

And there can be real joy in doing things the slow way. I’ve often connected more with manual equipment or that which requires regular maintenance. I once scoured Facebook Marketplace for an old Coleman white gas lantern and hand-pump camp stove.

My latest manual interest is a Fujifilm X-E2 I picked up second hand with a cheap 40mm-equivalent f/2.8, joining the retro camera trend about a decade late. Setting aperture and shutter speed on physical dials has made me better at the exposure triangle and the lightweight body and prime lens make for a more focused and simpler shooting experience than my Canon R8 with its heavy zoom lens.

Take Time for Your Behavioral Prep—and Start Earlier

Like with the manual camera, sometimes you get better at things by doing them slowly. And that turns out to be true of behavioral interview prep too.

I keep getting clients who come to me with an interview in a week, or even tomorrow. There are things we can do together like cleaning up existing stories or brainstorming some framing with the hiring manager, etc. But if we run into fundamental challenges—like missing appropriately scoped stories—there’s just not enough time to make up for it. This is especially true for candidates targeting frontier labs with demanding culture expectations.

The candidates who do best have been working on their behavioral prep for a month or more, because remembering and emotionally processing your career, or developing a personal philosophy about AI safety, just takes time.

Try not to cram for behavioral interviews. Take it slow by starting to journal—or even go for a walk—and think about the hardest things you’ve done. And of course, check out my other content for detailed, step-by-step approaches to prepare.

July 2026 Coaching Notes

I conducted 32 sessions in July, mostly with senior ICs and managers preparing for FAANG and frontier lab loops. Here are some notes.

Give every big story a table of contents. When you go to tell a story, especially a long one, the temptation is just to dive in and give a long timeline-oriented description, leaving the job of extracting the most relevant parts to the interviewer. While sticking it to the interviewer might seem appealing, that’s not a great strategy to get hired. After brief context, list three or four dimensions where the signal lives, like the architecture decisions, the conflict, the rollout, the follow-on work, or whatever, then work through them one by one, steering the conversation in a partnership with the interviewer.

Front-load the results, scope, and stakes. Assume you will get cut off before the end of your story. Lead with the business impact and the scale. Despite when the Results are supposed to be shared in STAR or CARL, don’t save them for the end.

Stop shrinking your scope. People introduce a year-long platform they led as “just the personalization piece,” or flatten a real win into “I built a Claude skill” instead of “I raised my team’s velocity.” The scope you name is the scope you’ll get judged at.

Narrate the thinking since thinking is an action too. At Staff+ or Director levels, they’re hiring you to think. Be sure to list the alternatives you considered at each decision point and why you chose the one you chose. Several candidates this month made excellent calls but forgot to tell me about the reasoning.

AI questions are standard now, and most people have gaps. Interviewers are probing five areas — work, trust, iteration, growth, scaling. The “how can you trust the output” and “how do you stay current” buckets are the ones most often empty. Look out for a deeper explanation of this in an article in September.

Slow down. For senior rounds, answering within two seconds usually works against you. Anthropic’s culture round in particular is watching you while you reason through a difficult situation, and a fast answer seems overly rehearsed. Back to, “Premature optimization...”

September coaching slots are filling. If you expect to interview in the next few months, grab some coaching time now. Or pick up my best-selling book Mastering Behavioral Interviews for the complete prep system.

I sat down with Marina Petrović—ex-Google, ex-Meta recruiter turned career coach—and she spilled ALL the tea on how recruiting actually works at Big Tech.

Marina’s been on both sides of the table: bartending in NYC (when java was a drink) and running hiring pipelines at two of the biggest tech companies in the world. There are some insightful segments in our conversation and I encourage you to check it out if you’re in the tech job market.

So, a recruiters friends or foes?
Recruiters are not working for you but they aren’t working against you either. They work for the company but your success is their success. They have hiring goals. If you get hired, they hit their numbers. So they’re actually hustling for you and you can make their advocacy for you smoother if you rock the initial call...

The recruiter call is a restaurant date
Speaking of that, you know how people say “watch how your date treats the server”? Marina is watching how you treat her in that first call. If you open with “Ugh, it’s been one of those days,” she’s thinking: If this is how you talk to me, what are you gonna say to my hiring manager? Give the recruiter a pitch they can turn around and give the hiring manager as to why you’re the right person for the role.

Some hot takes from our conversation:

🔥 Never give your salary number first. Flip the script: “What’s the budget for this role?” Let them anchor, then negotiate.

🔥 At startups, ask: “Is this budget even approved?” Marina’s seen hiring managers recruit candidates... only for finance to pull the funding. Don’t waste your time on ghost jobs.

🔥 “Passion for Rust” on your resume is useless. You either have Rust experience or you don’t. Save the passion talk for LinkedIn.

🔥 Linked your GitHub on your resume? It better be green. “If I go to GitHub and it’s empty, I’m like... okay, so...”

🔥 No LinkedIn recommendations = red flag. Marina’s internal monologue: “Nobody likes you. Nobody likes to work with you.” I don’t think I have any recommendations on my LinkedIn, need to fix that...

🔥 Keyword-stuffing your resume? “Boo.” Hiring managers may drill into every single technology you list. Only put what you can actually defend.

I had to ask about negotiation since I’m so horrible at it personally:

• Companies EXPECT you to negotiate. If you just say yes immediately, they think it’s weird.

• Don’t accept verbal offers on the spot. Get it in writing first—that begins your leverage.

• Base salary is hard to move, but sign-on bonus is easier to negotiate since it’s often a different approval process.

If you want to get feedback on your performance:
You’ll almost never get written rejection feedback from a big company for legal reasons. But get your recruiter on an actual phone call and maybe they’ll tell you more.

Thanks Marina for such a lovely conversation!

Marina coaches mid-to-staff level engineers on networking, resumes, and interviewing, and works with them until they find a role.

Find her on LinkedIn.

Recently, I got a chance to attend a Silicon Valley meetup and tech talk hosted by and Augment Code. It was classic San Francisco: a posh spot in the Ferry Building overlooking the Bay, charcuterie boards, some geeky presentations, and a bunch of somewhat shy people talking about coding with AI.

I felt nervous going in, as I always do with these things, but came out with a bunch of new contacts.

If you’re prepping for behaviorals, you’re probably networking to find open roles as well. Let me tell you about how I’ve gone from one of the most insecure wallflowers to someone the organizer of that meetup says is (apparently) an expert networker:

First, Change Your Mindset

All your actions come from within, borne of your beliefs. If you want to be a great networker, you have to start by establishing the following truths, inside yourself. The tactics I discuss in the next section won’t work otherwise:

Everyone is just as uncomfortable as you are. Seriously. Even the people who look like they’re working the room (even me). Most people at meetups feel the same undercurrent of social anxiety about breaking into conversations and introducing themselves to total strangers. You’re not uniquely bad at this. You just haven’t figured out how to overcome it yet.

Everyone wants to talk to you. This is a significant difference between meetups and other social situations. At a bar or a party, people might or might not want to be approached and your brain is cautious about potential rejection. At a tech meetup, everyone showed up explicitly to network. That’s why they’re there. Ok fine, there’s often a talk of some kind, but the talk is not really the point. This means you don’t need to earn your way into a conversation and you’re very unlikely to be rejected.

Relationships make life worth living. Not to get too philosophical but you’ve probably figured out by now that good relationships are a key to having a good life. Decide that meeting new people makes your life richer and fuller and that will make you genuinely interested in the strangers you’re about to encounter.

Meditate on these things. You know they are true. Let them change you from the inside.

On to Tactics...

If you struggle meeting people at these kinds of events, and you’ve internalized the three above mindset shifts, let me give you a set of tactics that work for me, roughly ordered from (socially) easiest to hardest.

Take a wingman

Going it alone is always harder than bringing a friend. If you have the opportunity, get a friend to go with you to the event. You’ll feel so much more at ease with at least one friendly face there. If things get overwhelming, you can always seek out your friend for a respite.

The risk will be that you end up talking to each other all night. Agree to apply some of the other tactics I discuss below, separately, and then come back together and introduce each other to the new folks you’ve met.

Come in with a plan

Before you go to an event, prepare two or three conversation-starter questions. Something like:

• “How are you leveraging AI in your current role?”

• “What do you want to get from being here?”

• “What’s your take on (topic the meetup is about)?”

Even though I’m not a journalist and I’m not going to curate what I hear, it’s almost like I’m doing research on the room and somehow that helps me see purpose and meaning in talking with total strangers.

Use downtime

One of the easiest places to start a conversation is somewhere you’re already stuck waiting—the food line or sitting in the rows right before the presentation.

You and the stranger are both just waiting there.
In silence.
How boring for both of you.

You’re not interrupting anything if you talk with them. Just say hi and introduce yourself. It works because it’s low stakes. Again, they came to this event to connect with people. They won’t mind.

Leverage familiar faces

If you’ve managed to talk to a few people, or you brought a wingman, look for those familiar faces in conversation pods of other people. It should be easier for you to go up and join their conversation when you know you’ll be introduced by this familiar person.

Obviously, this presents an exponential growth opportunity for you to connect with new combinations of people.

Move around the room

While I was at this meetup in SF, I saw a forlorn individual, standing at one of the tables off to the side, just eating the snacks. For like 20 minutes. Clearly they wanted to meet people—I mean, they could have just left—but didn’t have skills to do so. I regret not saving this person and if you’re out there reading this, I’m sorry.

But if you go to these meetups, you do need to move around the room. Go get a snack. Go move to a different table. Go to the bathroom. Even just walk around between the groups of people. As you move around you’ll find opportunities to apply one of the other tactics.

If you stay put and wait for people to come to you, it may never happen.

There’s a corollary to this, which is that just because you’ve found a few people to talk to, don’t talk to them the whole night. It’s comfortable and you won’t have to overcome the social friction of meeting new people but that’s not your goal.

Be happy and curious

In these meetings with strangers, people have only the most raw social cues to consume. They don’t know you, your personality, or that you’re really a nice person inside. They are simply judging you by the look on your face and your body language. If you want people to talk to you, put an amicable look on your face. Smile.

Also, it was good advice when your mom gave it to you before that big Prom date and it’s good advice now: people just want to talk about themselves. Once a conversation starts, ask questions about them. You’ll come across as genuinely curious (because you should be), and you’ll make the other person feel good about the conversation. Ask follow-up questions. Let them go deep on something if they want to.

Prey on newcomers

I did this at a different meeting recently in SF: post up near the entrance and talk to some people as they come in. First, they obviously aren’t talking to anyone yet. Second, they are probably super nervous, just like you were when you walked in, and will be grateful for someone who’s enthusiastic about meeting them.

At this other meetup I mentioned, I did this probably too obviously, to the point where people started asking me, “Do you work for (sponsoring company)?” lol

Just walk up and stand next to a group

Ok, here we go, probably the hardest but most effective tactic to employ. Find a group of three or more people, walk up, and stand near them. Give it a moment. They will almost always shift to include you.

People at meetups are doing this constantly. Nobody is trying to form an impenetrable circle. When someone walks up, the natural instinct is to open the group. Trust that it will happen.

Boom, now you’ve met three new people.

A Note on Talking to the Speakers/Organizers

At most meetups, there are one or two featured speakers or guests—the principals who gave the talk, ran the panel, or are there in some official capacity. These people are worth talking to, and many attendees are too intimidated to approach them.

A few things that work:

Have a specific question ready. Not a generic “great talk” comment since that doesn’t go anywhere. Prepare something that shows you actually engaged with what they said, or something that’s relevant to their work. “You mentioned X — I’ve been thinking about that in the context of Y, what’s your take?” That kind of thing opens a real conversation.

Don’t linger too long. Principals have a lot of people who want their time. Have your conversation, get what you came for, and move on. Don’t monopolize. They’ll remember you better for being efficient and respectful.

Ask to connect on LinkedIn before you leave. The worst they can say is no. Send them a request later with a message that references your conversation.

And don’t be afraid to walk up. They can probably leave anytime they want so if they’re still there, they still want to talk to people. Don’t talk yourself out of approaching because it feels presumptuous. It isn’t.

These events are worth going to. Your next role will probably come from someone you know so get out there actually know some people.

It can be challenging. I get it, it’s challenging for me too. But it does get easier, and the rewards—new connections, job leads, the occasional collaboration that you couldn’t have predicted—will come.

Like what you’re reading? Subscribe below for posts about behavioral interview prep and landing roles at top tech companies, from me, a former Meta hiring committee chair and Senior Engineering Manager.

Subscribe now

If you’re a senior+ engineer, PM, or leader preparing for behaviorals and want to spend some time with me, check out more at https://thebehavioral.tech/coaching

Here are the notes from this week, all from senior+ engineering candidates…

Strategy first, tactics second, on every leadership question
When I asked one candidate how they maintain high engineering standards, they gave me design docs, unit tests, and code reviews. Seems legit, but not what a senior manager sounds like. A senior manager leads with a point of view, something like “I build for autonomy and high ownership, which means I invest heavily at the front of a project so engineers can move fast without me.”

Don’t anchor on the wrong thing (like your current title)
One candidate, hoping to reach for a promotion to staff level by changing companies, opened their Tell Me About Yourself with “I’m a senior engineer at (Company)...” That sets the ceiling before you have said anything else. Define yourself the way a staff engineer would: by the domain you own and the business outcomes you are responsible for. “For the past seven years I have been the technical leader behind the platform that (does business things) across tens of billions in annual revenue.”

Outline your thinking
Multiple candidates this week made strong decisions in their stories without making the reasoning visible. At the staff and director level, they are scoring your framework as much as the outcome. When you advocated for a phased release instead of a big-bang launch, name the tension you were navigating: first-mover credibility on one side, brand risk on a technically volatile product on the other. One sentence of explicit reasoning makes you sound like a principled leader rather than a smart engineer who happened to make the right call.

Don’t shortchange your role
One candidate described their scope as a manager by saying that once a decision is made, they implement it. Whether or not that is operationally accurate, it is not how you want to present yourself. You had opinions about the tradeoffs before the decision was made, you advocated for the outcome, you shaped it. The framing you choose to describe your work reveals the level you are operating at.

Your “Why (company)?” answer needs to map only to that company
Two candidates this week had “Why (company)?” answers that could have been submitted to three different companies. “I want to work on the hardest problems and not watch from the sidelines” sounds ok but is not memorable because anyone could say it to anyone. The best version of this answer ends with something specific to that company’s unique position. One candidate was preparing for Anthropic’s dev infra team. The strongest version of their answer was that the tools built internally there will directly shape how the rest of the industry thinks about AI-assisted development. Meta and Google cannot (currently) support that claim, but Anthropic can.

Give your story a table of contents
For any multi-part project, tell the interviewer what they are about to hear before you start. Something like: there are three parts to this — how I identified the opportunity, how I got leadership aligned, and the hardest technical problem we had to solve. That framing keeps the interviewer oriented, signals that you can synthesize complex work, and makes it easy for them to direct you to the part they care about. Stories that run linearly and trail off make it hard to know what the key moments were.

I wanted to share with you that your book really helped me for passing behavioral interviews this year, especially with CARL and the 3 big questions! Thank you for writing the wonderful book!
— SZ, newly hired at Instacart

If you want help preparing for behavioral interviews—identifying your best stories, extracting relevant details, crafting responses—then grab Mastering Behavioral Interviews and if you haven’t already, subscribe to this newsletter. It’s free!

Subscribe now

If you’re a senior+ engineer, PM, or leader preparing for behaviorals, check out more at https://thebehavioral.tech/coaching

For Anthropic specifically, develop an actual moral philosophy. “I try to do the right thing” isn’t sufficient. They’ll ask about moral dilemmas, how AI safety should work, what your guiding values are. Spend real time thinking through ethical frameworks and which ones resonate with you. Go journal by a lake :)

For OpenAI, lean into optimism. They believe AGI will transform society positively. Your “why OpenAI” should be personal and forward-looking. One candidate talked about using AI with their kid for math tutoring and wanting to bring that to the world: good as a personal anecdote, but we upleveled it by adding a broader societal context.

Lead with the headline, then give the details. When I asked one candidate what they were doing to grow their org-wide influence, they started with “I’m engaging more in Slack channels.” That’s the sub-point. The headline is: “I’m deliberately investing time in influencing long-term technical direction across the org.” Then you give the Slack example. Practice saying the takeaway first, then backing it up.

Front-load stakes in the first slide. We were preparing a slide deck for OpenAI’s Project Deep Dive, that requires slides or a document. One candidate had a project that unlocked a billion-dollar customer, but that result was buried on slide 11. We moved it to slide 1. In a real interview, you may never reach a results slide at the end. Open with what the CEO would say about your project.

Scope is felt from the challenges described. The deeper you dig the hole in your setup—how hard the problem was, how many teams were involved, how long the company had avoided it—the more impressive your story is when you get out of the hole.

Signal your level through what you emphasize. Line manager sounds like “I keep my team executing well, I stay technical, I uplevel junior engineers.” Senior manager sounds like “I understand where the business is going, I translate that into multi-year vision, and I build the people and the systems to get there.” You might have the raw material for the second story but keep defaulting to the first. Several candidates this week had that pattern.

Build durable systems, not just relationships. One candidate was handling a difficult cross-team relationship through back-channels and one-on-ones. That’s better than nothing, but the higher-level move is putting a structure in place: aligning with the partner director on how the two orgs will prioritize and resolve conflicts for the next year. Teaching the org to fish (lol) rather than personally smoothing each instance.

Great week, looking forward to next week!

• How have you used AI to increase your impact?

• How do you safely use AI in your day-to-day work?

• How are you staying on top of the latest developments in the application of AI?

I’ve long predicted the behavioral will become an ever more important round for companies to collect signal like initiative, ownership, and business sense because AI-pilled builders have such a large potential for impact. But it’s now also a place for companies to acquire explicit AI signal, including these kinds of values- or philosophy-oriented signals, since so much about the future of building is uncertain as ways of working change.

If you don’t care about Meta, jump down to the Talking about AI in a behavioral section to learn how to adapt to this trend.

I’ve also updated my AI story building and co-pilot to incorporate these new Meta signal areas and general guidance on talking about AI.

Bonus: it comes with a paperback copy of my book :)

Check out the AI Studio

Meta has changed their behavioral evaluation signal areas

Last week, Meta rolled out changes to all three engineering interview rounds, transforming them into so-called “AI-Native” versions. This includes changing their behavioral interview signal areas to explicitly account for AI workflows.

For a long time, Meta has used five signal areas to formally evaluate engineering candidates in their behaviorals:

• Driving Results

• Embracing Ambiguity

• Resolving Conflicts

• Growing Continuously

• Communicating Effectively

PM and other roles have similar but slightly different signal areas. Learn more about how I’ve recommended candidates approach Meta’s behaviorals here.

After April 16th, engineering candidates are receiving behavioral rounds with new signal areas:

• AI-Driven Impact:

  • How do you leverage AI to create measurable impact?

  • How do you execute / drive forward work to achieve results?

  • How do you safely and responsibly use AI to enhance problem solving?

• Continuous AI Learning:

  • How do you seek out and build on opportunities for growth and learning both AI and non-AI technologies and concepts?

  • How do you experiment and iterate with emerging technological capabilities and workflows?

  • Do you take constructive criticism as an opportunity to improve?

  • How have you approached improving your skills?

• Partnering:

  • How do you drive collaboration on cross-functional projects?

  • When faced with disagreements with colleagues and/or managers, how have you resolved them?

  • How have you addressed conflicts directly and approached difficult conversations?

• Embracing Ambiguity:

  • How do you operate in an ambiguous and quickly changing environment?

  • Are you comfortable making decisions and maintaining high levels of productivity when you are missing information or lack clarity?

  • How did you react when you had to quickly pivot away from a project due to a shift in priority?

• Communicating Effectively:

  • How well do you communicate with teams?

  • What about cross-functional partners?

  • How do you tailor your communications based on the work and/or the audience?

I’ve confirmed this with internal sources, but their official SWE prep guide still lists the old signal areas. I imagine that will be updated at some point.

What has actually changed at Meta?

In some ways, this is just remixing and augmenting the previous signal areas, with Driving Results being replaced by AI-Driven Impact and Growing Continuously being replaced by Continuous AI Learning. Notice how some of the old Growing Continuously signal is still being gathered in Continuous AI Learning, things like taking constructive criticism.

But there are significant changes. They’ve made AI front-and-center in these new signal areas, which makes sense as we’ve discussed already—builders leveraging AI are multiples more productive than hand-coders.

Notice the specific signal though:

• Concrete examples of how you’ve leveraged AI to increase output.

• Attention to safety concerns.

• An emphasis on the dynamic nature of AI in today’s workplace.

There are also some other subtle changes to the signal area coverage across the interview:

• Notice the downgrade of top-level conflict resolution signal into a more generic Partnering area. This is something I discussed on Luca Rossi’s podcast, as a hot take: that conflict resolution signal is too often the focus of behaviorals and that interviewers should downplay it vs. collecting ownership, ambiguity, and growth signal.

• One of the effects of this change is to make the Partnering axis more expansive, now making the collaboration and communication signal they’re acquiring more explicit.

• There’s also a more intentional ordering of the signal areas. Continuous AI Learning is close to the top now vs. where Growing Continuously was before. Obviously, AI is changing everything quickly so engineers who can’t adapt will fall behind in their fast-moving teams.

Talking about AI in a behavioral

Even if you don’t care about interviewing at Meta, you’re likely to talk about AI in your next behavioral interview. Here’s how you can adapt if you’re preparing:

Collect Stories About Leveraging AI

• Interviewers will expect you to have a strong story about how you’ve leveraged AI to build something. If you don’t have that story, go get that story.

• Beyond that, be sure to include AI-related actions in your CARL/STAR stories at each phase of the software development lifecycle—not just coding, but design, review, debugging, documentation, and rollout.

• Talk about why AI was the right choice at that phase, not just that you used it. “I used Cursor to scaffold the service because the API surface was well-defined and I wanted to spend my time on the integration edge cases” shows some kind of judgement and not just hoping the one-shot solution will be good enough.

• Don’t retrofit AI into old stories. You probably have a catalog that predates heavy AI use, and that’s fine. Continue to lean on those stories when they’re appropriate, but understand that whenever you can land a story about leveraged AI usage, do so.

Develop a “Philosophy” of AI in the Workplace

In most IC behaviorals, you won’t find what I call Values Questions, things like, “Tell me about your philosophy on performance management.” Those are typically reserved for very senior or people management loops.

However, since AI is changing so fast, your underlying beliefs have will have a big impact on your productivity in your next role, so companies will start asking more explicitly about AI “philosophy.” I use that work in the loosest sense.

• Know when to reach for AI and when to do something by hand and be able to explain your approach. Understand what current models are actually good at, where they fail, and what that means for privacy, security, and correctness in your domain.

• Narrate the decisions around AI. Interviewers will fill narrative gaps with the unfavorable assumption that you’re now a prompt-typer with no underlying judgment. Close those gaps by sharing why you picked the tool, what you verified, what you overrode, what you refused to hand off. Without this, the signal collapses into “I typed some prompts.”

• Given all the recent hype about token costs and the reality of working in a place with so much AI-generated code, have a mental model of cost and benefit—latency, token spend, review overhead, failure modes—not just “AI makes me faster.” Interviewers at serious companies are starting to probe this.

Have a Structured Learning Approach

• Think about how you learn and how you’ll keep learning. What do you read and why? What is the cadence of trying new things? How do you separate signal from hype?

• Be ready to talk about how you experiment with new technologies. What have you built recently just to learn something? How do you go about choosing what personal projects to build? How do you know when to bring something you’ve learned on personal time into your work environment?

Example behavioral questions about AI

I typically don’t advise you to prepare for behaviorals by drilling questions since the interview is about you and your career and because it’s difficult to predict what questions you’ll receive. I think we can bend that advice here, especially if you are interviewing at Meta, since we know you’re going to get AI-related questions.

Here are some example questions. Work through these the same way you'd work through any behavioral question: decode what signal is being sought, select a story from your catalog that shows it, deliver with CARL. A few of these don't have clean story matches for most candidates yet—that's expected. Use those to identify where you need to build new stories over the next few months.

AI-Driven Impact

• Tell me about a time you used AI to deliver something you couldn’t have delivered otherwise—or couldn’t have delivered as quickly.

• Describe a project where AI was central to your approach. What did you do yourself and what did you delegate to the model?

• Tell me about a time you decided not to use AI for something you could have. What was your reasoning?

• How do you measure whether AI is actually making you more productive, versus just feeling faster?

Safe and Responsible AI Use

• Tell me about a time you caught an AI mistake before it shipped. What made you look?

• Describe how you handle AI-generated code in code review—yours or someone else’s.

• Tell me about a time you had to push back on an AI-driven approach because of privacy, security, or correctness concerns.

• How do you decide what’s safe to send to an external model and what isn’t?

Continuous AI Learning and Experimentation

• How are you staying on top of developments in AI tooling for your role?

• Tell me about a tool or workflow you adopted in the last six months. What made you try it, and did it stick?

• Describe a time your AI workflow stopped working—the tool changed, the model changed, the problem changed—and how you adapted.

• What’s something about working with AI you believed a year ago that you no longer believe?

Partnering (Cross-Functional Collaboration with AI in the Mix)

• Tell me about a time you disagreed with a teammate about how to use AI on a project.

• Describe a cross-functional project where AI changed how the team worked together.

• Tell me about a time you helped a colleague who was skeptical of AI—or overly reliant on it.

Philosophy and Values

• What’s your philosophy on when to use AI versus doing something by hand?

• How do you think about the tradeoffs between speed and verification when working with AI?

• What’s the most important thing you’ve learned about working with AI?

• How do you think AI will change your role over the next two years, and what are you doing about it?

Don’t wait to add AI to your behavioral prep

If you're interviewing in the next few months, don't wait for a company to publish updated signal areas before adapting2. Update your story catalog to include how you’re leveraging AI recently, journal about your philosophy in a paragraph or two, and pick one new tool to actually try this week. That's most of the prep. The rest is making sure you talk about AI the way a builder does: as a tool you direct.

I don’t usually write about career advice on this newsletter. I write about how to rock your behavioral interviews. But so many of my behavioral coaching clients who successfully land roles at Meta turn around and book another chat with me about how to succeed once they’re there.

It’s a fair question.

I spent almost ten years at Meta as a Manager, supporting over 200 engineers. I sat through 17 multi-week calibration sessions where we decided who gets promoted and who doesn’t, who gets the bonus and who gets managed out. I onboarded dozens of new engineers into the company and watched what worked and what didn’t.

Today, I’m sharing the four things you need to know to be successful as a new engineer at Meta. The stuff I told my new reports when I onboarded them.

1. Meta is a performance-driven company

2. Meta is a metrics-driven company

3. Meta is a relationship company

4. Meta is a “show your work” company

Meta is a Performance-Driven Company

Obviously, your manager’s job is to rate your performance, but at Meta, like most big companies, the evaluation process is pretty onerous for management. And while they’ve played with it in the past few years, trying to make it lighter weight, the process still guides decision making on the ground, since doing work that’s not appreciated at performance time doesn’t make much sense.

Understanding the performance evaluation criteria your manager will use to assess you (and everyone around you) is going to help you from day one:

• Your impact: What have you done for the business?

• Your engineering excellence: How well do you execute against technical standards?

• Your leadership and direction setting: How do you guide yourself and others?

• Your impact on the people around you: Including mentoring, team health, and collaborative projects

Internalizing these matters because you need to begin with the end in mind.

Before you even start your first project, sit down with your manager and ask: “What does a successful performance review look like for me in six months?” Get specific. Get specific across all four axes.

It might surprise you, but not every manager will think like this. Sounds like it should be their job to set up their reports for success at review time, right? It is. But new managers might not actually know what these dimensions mean—or might not know what “meets expectations” at your level looks like on each axis.

If your manager is new to managing or new to Meta, they probably haven’t calibrated their ratings through enough performance review cycles. They might not realize that what felt like a “strongly exceeds” performance from a previous company only registers as “meets” in Meta’s culture. It’s a subjective process and takes a lot of reps to get right.

You can compensate for this gap by building relationships with and leveraging the experience of the people around you:

• Get to know your tech lead

• Get to know other managers in your org

Run your project plans by them. They can give you feedback on whether your plan sounds like a “meets” or “exceeds” for your level, giving you the opportunity to adjust before the cycle ends.

If you do this, then during the performance cycle, when all the managers and tech leads gather to discuss your work, there will be more than just your manager with context on your performance. You’ll have built advocates—people with some sense of ownership over your career that extends beyond your direct reporting chain.

Meta is a Metrics-Driven Company

Meta, and even many people at Meta, don’t care about your project because it’s technically interesting. Meta cares about your project because it’s moving the needle on something measurable that was agreed on in advance.

Maybe it’s DAU. Maybe it’s engagement time. Maybe it’s revenue per user. Maybe it’s infrastructure cost reduction. But it’s something that someone at the top of the org cares about—and you need to know what that something is.

So here’s what to do:

Go find your org’s and your team’s recent planning documents. Maybe it’s organized by half, or by quarter, or whatever cadence your org uses, but there’s a plan somewhere that outlined what the team was going to invest in AND how they were going to measure success.

Now, look at your personal plan. You have a plan for what you’ll invest in, right? We just talked about that, lol.

Then ask yourself: “Where does my plan fit into this larger org plan? What metric is it moving? And does someone important actually care about that metric?”

If the answer is vague—”We’re not sure yet” or “It’s kind of exploratory”—be wary.

If there’s no way to measure the impact you’re making, then the only way for you to “exceed” or “greatly exceed” expectations on that project is if it’s really technically difficult or you’re really junior and the expectation is that you can’t do it at all. That’s not a great spot to be in.

You want to work on projects with measurable outcomes. That has two benefits: first, so you can know whether you’re making progress toward the goal. And second, so you have a way to justify a better-than-meets-expectations rating when review time comes.

If your project isn’t connected to a top-line metric, it’s at risk of being a nice-to-have. And when the company needs to do headcount reductions or reprioritize—and they will—nice-to-haves get cut first. The people working on them get reassigned at best, or managed out at worst.

You want to be clearly connected to something that matters to the business. That’s how you succeed...or even survive.

Meta is a Relationship Company

Meta has a lot of products, but almost all of them are relationship products. You might have noticed that it’s a social media company. Facebook, Instagram, WhatsApp, Threads—they’re all fundamentally about human connection.

Just as its products are social, the company is social too. There are two implications of this for a new joiner:

1. You’ve got to get to know people

2. You need to understand how communication works in your org

Let’s talk about building relationships

When you arrive at Meta, one of your first jobs—arguably more important than your actual project work in the early weeks—is building social capital by getting to know as many people as possible.

I’m not talking about going to a few happy hours and making small talk. I mean actually knowing people. Understanding who they are, what they care about, what they’re working on, what success looks like for them.

First, get to know everyone on your team. This sounds obvious, but I’m mentioning it because I’ve seen new hires skip it—especially junior folks who are heads-down trying to prove themselves technically. You should know your teammates’ names, their projects, their career goals. It shouldn’t take a month for people in your team meeting to know who you are.

Second, get to know your cross-functional partners. Your PM, your designer, your data scientist. Don’t neglect them. This might sound obvious to experienced people, but juniors need to hear that XFN partners are part of your team too.

Third, get to know the senior engineers on adjacent teams. They’re the ones your manager will ping when they’re gathering data about you. They’re the ones who’ll sit next to your manager at lunch and say, “Oh, that new engineer you hired? They’re solid. I’ve seen their code reviews and they really know their stuff.”

And finally, even meet with parallel managers. I mean the managers of adjacent teams. They’re the ones sitting in the same performance review meeting, the ones your manager needs to convince to give you a positive rating. If they know you, trust you, and respect your work, that counts for something when ratings are being decided.

Now let’s talk about communication culture

There’s another relationship aspect that’s crucial at Meta: learning the cultural expectations for communication in your part of the org.

Meta uses a version of its own Facebook product, called Workplace, to coordinate on and between teams. It’s pretty wild to have so much company context—posts, comments, discussions—available in a news feed for your career.

However it looks in your specific org, there’s some overlapping hierarchy of internal groups to understand and manage. Like one group for your immediate team, one for each project you work on, one for the broader org—maybe two or more levels up—and innumerable groups to facilitate communication between orgs.

I even set up 1-on-1 Workplace groups to manage personal relationships, like between me and my direct reports.

Figure out what these groups are as fast as possible. Honestly, your manager should tell you about them, but don’t wait for them to do so. Then learn what content goes where and at what cadence.

Participate in those groups. Ask questions. Answer questions. Be a voice people recognize.

Meta is a “Show Your Work” Company

Of course, Meta is like everywhere else: your work doesn’t exist if people don’t know about it.

You could ship something incredible, move a huge metric, solve a massive problem—and if nobody sees it, it doesn’t count as much during rating season.

This is where those Workplace groups come in.

Post about your wins. Share what you shipped, what you learned, what metrics improved. People scroll Workplace. Your peers scroll it. Your manager scrolls it. Your manager’s manager scrolls it. You want to be visible. It can feel like self-promotion and I guess it is a bit, but that’s just the game.

Post about progress too, not just wins. In the right group, of course. If it feels like you’re posting too much, you’re probably posting just enough. You should be creating some kind of content there at least a couple of times per week.

All this posting has an added benefit beyond the visibility it creates. When it comes to writing your self-review—something you’ll do every six months at Meta—you’ll have a rich archive of content to draw from. The internal AI system can pull from your posts when writing a summary of your half. If you haven’t been posting, you’ll be sitting there at 11pm the night before your self-review is due, trying to remember what you did four months ago.

Don’t be that person.

The Bottom Line

Those are the four keys: performance, metrics, relationships, and visibility.

You might not love all of these. Some might feel uncomfortable or contrary to how you think things “should” work. And that’s fine. There are unpleasant realities in every job.

Honestly, these dynamics are part of the tradeoff baked into the total comp you’re receiving, which is frankly unimaginable for a regular desk job compared to 30 years ago. Maybe that’s not a solace to you but I think it should be.

Meta can be a really fun company to work for. It’s a culture that still rewards impact over tenure, and execution over politics (for the most part). You can do genuinely meaningful work there, at a scale that most companies can only dream of.

If you just landed a job at Meta, congratulations! That was the hard part. Now take these four principles, internalize them, and go crush it.

• In conjunction with Hello Interview, I’ve produced a video master class covering much of the content from the book. If you’re not a member of Hello Interview, you should be. They have the best system design content around and now they have the best behavioral content around :)

• So many people ask me for coaching, so I took all the context from the book and my coaching sessions and built a downloadable AI copilot that guides you through behavioral story selection, construction, and delivery, allowing you to customize for your specific target companies. It’s part of Premium Access on my website, which also includes a print copy of my book and any future premium content I will create!

• Speaking of that, I’ve started recording the audiobook version of the book. If you purchase Premium now, then you’ll get a print book, access to the copilot, and immediate access to the audiobook as soon as it’s ready.

Ok let’s get to the conversation I had with Gilad…

Manager roles are obviously full of more behavioral-ish actions than IC roles, with more communication, organizing, leading, more ambiguity, etc. so it makes sense that candidates for those roles would get more behavioral rounds and that they’d be scrutinized more closely.

To help you prepare for leadership interviews, I recently sat down with Gilad Naor of Management Deltas to discuss what makes people management interviews different and how to master them.

Gilad is a former Senior Engineering Manager at Meta, and formerly at Amazon, and he’s worked with hundreds of candidates preparing for their loops. His mentoring program, Management Deltas, helps ICs and managers ace their interviews and accelerate their careers.

Check out the video conversation we had, our second one from Stanford’s cactus garden:

Here’s what stood out to me from our conversation.

What Makes Manager Interviews Different

• Breadth of competencies :You’re evaluated on engineering competence, leadership, more extensively on communication, and execution management

• Unique dimensions: Executing large multi-month projects, influencing without authority, leading with authority, and growing the organization

• Philosophy over just stories: You need frameworks and guiding principles, not just examples of when you’ve done things.

Story Selection is Still 90% of the Work

• Two-pass approach: First brainstorm all stories, then filter for genuine challenge

• Ask yourself: “What specifically made this hard?” If you can’t answer, find a better story

• Best stories show you bending the curve: not inheriting a problem, but navigating nuance (e.g., a formerly great engineer struggling vs. an obvious bad hire)

• Show propagation of learnings: How did you apply lessons beyond just that situation?

The Greatest Hits

Here are some topics to prepare specifically ahead of your next manager behavioral:

• Managing low performers

• Building organizations (hiring, coaching, promoting)

• Cross-functional collaboration/conflict

• Leading large projects (execution, structure, communication)

• Your approach to one-on-ones

Handling Long Stories in Short Interviews

I’ve talked a lot in the past about how to structure long stories, so I asked Gilad about how to handle that frequent situation for managers:

• Start with a “menu of options”: Give a high-level overview, ask which part to expand

• Watch for subtle signals: “Got it” or “okay” often mean “wrap it up”

• First 10-15 minutes are for identifying the interviewer’s style

• Proactively pause: “Let me stop here—would you like me to go deeper or move to another area?”

Avoiding Pitfalls

1. The “It Depends” Problem: Interviewers may project their recent painful experiences onto your story. Defuse this by:

   • Acknowledging the risks of any approaches you took

   • Explaining what you considered and why you chose your path

   • Not just saying what you did, but what went through your head

2. The AI/Cheating Concern: Interviewers now weight follow-up questions more heavily than initial answers

   • Keep initial answers short

   • Shift content to the back-and-forth dialogue

   • This shows you can actually think, not just recite

3. Make It Real - Name people (anonymously) and places. This...

   • Builds authenticity

   • Helps your own memory for follow-ups

   • Makes the story memorable for the interviewer

4. Don’t Ramble: Pause, choose a structure like CARL (Context, Action, Results, Learnings), then speak

Looking Forward (2026 and Beyond)

• Be ready to discuss how do you bring AI into management (not just engineering).

• Organizations are flattening: how do you scale yourself as a leader?

Thanks for checking it out! More video content is coming, with the next installment all about what to do as a new joiner to Meta. I know, it’s not interview content, but people always ask me…

Recently, I sat down with Gilad Naor of Management Deltas to discuss what makes Amazon’s approach to behavioral interviews so uniquely challenging and how to master them.

If you’re preparing for an Amazon interview, you probably already know they’re different. But different how? That’s what we dug into.

Gilad is an expert on Amazon’s hiring process (he’s was an EM at Amazon and Meta), and he’s worked with hundreds of candidates preparing for their loops. His mentoring program, Management Deltas, helps engineers ace their interviews and accelerate their careers.

Here’s what stood out to me from our conversation, and what you need to know if you’re going to nail your Amazon interviews.

P.S. We took a risk and filmed this outside, on Stanford’s campus. It was beautiful, but the audio wasn’t the best :( To compensate for that, the universe sent us some coyotes, which apparently live at Stanford.

Leadership Principles Aren’t Just for Interviews, They’re the Operating System

Most companies have values, but Amazon has Leadership Principles, and they treat them differently.

At most tech companies, the stated values live on a wall somewhere. Maybe they get mentioned at an all-hands. But in the day-to-day, people aren’t actively using them to make decisions. That was certainly the case at Meta.

But not at Amazon.

Gilad explained that Amazon’s 16 Leadership Principles are the operating system for the entire company—at every level. When the CEO or any executive can’t be in the room for a decision, those principles codify the best practices the company has learned about how to make hard decisions. Technical ones, strategic ones, people decisions.

Think of it like design patterns in code. They provide a consistent language. When someone says “customer obsession” in a meeting, everyone knows what that means and why it matters.

And critically, in every behavioral interview you’ll do at Amazon, you’ll be assessed on a specific subset of these 16 principles. Each interviewer has 2-3 principles they’re evaluating. This means the leadership principles aren’t optional context for your Amazon interview.

In case the LPs are new to you, here are all 16:

• Customer Obsession: Starting with the customer and working backwards.

• Ownership: Thinking long-term and acting on behalf of the entire company.

• Invent and Simplify: Expecting and requiring innovation and simplification.

• Are Right, A Lot: Possessing strong judgment and good instincts.

• Learn and Be Curious: Constantly exploring new possibilities and improving.

• Hire and Develop the Best: Raising the performance bar with every hire.

• Insist on the Highest Standards: Relentlessly high standards for products and services.

• Think Big: Creating and communicating a bold direction.

• Bias for Action: Valuing speed and calculated risk-taking in business.

• Frugality: Accomplishing more with less.

• Earn Trust: Listening, speaking candidly, and treating others with respect.

• Dive Deep: Operating at all levels, staying connected to details.

• Have Backbone; Disagree and Commit: Challenging decisions respectfully, then committing wholly.

• Deliver Results: Focusing on key inputs and delivering quality outcomes in time.

• Strive to be Earth’s Best Employer: Creating a safer, more productive, higher-performing, and diverse work environment.

• Success and Scale Bring Broad Responsibility: Being humble, considering the secondary effects of actions, and leaving things better.

Your Stories Need to Reveal Your Decision-Making Process

When Gilad asks candidates about a time they refactored some code, they’ll jump into: “I refactored this service, it took two weeks, we reduced load by 30%.” But that’s a pretty incomplete picture of your project.

What Amazon really wants to see is: How do you think? How do you navigate the tension between moving fast and maintaining quality? Between thinking big and keeping things simple? How do you make hard decisions when there’s no obvious right answer?

So instead of just telling the story, Gilad recommends this approach:

Prepare your stories in advance. Build a story bank (you should be doing this anyway, see my book). Then, for each story, identify which leadership principles you demonstrated. More importantly, identify the tensions in that story—moments where two principles were in conflict.

For example, you had to move fast (Bias for Action), but you also wanted to maintain quality (Insist on the Highest Standards). What did you choose? How did you think about the risk? Why did you make that call?

Don’t name-drop the leadership principle. Instead, talk about the behaviors and the thinking process. “I thought about the blast radius if we made a mistake” and “I invested time in building a test harness before we refactored” tells the interviewer way more than “I demonstrated Insist on the Highest Standards.”

Think out loud the way you would in a coding interview.

The Bar Raiser Is Central to the Entire Process

Amazon has a role that other companies don’t have: the Bar Raiser.

Every Amazon interview loop includes a Bar Raiser, who is always from a different organization (not your team). Their job is to ensure that the process works for Amazon, not just for your hiring manager. They run the debrief and one of the only two people who have a vote. The other person is the hiring manager.

Gilad told me about loops where it looked like a “no hire” at the start of the debrief, but by the end, they’d decided to hire. How?

The Bar Raiser would synthesize information across all the interviews. Maybe one interviewer felt you were strong on one leadership principle and weak on another, but two other interviewers showed you were actually strong on both. The Bar Raiser connects the dots.

Or they play devil’s advocate, pushing the team to really justify their reasoning. Sometimes that clarification changes minds.

This is why every single interview matters from a behavioral perspective at Amazon, not just the ones with the hiring manager. And it’s why behavioral signal is so important—it’s one of the main things that can shift opinions in that debrief.

Data-Driven AND Good Judgment

One theme that kept coming up: Amazon is obsessed with data, but not like other companies. At junior levels, being data-driven is about gathering information before making decisions, but as you get more senior, it’s about your judgment in the absence of data.

Jeff Bezos writes about this in his shareholder letters. Some decisions can be solved with math if you have all the data. But you usually don’t have all the data. That’s where your judgment comes in.

So when you’re telling stories at Amazon, especially if you’re interviewing for a senior level:

• Talk about the metrics you tracked

• Be specific with numbers

• But also talk about decisions where you had to use judgment

• Explain why you chose to trust your judgment in a particular situation

And avoid “weasel words” like “really significant” or “moved really fast.” Amazon wants specifics. It’s both a reflection of how they communicate and what they value.

The Questions You Should Ask Your Recruiter

Before your loop, you should have a phone call with your recruiter (not email), since recruiters will be more candid on the phone and share things off the record they won’t put in writing.

What should you ask?

• Which leadership principles are you being evaluated on?

• Amazon has 16 principles. The hiring manager will typically focus on a subset that matters most for your level and role. Getting hints on which ones can help you prepare.

• What does success look like at your level?

• What’s the team/organization like?

• Are there any specific areas the team is concerned about for this role?

This information is gold because you can then make sure your stories align with what they’re actually looking for.

Top Tips for Amazon Interview Success

1. Preparation is Non-Negotiable

Especially at junior levels, don’t discount the importance of behavioral interviews. You’d be surprised how many junior candidates think the behavior interview doesn’t matter as much as the coding interview. It does. Amazon weights behavioral heavily, even for junior roles.

Build a story catalog based on hard situations you’ve navigated, not based on the questions you think you’ll get asked. Then, map those stories to leadership principles.

2. Study the Leadership Principles Deeply

Don’t just read the names. Amazon publishes a full description for each principle on their careers page. There’s also a videos of executives describing each one. Watch them.

3. Think About Tensions

Some of Amazon’s leadership principles have inherent tension. Bias for Action vs. Insist on the Highest Standards. Think Big vs. Frugality. Leaders who can navigate these tensions are the ones who succeed at Amazon.

When you’re prepping, ask yourself: In my story, where was the tension? How did I think about it? What were the tradeoffs?

4. Understand Amazon’s Writing Culture

Amazon has a strong writing culture (they use written narratives for decision-making). The way you write about your accomplishments as part of the interview process reflects how you’d communicate at Amazon.

• Avoid vague language

• Use specific numbers and percentages

• Be clear and concise

• Show your thinking, not just your results

5. Be Prepared for Variance

Amazon is distributed (see their culture of two-pizza teams, microservices, etc.), and that distributed structure applies to interviews too. There’s a lot of variance in how different interviewers run their interviews. But there are guardrails (the Bar Raiser system, standardized training). Don’t stress if one interview feels different from another—that’s normal.

Watch the Full Interview

To hear the full conversation with Gilad—including deep dives on the bar raiser process, how to prepare for level-specific expectations, and tactical tips for every stage of your Amazon interview—check out the full video.

And if you’re serious about Amazon prep, I’d also recommend checking out Management Deltas. Gilad specializes in Amazon and Meta interviews, and he works directly with candidates through his mentoring program.

Good luck with your Amazon interviews. You’ve got this.

*Questions about Amazon behavioral interviews? Drop them in the comments!

Also, check out the conversations I’ve had with some amazing tech podcasts:

• How to Nail Big Tech Behavioral Interviews as a Senior Software Engineer with Gregor Ojstersek, breaking down modern behavioral interviews and how they’ve changed with AI and shifting expectations in Big Tech.

• Austen McDonald Reflects on Mastering Behavioral Interviews with the Book Overflow guys where we talk about some of the misconceptions in this post and how subtle Big Tech story telling can really get.

I regularly talk to talented engineers who crushed their coding rounds but failed behavioral interviews. They’re confused and frustrated. “I thought I did well,” they tell me. “The conversation felt natural. The interviewer seemed engaged.”

But they still got rejected because they approached behavioral interviews with the wrong mental model. They believed common misconceptions that undermined their preparation and performance.

Here are the seven most dangerous myths about behavioral interviews and what you should believe instead.

Myth 1: No Prep Required, Just Be Yourself

This isn’t great dating advice and it’s not great interview advice either.

Yes, behavioral interviews are about you and your experiences. But understanding what interviewers actually want and crafting stories that communicate it effectively in a high-pressure setting requires preparation.

Think about it: you wouldn’t walk into a system design interview and just “be your natural problem solver.” You’d study patterns, practice articulating trade-offs, and prepare to demonstrate specific competencies. Behavioral interviews deserve the same rigor.

The reality is that even if you’ve done impressive work, you can still fail the interview if you can’t articulate it well. You might not like living in that world, thinking that good work should just be evident, but that’s not reality. You need to know which stories demonstrate the evidence interviewers are hunting for, how to frame those stories to highlight your impact, and how to deliver them concisely under pressure. And that’s going to help you not just in a behavioral but also in advocating for promotions and talking to your leadership about what you’ve accomplished.

Being authentic matters, but authenticity without preparation is just winging it.

Myth 2: Prep Specific Questions in Advance

You really don’t know what you’ll be asked.

Many candidates waste time memorizing answers to “Tell me about a time you had a conflict with a product manager” or “Describe a project that was behind.” They build a mental spreadsheet mapping specific stories to specific questions.

This approach fails because behavioral questions are incredibly varied.

Better to understand what interviewers are looking for (the underlying signal areas like ownership, scope, and communication) and know how to tell key stories from your career that demonstrate those competencies. With a few exceptions, these are not like coding interviews where questions are often repeated across companies.

A well-chosen story about driving a complex project can provide evidence for ownership, technical depth, collaboration, and handling ambiguity. You don’t need 30 prepared stories—you need 4-5 strong stories you can adapt to different questions.

Myth 3: The STAR Method Is All You Need

Search for behavioral interviews online and you’ll find countless articles about STAR (Situation, Task, Action, Result). It’s presented as the silver bullet for behavioral interview success.

STAR is useful—applying it puts you ahead of someone with no prep. A basic story structure helps you avoid rambling and provides a beginning, middle, and end.

But STAR doesn’t tell you which stories to choose, how to position yourself for a top-tier company, what scope signals “senior” versus “mid-level,” or how to adjust your approach for recruiters vs. hiring managers vs. partner interviews.

STAR is table stakes—it’s the minimum structure you need. But thinking it’s sufficient is like thinking you can ace a coding interview just by knowing how to write a for loop.

Myth 4: Behavioral Interviews Are Subjective and Arbitrary

This is the most destructive myth because it stops candidates from preparing at all.

Yes, behavioral interviews feel more subjective than coding interviews. There’s no compiler to verify your answer is correct. You can’t run test cases.

I’m not here to tell you they are objective. But FAANG+ companies have invested heavily in making behavioral evaluations as objective as possible. They train interviewers to look for specific evidence. They use structured rubrics that define what “strong” looks like at each level. They calibrate across interviewers to ensure consistency.

When a hiring team member conducts your behavioral, they’re not asking “Do I like this person?” They’re asking “What evidence have I seen that this candidate can perform at the level we’re hiring for?”

The 8 signals they’re looking for are well-defined, even if they are uniquely framed and curated by a specific company. The mistake most candidates make is not understanding what evidence demonstrates these signals.

Behavioral interviews are predictive. Companies use them because they work. Your past behavior is the best predictor of your future performance. When you fail a behavioral interview, it’s usually not because the interviewer arbitrarily didn’t like you. It’s because you didn’t provide the evidence they needed to hire you.

Myth 5: You Can Wing It If You’re a Good Storyteller

Some engineers are naturally charismatic. They’re engaging in conversation, tell vivid stories, and connect easily with people. They assume these skills transfer directly to behavioral interviews.

That’s only partially true.

Being a good storyteller in a social context is different from being effective in a behavioral interview. Your college roommate doesn’t care if your story demonstrates appropriate scope for a Staff Engineer role. Your interviewer does.

A compelling story about a technical challenge you overcame might be fascinating, but if it’s a solo project and the interviewer is evaluating collaboration, it won’t help you. An engaging narrative about navigating organizational politics might resonate personally, but if you spend 8 minutes on setup and the interviewer needed to hear three different stories in the time remaining, you’ve failed.

Natural communication skills help, but they’re not a substitute for understanding what evidence to deliver, how to choose stories strategically, and how to structure your responses for an evaluation context.

Myth 6: Recent Grads and Junior Engineers Don’t Need to Prep

This misconception costs new grads and early-career engineers more opportunities than almost anything else.

The logic goes: “I’m applying for junior roles. The bar must be lower. They just want to see I can work on a team and communicate. I should focus my prep on coding.”

Reality check: competition for junior roles is often fiercer than for senior roles. In a tough market, you’re competing against candidates with internships at top companies, strong academic projects, and candidates who prepared for their behavioral interviews.

And while the bar for scope and complexity is lower at junior levels, the behavioral interview is often weighted more heavily than you think. Why? Because companies are making a bet on your trajectory, not just your current skills. They’re asking: “Can this person grow? Do they take ownership? Do they learn from mistakes? Can they collaborate effectively?”

Your interview stories might be smaller in scope—a class project, an internship, a hackathon—but the evidence you need to demonstrate is the same. And because you have less experience to draw from, you need to be even more intentional about choosing and delivering your stories.

Myth 7: The Manager Is Just Looking for Social Fit

Yes, when a hiring team member conducts your behavioral, they want to see if you’ll mesh with the team. Chemistry matters.

But that’s not all—and it’s not even the primary thing. They’re trying to predict how you’ll perform in the role.

Social fit is actually the easier bar to clear. Most qualified candidates can have a pleasant conversation. What separates successful candidates is demonstrating the competencies required for the role: Can you own ambiguous problems? Can you influence without authority? Can you make sound technical decisions under constraints? Can you navigate complexity?

Your interviewer isn’t asking “Would I enjoy having lunch with this person?” They’re asking “Can I trust this person to deliver results on my team?”

This is why “just being yourself” and hoping for good chemistry is insufficient. You need to provide concrete evidence of your capabilities through well-chosen stories that demonstrate the signals the interviewer is evaluating.

What to Do Instead

If these myths sound familiar, you’re not alone. Most candidates believe at least a few of them. The tech industry has trained us to think this way, and quality behavioral interview prep materials are hard to find.

The framework that works:

Decode what interviewers are actually evaluating. Every behavioral question is hunting for specific evidence. Understanding what the interviewer wants changes everything.

Select your stories strategically. Choose 4-5 well-developed stories that demonstrate clear growth and impact. Make deliberate choices about which experiences to share and how to frame them.

Deliver compelling narratives. Structure your responses to set context efficiently, walk through your actions with clarity, quantify results that matter, and demonstrate genuine learning.

This is the Decode-Select-Deliver framework I teach in Mastering Behavioral Interviews. The book walks you through this entire process step-by-step, with real examples at different career levels and advanced techniques for making your stories resonate with FAANG+ interviewers.

Stop preparing for the behavioral interview you think you’re getting. Start preparing for the one you’re actually getting.

Subscribe for More

Thanks for reading! If you found this valuable, I’d love to hear from you. Reply with your thoughts, questions, or your own behavioral interview experiences.

P.S. If you’re currently interviewing or planning to soon, grab a copy of Mastering Behavioral Interviews. It includes step-by-step processes you can start using immediately—even an “I’m in a hurry” track for last-minute prep.

Come join me for How Big Tech Hears Your Story—a hands-on behavioral interview workshop next week with the folks at Formation. You’ll practice structuring stories the way Big Tech expects, avoid the “good but not great” pitfalls, and make your impact unmistakable.

Thursday, January 29th, 2026 at 4:00pm PST

Register here. It’s free :)

If you’re interviewing at Big Tech companies from outside the Silicon Valley ecosystem, one of the hardest things to do is adapt to the expected culture. The stories you tell, the words you choose, and how you show up in the room all signal whether you understand the landscape you’re entering. It’s part of the motivation for writing Mastering Behavioral Interviews.

One overlooked dimension of interview prep is how you conduct yourself—interview etiquette, or more broadly, the mindset you bring to the conversation.

I came across a recent interview between Lenny Rachitsky and Sam Lessin on this very topic. While much of it focuses on how to show up in rooms full of founders or navigate dinner with VCs (would you offer to pay for $10k worth of wine? lol), Sam’s framework for presence and mindset applies directly to behavioral interviews.

The Abundance Mindset Matters

Sam emphasizes an abundance mindset or approaching interactions not as transactional, but with genuine curiosity and confidence. Obviously this is challenging in an interview.

Your upcoming interview might truly be your one shot at a dream job(*). But if you treat it that way, then it will show. If you desperately seek validation, or treat it as an opportunity to extract value for yourself, it won’t go over well with a Big Tech interviewer.
(*) Most of the time you can come back to the well later if you’re rejected, remember that.

The abundance mindset here means approaching the interview as a conversation between two professionals. Don’t let it devolve into a performance you’re desperately trying to nail. Be confident and not worried about your prospects with this company. Be genuinely interested in the interviewer. Be genuinely interested in whether this role is right for you.

Practical Interview Etiquette

Beyond mindset, there are concrete ways to signal that you understand Silicon Valley norms, that Sam also covers:

Dress one notch above the role. If the team is casual, wear business casual. It shows you at your best.

Optics matter. Even if it feels uncomfortable, people are judging you by what your video call looks like. Improve your lighting. Keep your background clean and professional—your home office should look like a place where serious work happens.

Start with small talk. Hard when you’re nervous, I get it, but small talk is part of the dance. It’s where you establish rapport and signal confidence. Your interviewer might cut it short or lean in—be prepared either way, and don’t take the redirect personally. This is part of the abundance mindset. You’re not extracting every second of interview time for your career stories.

Keep your heart rate down. Sam’s phrase stuck with me. Keep breathing, pause before answering. If you’re speaking slowly and deliberately, you’re signaling control.

How you show up shapes which stories land. A story about scrappy hustle plays differently when you’re calm and collected versus when you’re defensive. A story about collaborating with difficult stakeholders rings true when you’re genuinely curious about the interviewer’s perspective, not performing agreement.

Silicon Valley interviewers are trained to notice whether you’re adapting authentically to their culture or parroting what you think they want to hear. The abundance mindset isn’t a trick—it’s the only frame that reads as genuine.

I write more about how to adapt your responses to Big Tech dynamics in Mastering Behavioral Interviews, including covering the six Silicon Valley myths you need to internalize to guide your storytelling.

Book Update

Thank you for continuing to support Mastering Behavioral Interviews, now available on Amazon. It’s the #1 New Release in the Job Interviewing category and continues to help candidates land roles at top tech companies. If you’ve found it valuable, please leave a review—it genuinely helps other people discover the book.

I also recently returned to Coding Chats with John Crickett where we discussed how AI is reshaping interviews, broke down common behavioral questions, and explored how to adapt stories for different organizational cultures.

More podcast episodes are coming soon, including appearances on Book Overflow and Gregor Ojstersek’s Engineering Leadership podcast.

Here’s what Nathan Troups said about the book in his review on Amazon, and he knows books!

This book is easy to read and immediately actionable. It is well written, well paced, and provides a lot of framework, tooling, and real-world examples. It delivers on its promise, and it will certainly help you master behavioral interviews in tech.

Thanks Nathan!

Performance review season is here. Whether your company does annual reviews in January or has multiple cycles throughout the year, this is the perfect time to update your Story Catalog.

You may have a job right now and aren’t actively interviewing, but do yourself a favor: take what you’ve written about your accomplishments, especially the technical details and results numbers, and save them to your Story Catalog for later use. Your future self will thank you when you’re preparing for interviews six months or two years from now.

Why Performance Review Season Is Perfect for This

When you write your self-review, you’re already doing the hard work of:

• Documenting what you shipped

• Quantifying your impact with metrics

• Identifying technical challenges you overcame

• Reflecting on your growth and learnings

This is exactly the raw material you need for behavioral interview stories. The difference is that right now, the details are fresh. You remember the numbers. You remember the technical decisions and tradeoffs. You remember who was involved and what obstacles you faced.

Two years from now? You’ll struggle to remember the numbers, how long things took. etc.

Tag Your Accomplishments with Signal Areas

As you document your stories, tag them with the eight signal areas that companies evaluate: scope, ownership, ambiguity, perseverance, conflict resolution, growth, communication, and leadership.

This makes it easy to quickly find relevant stories when an interviewer asks “Tell me about a time you navigated ambiguity” or “Describe a situation where you had to resolve conflict.”

I’ve recently been bitten by the Obsidian bug and I’m loving it for taking notes about accomplishments. Obsidian’s tagging and interconnected link system has been really effective for some of my mentees who use it to build their Story Catalogs.

BONUS: Book Overflow Podcast’s Review of Mastering Behavioral Interviews

I was stoked to see that Book Overflow, the best technical book review podcast out there, chose to review Mastering Behavioral Interviews! If you haven’t subscribed to their channel, do it. Carter and Nathan provide insightful conversations about technical books and in-depth discussions with the authors themselves.

Check out their video review here.

They do a great job covering what the book is about and how to apply it.

Some highlights from their discussion:

• The “I vs. We” problem: They dig into one of the most uncomfortable parts of interviewing: you need to say “I did this” instead of “we did this,” even if that feels unnatural. The interviewer needs to know exactly what YOU contributed.

• The eight signal areas: They appreciated having a framework that works across different companies with different values. Aligning your stories with the signal areas is a helpful station on the way to mapping them to specific company’s values.

• The CARL framework: They found the Context-Action-Result-Learning structure more intuitive than STAR, especially for breaking down larger projects into mini-CARLs with a table of contents approach.

• The Big Three questions: Tell me about yourself, your favorite project, and a conflict resolution story. Carter and Nathan emphasized that you should absolutely have these locked in before any interview.

• Silicon Valley mythos: This generated some interesting discussion about how you need to frame stories to match expectations. Nathan called it “the elaborate mating dance of some Amazonian [pun possibly unintended, lol] songbird.” They get that it can feel performative, but understanding the game is valuable even if you find it frustrating.

They also pointed out something I appreciated: yes, some of the techniques in the book are obvious communication stuff, but most people (even senior folks) leave out key details or don’t organize their stories with a clear structure. Having frameworks to lean on is especially useful when you get knocked off balance in an interview.

I’m going to be on the podcast soon for a longer conversation, so keep an eye out for that episode!

Help Me Out with an Amazon Review

If you’ve read the book, the single most helpful thing you can do right now is leave a review on Amazon. Reviews help other engineers find the book when they’re preparing for interviews, and your feedback helps me understand what’s working and what could be better in future editions.

Thanks for reading, and good luck with those performance reviews!

Here are some reflections on the lessons I took away from this year of writing, some assorted year-end observations, and…

Be sure to scroll to the end to see the top Mastering Behavioral Interview Substack posts of 2025!

Do That Thing You Know You’re Supposed to Do

In early 2024, I realized the world needed a book on behavioral interviews. We have canonical books for system design and coding interviews, but there was nothing comprehensive to help people with behavioral. I spent some time writing about it, publishing a few YouTube videos and Substack posts. It was hard—I only had a couple hundred followers.

Then a trusted friend gave me advice: stay focused on supporting the day job. Writing a book is probably too much for this stage in your life.

This advice sounded good and there were plenty of reasons to follow it. My wife’s business was growing but needed a lot of support and of course there are two children with their own needs.

But it didn’t sit well with me for the rest of the year. I was demotivated. I kept feeling a sense of regret. I had some weird coping mechanisms, like at one point I (unsuccessfully) tried to buy a ranch in the eastern Sierras, lol. In December 2024, I finally took my best-selling author wife’s advice (which you should always do, by the way, except those times when you shouldn’t—see below) and committed to writing the book.

I promised myself to finishing it this year, to work earnestly on it, and 2025 turned out to be much different.

What are you supposed to be doing? Go, do that thing.

Record Your Promises to Yourself (And Reference Them)

When I first began writing, I found it helpful to write down the following promises to myself, putting them in their own Google doc tab called Mantras:

“No matter what happens (competition, failed launch, no sales, didn’t complete the book, people don’t like it), I will enjoy the journey.

I’ll push through to publishing so I can avoid regret.

I want to help people understand their story is worth telling. That they can be successful from a behavioral perspective at a large organization.

I won’t let perfectionism stop me from publishing.”

These mantras became my north star throughout the year, especially when things got difficult or when I discovered another creator was in the midst of writing their own behavioral interview book—exactly what I had told myself wouldn’t stop me.

Don’t (Always) Listen to the Best Practices—Do What You Gotta Do to Stay Motivated

I broke the rules when I wrote the book. I did a bunch of the book publishing tasks out of order, contrary to the advice of my wife, who is a 6-time, best-selling author on Amazon.

That was risky, but I really needed a pick-me-up when writing was flagging in the Spring, so I went ahead and designed an interior layout, started building a marketing website, and hired a cover designer. I even printed a copy of the draft of the book, complete with TODOs and empty chapters.

I needed to see the trappings of a real book, feel it in my hands, to maintain motivation to keep pushing myself on the writing tasks. Was this the “right” way to write a book? Do I recommend it to you? No definitely not, and it cost me some formatting and reformatting time later.

But did it work? Absolutely. So glad I did.

Consider Subtraction to Add Something to Your Life or Energy Management is More Important Than Time Management

I’ve been thinking about and reading pieces about doing less, subtracting things from your life. It’s not often what we consider when we want to accomplish a task. Writing a book means doing…more writing right?

I couldn’t do everything this year and I had to choose: writing on Substack, writing the book, filming and releasing YouTube videos, or coaching. For the whole year I had to put off the YouTube channel. It would have really helped me market the book, but it would have taken so much time I wouldn’t have finished the book itself. I also put off coaching a number of times and slowed down writing on Substack.

Subtracting those things felt like failure at multiple points along the way, but they were necessary to focus on finishing the book.

Relationships Were the Key to Making Content Creation Scale

The only reason the book hit the best-seller list was because of the relationships and the connections I’ve built here on Substack and LinkedIn.

For all of last year, I had barely any followers (see the chart). But then connecting with and going on John Crickett’s podcast really helped me validate the need for the content. Following that, landing on the Hello Interview podcast was the first key moment of growth for the Substack. The other big jump was Yangshun Tay’s repost of my content on LinkedIn.

Going beyond simple follower counts, these relationships helped me understand that what I was creating actually mattered to people and provided much-needed encouragement during some Summer setbacks in writing.

Mix Process Goals with Outcome Goals

I’ve been trained by Big Tech to focus on outcome goals—that’s how you incentivize teams and ensure you get what’s valuable. But James Clear is yelling at everyone about process goals all the time, lol. I prefer to have both.

I had a daily writing goal which was critical to making progress on the book. But it was equally critical that the goal was actually completing the book by the end of the year.

The daily habit got me through the tough days and helped me see the progress I’ve made in my tracker, but the deadline ensured I pushed myself in November, as you can see from the number of days I wrote that month.

Assorted Year-End Reflections

Not related to writing the book, but I’ve gotten value out of other people’s end of year musings, so I wrote a few myself:

Guitar Continues to Be a Delightfully Useless Hobby

Big Tech trained me only to care about measurable outcomes, to prioritize work that scales and makes the biggest impact. My learn-guitar-as-an-adult hobby is anything but scalable or highly impactful.

In fact, it basically has no (measurable) impact and I’m still bad at it. It’s hard to stick with a hobby where I’m not naturally talented—rhythm, memorizing things, and fine motor skills are all challenging for me. I’ve seen progress over the past 5 years, since I started picking it up, but even with 4 years of weekly private lessons, I’m no where near where I thought I’d be.

Guitar has become what Joan Westenberg calls a “thick desire“—a difficult to achieve goal but one that transforms me from the inside out. I’ve always wanted to play an instrument and I want something to push my cognitive abilities in new ways, so I’ll keep at it.

2025 Favorite Book: “And There Was Light” by Jon Meacham (2022)

It’s a couple years old, but this biography explores the moral evolution of Lincoln’s views on slavery and chronicles the kind of perseverance needed to steer a country through tragedy. It gave me hope, that just as the country made it through its previous Winter Solstice, there can be hope for shorter nights to come.

Runner up: AI Engineering (something completely different!)

Taste is All the Rage…But it Won’t Save Us

So many pixels spilled recently about how important taste is as we work with AI and how it will be a safe contribution of humanity. Obviously it’s essential, but I’m not sure I see it as a moat for our fleshly value. So much of taste is just identifying and replicating trends.

In my own journey, I attempted to apply taste through AI-generated art. I got some amazing images out of ChatGPT for the book, but also some pretty crummy ones. You need more than just evaluative taste to be successful with image generation. You need a lot of patience and some prompt + art kung-fu to really get what you want.

Let’s just say that I’m grateful one of my mantras was not letting perfection prevent me from shipping.

AI Has Created Background Mental Negativity

AI has done weird things to my ownership and resolve. Yes it’s reduced friction for the “this isn’t so hard, just get it done” kind of tasks, like writing automated tests. But for every task that I come across, there’s this constant nagging and downright unpleasant thought: “I should be automating this,” followed by some sense of failure when I can’t or don’t automate it.

I’m still working through this tension.

Top Posts of 2025 from Mastering Behavioral Interviews

Thank you all for your support this year! Here are the posts that got the most views on my Substack.

It’s clear that practical, actionable advice is what people want. Look for more of that in 2026, unlike this post, lol.

1. Using the CARL Method to Structure Your Behavioral Responses

2. Conflict Stories 1 of 5: Workplace Conflicts That Make Great Interview Stories

3. Behavioral Interview Question Breakdowns

Here’s to 2026—may we all do more of those things we know we’re supposed to do.

Get the Book on Amazon

Just in the couple of days since I submitted the book to Amazon, it is already the #3 best-seller in the Job Interviewing category, right behind…you guessed it, System Design Interview and Cracking the Coding Interview.

Get the Book on Amazon

But more than just announcing the book, I want to give you something immediately useful: an updated roadmap for how to actually prepare for behavioral interviews in 2026….

Most tech candidates still approach behavioral prep the wrong way. They either wing it (”I’ll just be myself”), practice random questions they find online, or read about the STAR format and think they’re erady. None of these approaches work at the companies and for the roles that matter most.

Let me walk you through what actually works.

What’s Really Happening in a Behavioral Interview

In a behavioral interview, the interviewer is forecasting your future performance based on your past behaviors. They’re assessing specific competencies: Scope, Ownership, Ambiguity, Perseverance, Conflict Resolution, Growth, Communication, and Leadership.

Every question maps to one or more of these signal areas or a specific company value they’ve identified. “Tell me about your most impactful project” assesses Scope and Ownership. “Tell me about a time you disagreed with your manager” evaluates Conflict Resolution, Communication, and Scope.

Understanding this structure transforms how you prepare. Instead of trying to memorize answers to 100 possible questions, you build a strategic story catalog that covers all the signal areas they’re actually assessing.

What You Actually Need to Be Ready

After coaching over 200 candidates into FAANG+ roles, I’ve learned that successful preparation comes down to mastering a simple framework:

• Decode what the interviewer is really asking

• Select the right story from your experience

• Deliver it in a compelling way

To do this effectively, you need four specific components:

1. Core Stories (Your Foundation)

You need 3-4 substantial project stories that represent your strongest work. Choose them based on this criteria:

Scope: Does the project demonstrate complexity appropriate for your target level? A staff engineer needs stories about driving multi-team initiatives, not just shipping a feature.

Impact: Did it move meaningful business metrics? “Reduced latency” is nice, but “reduced checkout abandonment by 15%, recovering $2M annually” establishes a real connection to outcomes.

Your Role: Were you the primary driver, or just a participant? They’re hiring you, not your entire previous team.

For each core story, you need to extract the details that matter: the business context that explains why it mattered, your specific actions (not just “I built the feature” but the decisions you made, the alternatives you considered, how you navigated challenges), the quantifiable results, and most importantly—what you learned.

This is where most candidates struggle. They know they “led a migration” but can’t articulate the 15 specific actions they took that made it successful.

In the book, I walk through the progressive journaling technique that helps you excavate these details from your memory, even for projects from years ago.

2. Additional Stories (Your Coverage)

Your core stories might demonstrate Scope and Ownership, but what about Conflict Resolution? Growth? Communication across functions?

You need 5-7 additional stories that fill the gaps in your signal area coverage. These don’t need to be as polished or as impressive as your core stories, but you need them readily accessible when an interviewer asks about a time you:

• Navigated a difficult stakeholder relationship

• Made a mistake and learned from it

• Had to work with incomplete information

• Received hard feedback and adapted

Most candidates don’t realize they have these stories until they do the structured reflection work. That time you pushed back on a product decision? That’s a Conflict Resolution story demonstrating judgment and communication. The feature that initially failed but you learned from? That’s Growth signal that senior candidates especially need to demonstrate.

3. The Big Three Questions (Your Anchors)

Three questions appear in virtually every behavioral interview loop:

“Tell me about yourself” is your chance to control the narrative. You have two minutes to frame your career trajectory, highlight 2-3 key accomplishments, and position yourself for the role. Most candidates either give a tedious chronological history or a vague summary. Instead, you want a practiced TMAY (Tell Me About Yourself) that’s tight, relevant, and sets up the stories you want to tell.

“Tell me about your most impactful project” (or favorite project, or first project you discuss) is your opportunity to showcase your best work. This story should demonstrate multiple signal areas and match your target level’s expectations. For senior+ candidates, this means organizing it with what I call the Table of Contents technique—structuring your narrative into clear themes so the interviewer can follow your complex project without getting lost.

“Tell me about a conflict” is where many candidates stumble, especially those from non-Big-Tech backgrounds. Tech companies expect you to embrace productive conflict, address disagreements directly, and use data to drive resolution. If your conflict story involves escalating to management or avoiding the difficult conversation, that’s a red flag. The book has an entire section on how tech companies view conflict differently and how to frame your stories accordingly.

These three questions take up 15-20 minutes of most behavioral interviews. If you nail them, you’re already in strong position.

4. Practice (Your Insurance Policy)

You can have great stories and still bomb the interview if you can’t deliver them clearly under pressure. The cognitive load of real-time storytelling—selecting details, organizing coherently, adapting to follow-up questions—is significant.

I recommend a progressive practice approach:

• Solo practice first: Record yourself telling each core story. Watch for pacing, clarity of ownership, verbal fillers, and organization. Do this 3-5 times per story until it feels natural.

• AI practice second: Use LLMs to generate unpredictable questions and test your ability to quickly pair questions with the right stories from your catalog.

• Peer mocks third: Practice with friends or colleagues who can interrupt with follow-ups and provide feedback on how you’re coming across.

• Professional mocks last: Get calibration from experienced interviewers who can tell you whether your stories hit the right scope and signal for your target level.

Most candidates skip practice entirely or do one mock interview the day before. That’s not enough. The difference between “good enough” preparation and “confident” preparation is usually 6-8 hours of focused practice.

Adapting to Big Tech (The Final Layer)

If you’re targeting FAANG+, there’s one more layer: understanding how to translate your experience into Big Tech language and expectations.

Coming from a startup or traditional enterprise? Your stories might need reframing. Big Tech interviewers pattern-match against specific cultural archetypes who ownership, moves fast, embrace conflict, and frame work in terms of systemic impact.

Instead of “My manager assigned me this feature,” say “I took on this feature.” Instead of “We improved the deployment process,” say “I reduced deployment time from 2 hours to 15 minutes, saving our 20-person engineering team 40 hours monthly.” The actions are the same, but the framing demonstrates the ownership and impact-orientation that Big Tech values.

Getting Started

This roadmap gives you the structure. The book goes deep on each of these steps—complete with examples at different career levels, common pitfalls to avoid, advanced techniques like the Menu Technique and Table of Contents approach, and specific guidance for specialized interview types like leadership rounds and cross-functional interviews.

If you’ve found value in this newsletter over the past year, I have a favor to ask: grab the book and leave an honest review on Amazon. Reviews genuinely help other candidates discover this resource, and after two years of work distilling everything I know about behavioral interviews, I want this to reach everyone who needs it.

The behavioral interview determines who gets the roles that matter most. With the right preparation, you can walk into any behavioral interview—at any company, at any level—knowing exactly what they’re assessing and how to demonstrate it clearly.

After 18 months of writing, rewriting, and obsessing over every example, I’m about to finally publish Mastering Behavioral Interviews.

Next Wednesday, December 17th, you can grab it at the launch price—a special thank you to my subscribers!

Behaviorals get you the roles that really matter

The coding round might get you in the door. But the behavioral interview determines your level, your comp package, and whether you actually get the offer.

After conducting over 1,000 big tech interviews and serving as a Meta Hiring Committee Chair, I’ve coached over 200 clients, helping L6+ engineers land the FAANG role they wanted, by giving them the coaching that I put into this book.

What makes this book different?

I know you, as my loyal subscribers, would never underinvest in behavioral interview prep, but a lot of people do, which is why I wrote this book.

This isn’t a list of 50 practice questions or generic “tell me about yourself” templates.

Mastering Behavioral Interviews details the dual evaluation system interviewers use:

• The structured framework (signal areas like Ownership, Conflict Resolution, Ambiguity)

• The intuitive cultural patterns (Silicon Valley’s mythology of the “Builder” that shapes how your stories land)

You’ll learn the Decode-Select-Deliver framework that works for any question, a step-by-step preparation system starting from identifying your career stories through advanced communication techniques, and specialized guidance for leadership interviews, team matching, and breaking into Big Tech.

The book includes dozens of complete example responses—from new grads to staff engineers—showing exactly what works and why. Not theoretical advice. Real stories, calibrated to FAANG+ expectations.

What readers are saying

I had some awesome beta readers. Here’s a sample of some of the feedback I got:

“The most complete and accurate guide I have seen on the subject–for FAANG and beyond”
— Clément Genzmer, Director of Engineering, Meta

“I couldn’t recommend Mastering Behavioral Interviews more highly!”
— Stefan Mai, Founder, Hello Interview (Ex-Amazon, Ex-Meta)

“Cracking the coding interview only gets you in the room. This missing guide teaches you how to win once you’re there.”
— Mike Mroczka, author of Beyond Cracking the Coding Interview (Ex-Google)

Wednesday, December 17th is your chance to grab this at launch pricing for a limited time.

Whether you’re interviewing next week or next year, having this framework changes how you think about your own career—not just how you talk about it.

I’ll send the link Wednesday morning.

Until then, behave yourselves!

P.S. If you’ve read the drafts and found it valuable, please prepare to leave an Amazon review. That would mean the world to me! As an author, there’s nothing quite like seeing people engage with work you’ve poured yourself into.

I just released a short video answering a common question from my coaching clients: How fast should I speak in a behavioral interview?

After conducting over 1,000 Big Tech interviews and serving as a hiring committee chair at Meta, the reality is most candidates are fine—stop worrying.

In the video, I demonstrate:

• The slowest acceptable pace that won’t undermine your credibility or have people thinking you’re reading from an off-screen LLM

• The fastest acceptable pace (political commentator style) before you lose your interviewer

Watch the video on YouTube

Most candidates fall naturally within the acceptable range, but if you’ve ever wondered whether you’re speaking too quickly or too slowly, this will give you a concrete benchmark.

What do you think—does this match your experience as either a candidate or interviewer? Let me know in the comments here or on the video!

Here are some sections from the upcoming book, Mastering Behavioral Interviews, related to hypotheticals.

Book update: the complete draft is almost prepared, due 11/28 to the editor. I still expect to make the book available before the end of the year!

Choosing Responses to Hypothetical Questions

Questions like, “What would you do if a project was behind schedule,” are similar to Values Questions. The key to handling these Hypotheticals is recognizing that while you may not have faced the exact scenario, you’ve likely faced the same category of problem.

Frameworks for Hypothetical Questions

Like with Values, look to create a framework and use a pattern-matching approach to do so:

• Abstract the core challenge: Project behind schedule → resource/time/scope tension

• Scan your experience for similar tensions: Have you dealt with other deadline pressures? Resource constraints? Stakeholder disappointments?

• Extract the transferable principles: What worked? What failed? What would you do differently?

As another example, if asked “How would you handle a team member who consistently misses deadlines,” and you’ve never managed someone with that specific issue, consider:

• Have you dealt with unreliable vendors? (similar accountability challenge)

• Have you helped struggling peers? (similar performance issue)

• Have you missed deadlines yourself? (gives you empathy and insight)

To help you build a framework library, here are some building blocks organized by theme:

• Diagnostic Frameworks for “something is wrong” scenarios:

  • People vs. Process vs. Technology

  • Internal root cause vs. External factors

  • Acute crisis vs. Chronic issue

• Decision Frameworks (or “what would you choose” scenarios:

  • Impact vs. Effort

  • Reversible vs. Irreversible

  • Build vs. Buy vs. Partner

• Communication Frameworks for “how would you handle” scenarios:

  • Audience × Message × Medium

  • Diagnose → Align → Execute → Follow-up

  • Listen → Empathize → Reframe → Solve

Select and combine these building blocks based on the question. For instance, “How would you turn around a failing project?” might combine diagnostic (what’s wrong?) with decision (what to change?) with communication (how to align stakeholders?).

Choose questions carefully

Unlike the other questions we’ve considered, where you launch into a story, Hypotheticals benefit from strategic clarification. But there’s an art to this—you want to seem thoughtful, not evasive. Select 1–2 clarifying questions based on what would genuinely change your approach.

Good question selection:

• Shows you understand nuance: “Is this a B2B or B2C product?” (when asked about feature prioritization)

• Reveals critical constraints: “Do I have hiring authority?” (when asked about scaling a team)

• Identifies stakeholder dynamics: “Who are the key decision makers?” (when asked about driving consensus)

Poor question selection:

• Too basic: “What do you mean by ‘difficult’?”

• Too numerous: Asking 5+ questions before providing any value

• Too deflecting: “Well, what would you do?”

Select a relevant career story

To ground the conversation, you’ll still want to share a story from your career related to the hypothetical situation. Using the same story selection criteria we’ve discussed for “Tell me about a time...” questions.

Responding to Hypothetical Questions

Similar to Values questions, with Hypotheticals it can be difficult to know what the interviewer wants to hear or what an ideal answer might be. All you can do is showcase your problem solving, structured thinking skills, and back them up with relevant examples from your career.

If the question was, “Suppose you had a project that was behind schedule, what would you do,” here’s a structure you can employ when responding:

Clarify critical context. You’re unlikely to have all the necessary information just from the prompt. Don’t make assumptions or jump to solutions. Ask targeted questions that help you understand the constraints and stakes. Try questions like: “Is this a customer commitment or an internal deadline?” “Do I have flexibility on scope or resources?” “What’s the impact if we miss this date?” Keep this brief, like 30–60 seconds, as too many questions makes you seem indecisive or evasive. The goal is to show you understand that context shapes solutions, not to exhaustively map every detail.

Outline a framework or approach. Similar to Values questions, structure your approach around what’s important for success. Start with how you’d diagnose the situation: “I’d first need to understand why we’re behind—is it technical complexity, scope creep, or resource constraints?” Then explain your systematic approach: “Within 24 hours, I’d assess three things: the true gap between current state and target, the root cause of the delay, and what trade-offs are available.” This shows you won’t panic or make assumptions, but instead apply a repeatable methodology.

Present 2–3 likely scenarios and your responses. Rather than forcing a single answer, demonstrate nuanced thinking by bucketing probable situations. “If it’s underestimated complexity, I’d stop adding features and timebox an exploration. If it’s scope creep, I’d force a prioritization conversation with trade-offs. If it’s team velocity, I’d diagnose whether we need process improvements or additional expertise.” This approach shows you understand problems are multifaceted and solutions must match root causes.

Ground it with a real example. Ideally you have some relevant career story to share in a short CARL format.

Finish strong. End with forward momentum rather than trailing off. Share what you’d do next: “After implementing the immediate fix, I’d run a retrospective to prevent recurrence.” Mention common pitfalls: “The biggest mistake I see is throwing more people at late projects without fixing the underlying cause.” Or crystallize your approach into a principle: “I’ve learned that when projects are behind, the highest-leverage move is often to stop and change approach, not just change intensity.”

By applying these basic storytelling techniques your stories will be engaging and relevant, highlighting your repeatable actions connected to the signal areas the interviewer is assessing. There are more advanced storytelling techniques in Part 3: Refining Responses.

In the meantime, people still ask about how to answer specific questions and I can see the value—we all learn by example. gets these kinds of requests on their forums all the time so and I sat down to discuss seven behavioral interview questions using the Decode, Select, Deliver framework.

For each question, we discuss what the interviewer is looking for, what kind of stories you might select, including breakdowns by level, and then talk through key points to keep in mind when delivering that kind of response.

Enjoy!

00:00 - Intro
02:09 - “Tell me about a time you had a conflict with a coworker. How did you resolve it?”
15:49 - “Can you share an example where you resolved a significant conflict between different teams or departments in your organization?”
19:36 - “What was a situation where you didn’t agree with your manager or superior’s decision?”
27:57 - “What project are you most proud of?”
47:59 - “Tell me about a project where you failed.”
56:29 - “Give me an example of a calculated risk that you have taken where speed was critical.”
01:01:46 - “Tell me about the hardest feedback you’ve ever had to deliver.”
01:05:44 - Outro

In this piece, Andra addresses a common challenge tech leads face in interviews: how to talk about what you do when the definition of TL varies so much.

BOOK UPDATE: I haven’t posted much here on Substack since I’ve been furiously writing the book. We’re up to 281 pages and there’s light at the end of the tunnel. Still hoping to publish before end of the year!

When you interview for a Tech Lead role, the first thing to remember is that the role is not standardized. Unlike something structured like “Scrum Master,” who usually has a clear set of responsibilities, Tech Lead can mean very different things depending on the company.

Some companies see it as “the best engineer who can also coordinate a bit.” Others expect the Tech Lead to “keep the team aligned with the product.” In some cases, it is closer to “half manager, half developer.”

So how do you communicate your scope in an interview, when the expectations may be different from what you are doing today? Here are some steps that will help.

1. Start with clarity about your own responsibilities as a Tech Lead

Do not assume the interviewer knows what “Tech Lead” means at your company. When asked “Tell me about yourself” or “Describe your role,” be specific.

• What part of your time is coding?

• What part is mentoring, or running meetings?

• Are you running 1:1s?

• Where are you responsible for alignment with the product team?

This helps the interviewer see your reality and prevents mismatched assumptions.

For example: “In my current role I spend about half my time coding, a quarter on mentoring and running meetings, and a quarter on alignment with the product team.” If you are working on projects rather than a product, highlight how your responsibilities shift based on the needs of each project. This shows your flexibility.

2. Get curious about their view of the Tech Lead role

Once you have shared your scope, ask directly: “What are the responsibilities for a Tech Lead here?” This shows you are aware of the ambiguity of the role and are open to align expectations. You are not just answering questions, you are also shaping the conversation.

3. Connect your experiences to their expectations

As they explain what they mean by Tech Lead, map your own experiences onto that picture. For example:

• If they emphasize technical leadership, share how you have broken down complex problems or set technical direction.

• If they emphasize people leadership, highlight a moment you mentored someone, ran a 1:1, or mediated a conflict.

• If they emphasize cross-functional alignment, talk about working with the product team to balance priorities.

This way, you are not leaving them to guess, you are guiding them to see you in their version of the role.

4. Prepare for behavioral scenarios

Since you’re a leader, companies may turn to hypothetical scenarios more often in interviews and not just “Tell me about a time…” questions. Companies want to see how you act when things are messy, not just when you are coding.

Here is an example question I have heard managers use:
“You start a 1:1 with a team member. Five minutes in, a PO pings you about a nasty bug that needs your attention. What do you do?”

Most TLs cancel the 1:1 immediately. Their instinct is, “I can fix this bug faster than anyone.” But what message does that send? That the bug is more important than the person.

The better move: pause, delegate, and trust your team technically, while you stay present in the 1:1. That shows balance. That shows leadership.

The point is not to give the “perfect” answer, but to show how you think, what you value, and how you weigh trade-offs.

Remember: what you are doing today may not be what they expect tomorrow. Go into the interview with two goals:

• Be transparent about your current scope

• Show curiosity about theirs

Where those two overlap is where you can thrive.

You will stand out not by having the “right” definition of Tech Lead, but by showing that you know how to navigate its ambiguity with clarity, curiosity, and leadership.

Keep following for more updates on the book.

"Is it okay to repeat the same project across different behavioral questions?" This question comes up frequently in mock interview sessions. I can hear the anxiety in candidates' voices—they're worried about seeming one-dimensional or like they only have one meaningful project to discuss.

The concern is understandable. You want to showcase the breadth of your experience, and repeating the same story feels like you're limiting yourself to a single data point. But that’s probably not the thing you want to optimize for.

Spoiler alert: Focus on telling the best response for the question, even if that means using the same project, but do seek opportunities to show different projects when the quality is comparable. Beyond that, the answer is probably, “it depends.”

The Golden Rule: Choose Your Best Response

Quality trumps variety every time in behavioral interviews. An interviewer would rather hear one compelling, detailed example that perfectly demonstrates the skill they're assessing than three mediocre stories from different projects.

Always prioritize the strongest answer to the specific question being asked. If your database migration project from three years ago provides the best example of conflict resolution you've ever navigated, use it—even if you already discussed that project when answering about technical challenges.

The key is understanding what the interviewer is really looking for. Each behavioral question targets specific signal areas like communication, conflict resolution, or driving results. Your job is to provide the clearest evidence that you possess those capabilities, regardless of which story you use to demonstrate them.

When Variety Matters (And When It Doesn't)

But surely variety matters sometime right? Yes, but the importance of story variety depends on interview context:

Single behavioral interview: Repetition is less concerning. In a standard 45-minute behavioral session, you might only tell 2-3 detailed stories anyway. If your best examples happen to come from the same project, so be it.

Multiple behavioral sessions: This is where repetition becomes more tempting and potentially more of a risk, especially in senior loops that include specialized interviews. For Manager and Principal+ roles, you might face a general behavioral interview plus a dedicated project retrospective session, or a cross-functional collaboration interview, etc.

But the thing to keep in mind is that the real goal isn't demonstrating breadth of projects—it's demonstrating breadth of capabilities. A single, complex, multi-year initiative often provides rich material for showcasing diverse skills: technical problem-solving, stakeholder management, conflict resolution, and team leadership all within one project scope.

Follow-up interviews: If you’re going into a follow up interview, consider the reason for the follow up. If you think it’s because of the interviewer not collecting the proper signal, then reusing the same stories is probably fine. But if you suspect the reason is story choice or lack of signal in the stories you told, be careful. A mock interview with a skilled coach can be really helpful here. Read more about reasons for follow up behaviorals.

Strategies for Smart Story Reuse & Mitigation

Even though reusing stories is fine in many circumstances, here are some tips to minimize the potential downsides.

The Menu Technique

When you have multiple relevant examples for a question and the most relevant one is a previously discussed story, present them as options to the interviewer, calling out the repetition, instead of just barreling ahead with the reused one:

Tell me a story about how you resolved a conflict.

I could tell you about two different approaches I've taken to conflict resolution. One involved a disagreement with another engineering team about technical architecture—which I discussed before—and another was about resource allocation with my manager, but might not fit the question as well. Which would be more useful for you to hear?

This approach demonstrates that you have multiple examples while focusing the conversation on what's most valuable to the interviewer.

Read more about the Menu Technique.

The Halo Effect

In cases where you’re pretty sure it’s better to reuse a previous story, but there are some perhaps less-related stories that have traces of relevant signal, you can use lists to engage the Halo Effect and help dispel the perception that you have limited experience:

Tell me a story about how you resolved a conflict.

I’ve resolved conflicts across multiple roles, and with multiple stakeholders, including other eng partners and PMs, but I think the best example is one I mentioned in another interview. Let me tell you how I resolved a technical architecture dispute with another engineering team…

Read more about the Halo Effect.

Red Flags to Avoid

Don't apologize for reusing a story. Saying "I know I mentioned this project before, but..." signals insecurity and draws unnecessary attention to the repetition.

Don't use identical details every time you reference the same project. Adapt your focus and emphasis based on what each specific question is trying to assess. The same database migration might emphasize technical complexity for one question and stakeholder management for another.

Don't stick to one project if you genuinely have other strong examples. Breadth does help.

Conclusion

Reframe the question from "Am I repeating myself?" to "Am I giving the strongest possible answer?" Your goal is to convince interviewers that you can repeat your successes in their organization—and that requires showcasing your most compelling examples of the behaviors they value.

The right interviewer will appreciate depth and substance over artificial variety. They'd rather hire someone who can point to one transformative project where they demonstrated exceptional leadership, technical judgment, and business impact than someone who dabbled in many areas without leaving a meaningful mark.

Focus on your best stories. Tell them well. Let the quality of your examples speak to the quality of your work.

What do you think? When is it ok to reuse stories across the same behavioral interview? What about across multiple interviews?