Elevating Your Past Projects
Behavioral interviews require you to reflect on your past projects and experiences. In this lesson, we’ll teach you how to build structured, reusable responses for any behavioral interview question, by turning vague project details into meaningful, impactful answers.
In a nutshell, our five-step approach focuses on this theme:
- Don’t prepare for specific questions.
- Prepare the details of your work.
- And then mold them to specific questions.
Step 1: Select the right projects
Pick three business-focused and three people-focused projects, and add them to your own behavioral cheat sheet—this set is the foundation for the rest of your prep. Don’t overthink it! Don’t worry if your projects don’t seem impressive at face value. They will be elevated by the end of this!
Select your own three business-focused projects and fill out their names in your own behavioral cheat sheet:
Select your own three people-focused projects and fill out their names in your own behavioral cheat sheet:
Step 2: Brainstorm the facts
For each of your six projects, fill out a corresponding chart with BLUF and CARL (Context, Action, Result, and Lesson) (outlined below). This approach gives you the raw data that you can later craft into solid, structured answers.
Look for domain-specific complexity—such as model convergence issues, pipeline dependency failures, schema breakages, or handling millions of API calls per day. These often translate into excellent narratives about the challenges you faced, which we’ll use later.
Recommendation for best results: Read through our framework and examples first, and then fill out your own charts.
Our framework versus STAR
Our approach challenges the popular STAR format—and here’s why.
The STAR format (“Situation, Task, Action, Result”) is the standard advice. Like Steve Huynh, Principal Engineer at Amazon, we believe there are better alternatives:
- The most common follow-up question in behavioral rounds is some version of: “Given the chance, what would you do differently?” STAR has no built-in mechanism for this highly-likely scenario. Failing this scenario is a big red flag.
- Focusing on the “Situation” and “Task” is overly-complex, and seems to lead to long-winded answers, with too little focus on individual contribution.
Instead, we recommend to:
- State the most important details in a 1–2 line summary, first.
- Add structure that leaves space for lessons learned.
BLUF
The BLUF (“Bottom Line Up Front”) approach is to open with one sentence that summarizes the project and its impact. For example:
“On this project, I refactored our inference service to cut latency by 60%, improving response time for millions of users.”
This grabs the interviewer’s attention, shows off senior-level clarity, and sets the stage for the rest of your story.
Did you know? BLUF is a framework popularized by the U.S. military to make messages more concise and powerful. While the basic idea is counter to common structures (where the conclusion comes at the end), BLUF places the most important information at the beginning, delivered in one or two lines, to ensure the message’s core idea is understood right away.
Context (the “C” in “CARL”)
The “Context” is often the 20% of your answer which is not focused on your individual contribution. It’s common to include:
- Why the project mattered to the business
- Who was involved—teams, roles, and key dependencies
- Business context—Enough for an outsider to understand, ideally through user journeys.
A strong opener is often: “The problem we were trying to solve was…”
For technical roles, add details like load expectations, latency constraints, or data sources. A line such as, “The system had to support 500K queries/min under 100ms latency,” makes the problem more tangible.
Action (the “A” in “CARL”)
This is where you highlight the key actions of your individual contribution. Highlight the greatest challenge, tradeoffs, or conflicts you navigated.
- For business-focused questions, concentrate on the greatest challenge you encountered (what made it hard, what tradeoffs you considered), and why your solution was the best choice.
- For people-focused questions, highlight your conflict resolution skills and ability to understand other people’s perspectives. Aim to teach your interviewer something about effective collaboration.
Result (the “R” in “CARL”)
The end result, or the business outcome for this project. It may overlap with your BLUF, and that’s okay. Good stories often have a circular structure, ending close to where they began.
Lesson (the “L” in “CARL”)
This proactively answers the anticipated question: “Given the chance, what would you do differently?”
Highlight what you learned, especially for technical lessons (such as a modeling failure due to data leakage, or an outage due to lack of observability), and show what you changed (for example, added a validation layer, or implemented canary testing).
It doesn’t need to be centered around a mistake; it can also be a piece of key information or skill you learned.
Chart out your talking points
These charts are not scripts you need to be attached to. These are talking points that you can refine over time. The purpose of filling out these charts is to get to know the details of your six projects.
Fill out your talking points for your three business-focused projects in your own behavioral cheat sheet:
Do the same for your three people-focused projects: fill out talking points in your own behavioral cheat sheet:
Step 3: Talk it out, intentionally practice not being too scripted
Practice your answers aloud—with our AI interviewer—in the mirror, or in a voice memos app. Optimize for lean, yet dense answers that convey the core project message without sticking too close to the script.
How to practice
- Practice delivering the core message of each of your six projects multiple times.
- Tailor your three business-focused projects to a few different business-focused questions. Do the same for your people-focused projects.
- Allow for slight variations to apply to the specific question you’re answering. For example, if it’s a question about a project you’re proud of, emphasize your passion.
Step 4: Challenge yourself with follow-ups
Experienced engineers know that the initial answer to a question is usually not the true test. Usually, it’s the follow-up questions that reveal the true challenge. You can either challenge yourself as a part of your prep to build resilience, or you can feel the full pressure in the interview.
Never use structured, predefined frameworks (STAR, CARL) for follow-up questions. Simply answer the question as if someone is slacking it to you. Keep it lean, clear, and focused on exactly what was asked.
To successfully challenge yourself, write or speak aloud answers to the below questions for each of your six projects you charted out.
The most common follow-up questions, when and why they’re asked
-
Question: “Tell me more about that technology.”
Use case: Asked for any technology you mention.
What the interviewer wants to see: Are you a keyword stuffer with no real depth, or do you know the limits of your knowledge?
-
Question: “Tell me more about how that worked.”
Use case: Asked for any component in a system you mention.
What the interviewer wants to see: Did you limit your knowledge to the bare minimum you had to know, or did your learning go above and beyond?
-
Question: “Why did you choose X technology over Y technology?”
Use case: Asked for any technology you mentioned implementing.
What the interviewer wants to see: How you discuss tradeoffs and justify your choices with clarity.
Other example follow-up questions, and why they’re asked
-
Question: “What limitations or risks came with the approach you ultimately chose—and how did you mitigate them?”
What the interviewer wants to see: Nuance around risk awareness and proactive design thinking.
-
Question: “Did you run any profiling, testing, or analysis to validate your design or implementation? What did you learn from it?”
What the interviewer wants to see: Are you showcasing technical diligence, or just intuition-based design?
-
Question: “When choosing technologies or tools, did you consider how their capabilities or limitations might evolve over time? How did that influence your decision?”
What the interviewer wants to see: Self-reflection on long-term vision, ecosystem trends, and technical foresight.
Step 5: Get feedback
The most common question engineers ask is: “How do I know when I’m ready?”
Whether the next step is a mock interview or a final round with your top choice, don’t let self-doubt cloud your judgment.
Use this shortcut:
“Have I practiced for the next step five times?”
If “yes,” you’ve likely doubled your chances of success, and you’re as ready as you’ll ever be.
For example, if your next step is a Google tech screen, you’re ready after five realistic practice runs of that format. (The more exact your practice can match the format, the better.)
Take it one step further with feedback: You’ll grow faster with input from others. Get feedback from:
An alternative: give yourself feedback
Play it back—audio or video. Listen as if you were someone outside your circle. You’ll quickly figure out what’s not clear or needs more explanation. For example, if your story included a model change, an architecture swap, or a performance gain, ask yourself:
Was it explained clearly enough for a smart outsider to understand why it mattered?
Wrap up
Knowing your projects (inside and out) is your secret weapon. Practice until you’re sharp, confident, and clear—so you’re ready for any curveball a real interviewer might throw your way.