Course

The Big Three Questions

Special preparation for the three most important behavioral questions: Tell Me About Yourself, Tell Me About Your Favorite Project, and Tell Me About a Conflict.

When I was doing behavioral interviews at Meta, I was making hiring

Why the First 15 Minutes Matter in Behavioral Interviews

0:00

15:59

Video Content

While drilling random behavioral questions isn't the best preparation strategy, three questions (or variants) appear so consistently, and carry so much weight, that preparing them thoroughly pays off every time:

Tell me about yourself (TMAY)
Tell me about your favorite project
Tell me about a time you resolved a conflict

Since you know they're coming, you have an opportunity to prepare polished, practiced responses you can deliver confidently even when you're nervous. Nailing these will give you confidence through the rest of the interview and gives you a huge boost in terms of the subjective assessment from your interviewer. These questions also give you a chance to cover a wide variety of signal areas, establishing yourself as a good fit for the role.

Let's cover some special guidance for each of these questions.

Tell Me About Yourself (TMAY)

This question pops up everywhere. It starts in casual networking conversations, with recruiters, hiring managers, and of course in behavioral interviewers. It's so ubiquitous it has its own acronym: TMAY (pronounced "tee-may").

Answering TMAY effectively can set the tone for the entire session and accomplish a few things:

Break the ice and leave a great first impression. Candidates and interviewers alike are nervous at the beginning of an interview. Take these first few minutes to make a lasting impression when the interviewer is most attentive.

Set the context and your scope. Many interviewers have not reviewed your resume. They might be coming straight from another meeting and not even have looked to see which open role they're interviewing to fill. Your TMAY introduces the conversation and helps both of you get oriented.

Steer the rest of the conversation. A strong TMAY lets you guide the interviewer toward topics that showcase the best of your career. This ensures the rest of the interview focuses on your repeatable behaviors, which is how the interviewer will judge you.

Express passion for your role and for the company. This is your opportunity to demonstrate genuine enthusiasm for the work you do and the role you're pursuing.

Paradoxically, the way to achieve all of this is to keep your TMAY short. About 30 seconds to 2 minutes is ideal. Interviewers want enough context to orient themselves but are also eager to dive into their more meaty questions.

Don't use flattery like "It's been my life's dream to interview for this company." Your job is to guide the interviewer to the best stories about your career, so time you spent in the introduction means less time spent delivering signal that will get you hired.

A Simple Structure for TMAY

To accomplish all this, we recommend a simple structure that covers three parts: a personal summary, a few accomplishments, and a forward-looking statement.

TMAY Structure

Personal Summary

Start with a couple of sentences introducing yourself. Think of it as a condensed LinkedIn About section. Mention your role (e.g., backend engineer, full-stack developer), years of experience and title, and a unique trait or focus that sets you apart.

I'm a Senior Engineer, focused on backend with five years of experience building scalable systems and solving tough performance challenges. I'm passionate about crafting solutions that are not only efficient but also highly maintainable without documentation.

Tailor this summary to the job. If the role is for a frontend engineer, don't introduce yourself as a backend specialist.

Accomplishments

In the middle, highlight key achievements, similar to how you would on a resume. Choose two to three accomplishments, ideally recent ones, that:

Showcase core skills and business impact. Remember, the manager is hiring you to accomplish something in the real world (revenue, retention, performance, etc.) so prove to them that you care about outcomes.
Align with the role you're applying for. Choose accomplishments that demonstrate skills relevant to what they need.
Can be expanded upon in later questions. Ideally you're mentioning whatever you'll cover in your "Favorite Project" response, creating a natural hook for deeper discussion.

Each accomplishment should be concise, typically one sentence, with a dabble of technical detail and business impact:

At TechNova, I led a project to optimize our Redis-based caching strategy, which reduced page load times by 40% and improved customer retention.

This isn't the time to dive into full STAR/CARL stories. Keep it high level and intriguing. Your goal is to pique interest, not exhaust it.

Forward-Looking Statement

Ideal TMAY responses help the interviewer see the thread between your past work and the role they are hiring. If they get the impression that this is both the ideal next step for you and the right background for them, you're off to a solid start.

End with a sentence or two connecting your past to the role you're pursuing and what you're hoping for in the future. This wraps up your TMAY and hands the conversation back to the interviewer, avoiding an awkward stop.

I'm excited to bring my experience in distributed systems to a team tackling large-scale challenges and I'm looking to become a TL because I really enjoy the mentoring and technical vision parts of my job.

TMAY Examples by Career Level

Let's review some complete TMAYs for candidates at different points in their career. Notice how the scope and framing shift as seniority increases.

New Grad

As a new grad, prioritize work experience, even if it was short, over personal projects and school projects. Since you'll likely need to draw from some of those and they may not have real-world impacts, highlight key features as the "business impact" part of the accomplishment.

I recently graduated from State U with a degree in Computer Science, and I'm passionate about solving challenging problems with code. My focus has been on backend development, particularly designing APIs and working with cloud infrastructure.

When I interned at RetailRise, I worked on optimizing database queries, reducing query times. And during my final year, I built a project management tool for remote teams as part of a capstone project, using Python and Flask. This tool included real-time collaboration features and a custom notification system.

I'm excited to bring my learning and enthusiasm to Bloom, given its need for large, scalable systems.

Mid-Level Engineer

I'm a software engineer with four years of experience, specializing in frontend development and creating intuitive user interfaces. I'm really passionate about making experiences users love.

At Acme Co, I led the implementation of a design system that reduced UI development time by 30% and ensured consistency across the product. Before that, I worked on a customer feedback platform where I integrated a machine-learning model into the frontend to provide real-time insights.

For my next role I've been looking for a space in healthcare where I can solve tough problems with a user-centric lens and Synertech seemed like a perfect fit.

Notice the personal summary establishes who they are and what they care about. The accomplishments are specific with quantified impact. And the forward-looking statement connects their experience to this specific opportunity.

Senior Engineer

I'm a senior software engineer with over 10 years of experience building distributed systems and scaling complex applications. My expertise lies in designing architectures that work across a large array of teams and use cases.

At Flux, I spearheaded the migration of our monolithic application to a microservices architecture, reducing downtime by 50% and improving team productivity. Previously, I built a real-time analytics platform handling millions of daily transactions, using a combination of Kafka and Elasticsearch. I also enjoy mentoring junior engineers, helping them grow into confident contributors.

To continue using and grow my experience with large scale systems is the goal with my next role. I enjoyed chatting with the engineer I met at the conference last week, so excited to be here.

The scope increases with seniority. This candidate talks about architectures that span teams, migrations that affected the whole organization, and mentoring. These are signals of leadership beyond individual contribution.

People Manager

I'm an engineering manager with 12 years of experience leading high-performing teams across multiple organizations. I really love building engineering cultures and helping people grow.

At RideLink, I led a team of 20 engineers to deliver a mission-critical platform that enabled a 40% increase in customer onboarding speed. I also introduced a biannual hackathon that resulted in several ideas being turned into production features. Across my career, I've worked on scaling teams from five to 50 while maintaining a strong engineering culture.

In my conversations so far with folks at Bloom, I've been intrigued by the products and the connections you've built between the teams and your customers. Sounds like an interesting place for me to make an impact.

Note how the more senior candidates make stronger statements about how they can add value and are less deferential in their forward-looking statements. Late career engineers are expected to have a good idea of what they do best and know the value they bring.

Handling Complex Situations in TMAY

If your career history includes layoffs, gaps, or short stints, address these proactively and concisely in your TMAY. Set the narrative yourself to avoid misinterpretation. Brief, honest, forward-looking. Then move on.

For a gap in your career, we're trying to address the concern that your skills have atrophied:

After Sparkly shut down, I took six months to upskill in cloud architecture and completed a certification program. I'm excited about using that in [Company].

For a layoff, the primary concern the interviewer will have is that you might be at risk of poor performance, so convince them that's not the case:

Due to the changing economics with their real estate customers, HousingTech was under some financial pressure, ultimately deciding to cut the entire Growth team.

For short stints, the concern may be that you don't commit to work long-term or that you don't know what you want out of your career:

I've worked across a number of early stage startups, which really accelerated my growth as an engineer but ultimately none of them has panned out from a product-market fit perspective.

Don't say negative things about your previous employer. When describing the motivation for something new, be positive about what you're headed toward, not negative in describing what you're leaving behind.

TMAY Mistakes to Avoid

History Lesson

I started as a frontend engineer at Company X, then moved to Company Y, and now I'm at Company Z...

Avoid giving a chronological walkthrough of every job you've had. This History Lesson approach is tedious and it also makes your older experience seem equally important as your most recent experience, which is almost certainly not the case. Focus instead on the highlights from those jobs and the impact you want the listener to walk away with.

The Childhood Origin Story

I've been interested in computing since I was 6, when I worked on my first Scratch program in school...

While the interviewer is interested in unique aspects of you, make sure you share aspects relevant to the job. The interviewer doesn't need your biography. Start with who you are professionally now. The caveat here is if they ask you explicitly about how you got into engineering, then do share these kinds of origin stories.

Less is Not More

I'm a senior software engineer at Momentum, with 10 years' experience. [full stop]

Some candidates omit accomplishments of any kind, thinking they shouldn't repeat what's on their resume. Bad idea. Many interviewers haven't read your resume or at best they've skimmed it. Use your TMAY to guide them toward the stories that matter, taking care not to produce a History Lesson.

Being Negative About Your Former Employer

I'm looking for some place I can grow more technically. My current company has really poor engineering, with the codebase kind of a mess. My manager isn't interested in addressing the technical debt at all. The product roadmap changes every week, so we're constantly context-switching and never actually shipping anything meaningful. Plus, there's no real career growth path. I've been stuck at the same level for two years.

This response makes the listener wonder if you are the problem, and certainly exposes your lack of leadership ability to drive technical and cultural change in your current role.

Compare this to a positive framing of the same underlying motivation:

As I've grown technically, I've become increasingly interested in working on developer tools and infrastructure that can impact how entire engineering teams work. That's what draws me to this role: the opportunity to build in a culture that knows how to ship and is known for technical excellence.

Tell Me About Your Favorite Project

Early in the interview, often right after TMAY, you'll be given the opportunity to tell the story of one of your core projects. It might come in the form of an explicit question like "Tell me about your favorite project" or "Tell me about your most impactful project." Or it might be a question like "Tell me about a time when you solved an ambiguous problem."

Any of these give you the opportunity to choose one of your core stories to tell first, to create a strong impression of your impact, and to set the stage for the rest of the interview.

This question is a big deal. Interviewers are seeking to understand the scope you've operated at and how you go about accomplishing something end to end. In other words, they want a detailed description of your daily work over a long period of time. If a company is hiring you to deliver business results using some skillset, then because of the nature of this question, the answer alone is often enough to predict the interview's outcome most of the time. The remaining signal to acquire is cultural in nature (conflict resolution, growth, etc.) and not simply "can you deliver on the core parts of the job."

It doesn't matter how this question is phrased: "favorite project" or "most impactful project" or whatever. Respond with the same story. The interviewer is not actually interested in your affinity for the project, as in "What is your favorite movie," but rather in hearing what presents the most complete picture of your career.

Choosing Your Favorite Project

When selecting your favorite project, optimize for three key dimensions:

Impact: Choose work that moved meaningful business metrics. This could be revenue growth, user engagement improvements, system performance gains, or cost savings. Anything that demonstrably made the organization better. Quantifiable results with specific numbers are ideal, but qualitative improvements that clearly benefited users or the business also work.

Scope: Look for projects with substantial breadth or duration that gave you opportunities to demonstrate multiple signal areas. Complex projects spanning weeks or months, involving cross-functional collaboration, or requiring technical and non-technical problem-solving provide richer material for showcasing your full range of capabilities. Also ensure the project relates to your target role in its primary focus.

Personal Contribution: You need to have been a primary driver, not just a participant. The interviewer wants to understand what you specifically did to achieve the results. Being part of a high-impact team isn't enough; you need clear ownership of significant actions and decisions that influenced the outcome.

Choosing Your Favorite Project

The sweet spot is finding a project where all three intersect: substantial business results that you personally drove through complex, multi-faceted work. If you can't find a project that scores highly on all three dimensions, prioritize personal contribution over the others. A smaller project where you led everything is better than a massive initiative where your role was peripheral.

Since you're talking about a project of meaningful size, you'll find it helpful to structure your response not simply as a single CARL but by organizing it into themes, or groups of Actions, then signposting those themes throughout your response. Use the Table of Contents technique from the Deliver article.

As one of your core stories, be sure to prepare common follow-up questions. The interviewer will probably park on this story for a while since they're assuming it's the best one you have.

Questions that always come up:

"Were there any conflicts you encountered?"
"What was the hardest part?"
"What would you do differently?"

Have these ready. Don't let a follow-up catch you off guard on your flagship story.

Tell Me About a Time You Resolved a Conflict

Understanding the types of conflicts you've navigated and how you resolved them is a key indicator of seniority and helps interviewers understand whether you fit within the "conflict-makes-us-better" philosophy of modern tech companies.

If there's a red flag on "Tell me about a time when you had a conflict," you are very likely not to get hired. Many companies are loathe to hire jerks, no matter how brilliant they are. Remember that most hiring processes are tuned based on bad hires the company has made in the past, it needs to be completely clear that you're not like that guy who railroaded his previous team so much that nobody wanted to work with him.

How Tech Companies View Conflicts

"I don't have conflicts with coworkers" is a frequent response from either junior candidates or those not familiar with how tech companies work. This is a red flag, because it doesn't fit with modern perceptions of workplace dynamics in Silicon Valley-style companies.

Conflict isn't something to be avoided and it doesn't have to be emotional in nature. It's a sign of being involved in meaningful work with other smart coworkers. When multiple talented people care deeply about outcomes, disagreement is natural and healthy.

If "I never have conflicts" is your first response to this question, don't fear. You've probably been involved in a number of situations that would qualify and we'll help you find some. We've got some examples to jog your memory down below.

Here are some best practices companies look for related to conflict resolution:

Be assertive: You disregard power structures when the greater good is at stake. If you think you're right, you speak up.

Go directly to the source: You do not triangulate around conflicts or hide behind management (at least not prematurely).

Remain emotionally in control: Even in the face of others' anger, you stay calm and professional, venturing to care about the people involved even if there's disagreement.

Stay focused on outcomes: You prioritize the organization/product/user, and not personal gain.

Make data-driven, rational decisions: You believe in the meritocracy of ideas and use fact-based persuasion to advocate for your position. Data and logic are sufficient to change your mind.

Common Conflict Stories

Candidates often think they don't have a conflict story, that the interviewer is asking for an emotional drama, or when a coworker was being overtly combative with them. But that's not the case. Workplaces are filled with the kinds of conflicts that make great stories:

Technical disagreements:

My teammate wanted to use a NoSQL database for our user management system, but I pushed for PostgreSQL due to our need for ACID transactions.

Prioritization conflicts:

Product wanted three new features in the sprint, but I advocated for spending half the time on technical debt that was causing daily on-call issues.

Timeline pushback:

Leadership wanted to ship the feature immediately, but I insisted on adding input validation after showing them potential security vulnerabilities.

Resource allocation:

The infrastructure team couldn't provision our new services until Q2, so I worked with them to identify a temporary solution using existing capacity.

Process changes:

I wanted to introduce TypeScript to reduce our production bugs, but senior engineers were concerned about the migration overhead.

For these, stakeholders could be managers, product managers, designers, senior engineers, customers, etc.

Choosing the Right Conflict Story

When picking a conflict story, pick ones where:

The stakes were high: The scope of your conflicts is a reliable indicator of your level. Conflicts over formatting a codebase or which features to include in a release are low stakes versus conflicts over long-lived system design or team charters.

You were deeply involved: Being a central player in a conflict is the only way for a listener to evaluate your conflict resolution skills. Make sure you did something to bring about a resolution.

You ended up being right: It is less risky to tell a story where you were right, at least partially. Humility is valuable but not the signal the interviewer seeks, and you risk looking like someone who makes poor judgments.

Of course, some companies will explicitly ask you about times when you were wrong, to assess humility and growth. In those cases, of course you should pick a relevant story, but be careful about how you frame that you were wrong. Preferably, choose a story where you were not obviously wrong in advance—where your initial position was reasonable given the information available at the time. This way, you demonstrate humility and a growth mindset without looking like someone with poor judgment.

Common Elements of Successful Conflict Stories

As a way to help you remember Actions you took during the conflict resolution process, here are elements of successful conflict resolution stories:

Be proactive in raising concerns. If you are headed toward a conflict, be the one who directly confronts it with your coworkers. If you don't bring it up, then at least be receptive when it's brought to your attention.

Only start constructive conflicts. No one likes a cantankerous coworker. What you care about reflects on your maturity and fitness for a role.

Seek to understand before being understood. Often more information is needed before jumping into a conflict. Perhaps you seek it from the main party or collect corroborating evidence from others.

Choose the right communication channels. You move from one communication channel to another based on the state of the conflict. Comments on a PR or shared document are rarely effective conflict resolution mediums. Sometimes casual conversations are best.

Demonstrate empathy. Expressing an understanding and an affinity for the other party's position greases next steps and compromises.

Demonstrate maturity. Even in the face of emotional circumstances, you maintain your composure and act in a professional and laudable way.

Use data to make decisions. Where data or proof-of-concepts are possible, you collect or build them.

Involve the right coworkers at the right time. If other people are needed, you pull them in when needed, not before to create drama and not after when the project has suffered a stall.

Don't take too long. Invest time and energy relative to the business value of the conflict, perhaps timeboxing any data collection or deliberation steps.

Come to a clear resolution. Even if the result is not what you desired, there is clarity and a clear path forward for all participants.

Preserve relationships. Coworkers still want to work with you after the conflict is resolved, even if they didn't get their preferred outcome.

If your story involves a number of these actions, it's probably a good story to tell.

Full Example: Data Quality vs. Timeline

Our fintech startup was under intense pressure to launch a fraud detection model before our Series B funding round. The CEO had promised investors we'd have ML-powered fraud prevention live by month-end, and the product team had already committed this timeline to our biggest enterprise prospect. We'd been working with a dataset of transaction labels that were created by our customer service team over the past year, but I'd noticed significant inconsistencies when I started model development. About 30% of the labels seemed questionable: transactions marked as fraudulent that looked legitimate to me, and vice versa.

When I raised this concern, the product manager was visibly frustrated. She told me we "couldn't afford to be perfectionists" and that we needed to ship with what we had. The sales team was breathing down her neck because this prospect represented 40% of our projected revenue for the quarter.

I understood the business pressure, but I also knew that shipping a model with poor precision would be catastrophic. False positives would block legitimate customer transactions, potentially losing us existing users and damaging our reputation with the enterprise prospect we were trying to win.

First, I ran a quick analysis to quantify the impact. I trained a baseline model on the existing data and found it had a 23% false positive rate on our validation set. I calculated that this would block roughly $2M in legitimate transactions monthly for our current customer base.

I scheduled a meeting with the product manager and presented this data, but she remained firm on the timeline. She said the business risk of delaying was greater than the technical risk of shipping an imperfect model. At this point, I could see she was stressed and feeling caught between competing pressures from leadership.

I then proposed a compromise: give me two weeks to clean the most critical mislabeled examples while the engineering team built the model serving infrastructure. I offered to work with our customer service team to review a sample of transactions during business hours and create a more reliable training set. I also suggested we could launch with more conservative thresholds initially to reduce false positives, even if it meant catching fewer fraud cases at first.

When she still seemed hesitant, I brought in our head of customer success, who confirmed that transaction blocking issues were already our second-highest support ticket category. This helped illustrate that launching with high false positives would create immediate operational problems beyond just user experience issues.

After some back-and-forth, we agreed on a modified timeline: I'd spend 10 days on data cleaning while working closely with the customer service team to establish a labeling process, and we'd launch with conservative settings that we could tune more aggressively once we had cleaner training data.

The extra time investment paid off significantly. After cleaning the data and retraining, our false positive rate dropped to 8%, and we actually caught 15% more fraudulent transactions than the original model. We launched one week later than originally planned, but the product manager was able to present much stronger metrics to both our investors and the enterprise prospect. The enterprise deal closed two weeks after launch, partly because our fraud detection numbers were substantially better than what they were seeing from competitors.

This experience taught me the importance of quantifying technical risks in business terms that stakeholders can understand. Rather than just saying "the data quality is poor," showing the direct impact on revenue and customer experience made the case much stronger. I also learned that proposing solutions alongside problems is crucial. If I had just pushed back without offering the compromise timeline and conservative threshold approach, we might have reached an impasse.

Notice the structure: Stakes established quickly. Multiple actions that moved things forward: running analysis, presenting data, proposing compromise, bringing in allies. Clear result with business impact. And honest learning.

In your quest to be empathetic and positive, you'll be tempted to purge your story of any negative emotional content. Don't do this. If someone yelled at you, say that. If they were angry and vindictive, say that. If the executive was threatening the department with dissolution, say how that was affecting you and your coworkers. Do all this in an even and professional, journalistic tone, focusing on facts, and show that your conflict resolution skills extend to handling emotionally charged situations.

The Result Includes the Relationship

Achieving forward motion on a project after a conflict is progress, but if your relationships are damaged, endangering future progress, then your story casts doubt on your conflict resolution skills.

When presenting the Result part of your CARL response for a conflict, include the state of the relationships after the conflict was resolved. Consider stating it explicitly:

Jenny was satisfied with this compromise and expressed it in the follow-up meeting.

And cite evidence of future successful collaborations when possible.

If relationships were damaged in some way, tread carefully and provide some reason why the interviewer should trust you to resolve conflicts.

Telling a story where you were clearly wrong from the start is risky. If the interviewer can immediately see the flaw in your position, you risk looking like someone with poor judgment. Even when discussing conflicts where you eventually changed your mind, choose situations where your initial position was defensible.

Bonus: The Question Everyone Forgets

Every single interview ends with "Do you have any questions for me?"

"No, I think you covered everything" is a massive missed opportunity.

Having thoughtful questions shows genuine interest and engagement. It's also your chance to learn about the role and evaluate whether this is the right fit for you. Prepare 3-5 questions for each type of interviewer: hiring managers, peers, skip-levels, cross-functional partners.

Good Questions to Ask

Role-specific:

"What does success look like in the first 90 days?"
"What's the most important problem you're hoping this hire will solve?"

Team dynamics:

"How does the team handle disagreements on technical decisions?"
"How do engineers collaborate with product managers here?"

Growth:

"What opportunities are there for learning and development?"

Challenges:

"What's the biggest challenge the team is facing right now?"

Culture:

"What do you personally enjoy most about working here?"

Tailor your questions to the interviewer. Ask the hiring manager about team challenges. Ask peers about day-to-day work. Ask leadership about company direction. And if you're a more senior candidate, then the interviewer will expect more strategic questions as you show them you can be an expert partner in leading their organization.

Questions to Avoid

Anything easily Googleable. "What does your company do?" shows you didn't prepare.
Compensation and benefits. Save these for the recruiter, not your interviewers.
Questions that sound like you're already negotiating before you have an offer.
"How did I do?" It puts the interviewer in an awkward position and rarely gets a useful answer.

Exercise: Prepare Your Big Three

Write your TMAY using the three-part structure.
- Personal Summary
- Accomplishments (2-3)
- Forward-Looking Statement
- Time yourself: target 30 seconds to 1 minute
Identify your Flagship Story.
- Does it optimize for Impact, Scope, and Personal Contribution?
- Write out a Table of Contents structure for it
- Prepare for the common follow-ups
Prepare your Conflict story.
- High stakes? Deeply involved? Were you right?
- Write out the full CARL with emphasis on resolution actions
Write 3+ questions you'll ask interviewers.
- At least one for each interviewer type you'll encounter

These four preparations will serve you in virtually every behavioral interview you do.

What's Next

You've got the frameworks. You've got your stories. You've prepared the Big Three.

But if you're targeting FAANG or other Big Tech companies, there's a specific language and framing that resonates with those interviewers.

In the next article, we cover the cultural shifts you need to understand and exactly how to adapt your stories for Big Tech expectations.

Mark as read

Next: Adapting to Big Tech