This newsletter is sponsored by CodeRabbit.
Fewer findings. Only real risks.
AI-generated code can introduce vulnerabilities that are easy to miss in a pull request.
CodeRabbit Security continuously reviews your codebase for complex bugs and security risks, using full-codebase context to follow data flows, dependencies, and patterns beyond the latest diff.
Run CodeRabbit Security on your own repositories today.
Thanks to CodeRabbit for sponsoring this newsletter. Let’s get back to today’s thought!
Intro
Most engineers put a LOT of effort into preparing for tech interviews, they practice solving many of the leetcode-type problems (yes, still in 2026), prepare for system design interviews, and other similar types.
I focused a lot on that part as well when I was interviewing for Senior+ engineer roles in the past.
But what many people forget (me included in the past!) is that the tech interview is there to check the box of whether the person has the right knowledge and necessary technical skills.
But companies still need to answer these questions:
Will you be effective in this role?
Will you work well in this environment?
And at what level should we hire you?
All of these are determined in the behavioral interview. And it’s crucial that you do well on it.
To help us know exactly what companies look for to assess the fit and level of a potential hire, luckily, Steve Huynh will share with us today his insights from conducting nearly 1,000 interviews at Amazon.
Let’s introduce our guest author and get started.
Introducing Steve Huynh
Steve spent almost 20 years at Amazon as an engineer, growing all the way to becoming a Principal Engineer. During that time, he was an Amazon Bar Raiser, conducting a lot of interviews with potential hires while also training other interviewers.
Today, Steve is kindly sharing an excerpt of the chapter adapted for this newsletter, from his book Technical Behavioral Interview: An Insider’s Guide.
I also got a copy of the book and can attest to both the quality and depth of information. If you are looking to improve your behavioral interviews, this should be your go-to book.
Let’s start!
Technical skills alone don’t determine your offer
The primary consideration for any tech role is whether you have the technical skills to do the job.
Companies will assess this mostly through tech interviews, like, coding challenges, system design, or whatever technical evaluation matches the specific role. If the candidate can’t demonstrate the core technical capability, nothing else matters.
But technical skills alone are not enough.
Companies learned this the hard way by hiring smart people who couldn’t work effectively in their environment. That’s why behavioral interviews focus on 2 additional types of fit:
Role fit
Can you handle the specific challenges and working conditions of this position? A backend role at a fast-growing startup requires different capabilities than a backend role at an established enterprise. The technical skills might be similar, but the role demands will be different.
Company fit
Will you do well in the environment in which this organization operates? They want to see if your working style, decision making style and values align with how the company operates.
And companies use behavioral interviews to answer 2 critical questions:
Do you fit with both the role and the company?
And if you do fit, at what level will you be most effective?
Here is how it works:
You get both of them right, you get an offer at the right level.
If you get the fit wrong, you will be rejected no matter how skilled you are.
Get the level wrong and you will be down-leveled or rejected for being underqualified.
Signals to detect fit
Companies can’t just directly ask: “Would you fit here”? Because, I don’t believe any candidate would answer the question with “No”.
Instead, what companies do, is look for signals in your stories that show either you are a fit or not.
Let’s go through both specific role and company fit signals, next.
Specific role fit signals:
If the role requires you to work with ambiguous requirements, do your stories demonstrate that your comfortable working when uncertainty is high?
If the position involves cross-team coordination, do your stories demonstrate an ability to do well working with mutliple teams?
If the job needs fast iteration, do your examples show shipping quickly and adjusting based on feedback?
Specific company fit signals:
A company that values “bias for action” looks for stories that show you moving quickly despite incomplete information.
An organization that values “customer obsession” wants to hear you share examples of you going deep to understand user needs.
A place that has a culture of “radical transparency” is looking for stories that show you sharing information openly, even when you’re uncomfortable.
The same story can send different signals to different companies.
This is very important to keep in mind:
You spending 3 weeks perfecting a solution might demonstrate attention to quality at one company but analysis paralysis at another.
Moving fast and fixing issues later demonstrates good judgment at a growth startup but recklessness at an established healthcare company.
A lot of it comes down to what the company culture is, so always look at it backwards from the company perspective, and put your focus on demonstrating the qualities that a specific company values.
Let’s go through some specific examples of what you need to watch out, based on what kind of a company and the role you are interviewing for.
Common “mis-fits”
Even a talented candidate will get rejected if they are not a good fit. It’s important to understand that the same behaviors that are positive at one company can be a poor fit at another. Let’s go through some examples.
Example 1: Being independent versus work collaboratively
This covers both how you work and how you make decisions. Some companies need people to take a problem, own it, and return with a solution. Some expect you to bring the team along with you at every step.
Companies asking you to do work on your own also want you to make calls on your own, and companies asking for collaborative work want buy-in from the group on decisions.
If all your stories are about going off and building something by yourself, consensus-driven companies will worry that you’ll steamroll people or make decisions without informing anyone.
And if every story needs group agreement before you act, companies that value individual ownership will ask if you can make a decision without a meeting.
Example 2: Shipping fast versus being thorough
Startups need to experiment fast, ship MVPs and iterate based on feedback, while companies in healthcare or finance need to validate carefully before any release.
This tension also shows up in how teams think about code quality. Some organizations will happily spend extra weeks to perfect the architecture, while others want a working solution as soon as possible, even if the code needs cleanup later.
A startup might be bored by methodical testing stories and a medical device company might be scared off by your “ship it and fix it” stories.
Example 3: Being a technical expert versus focusing on pragmatism
There are organizations that value technical expertise and clean architecture above all else. Others need practical solutions on time, even if imperfect.
If you try to focus on perfect code, you will fail in a deadline-driven company. If you accept technical debt everyplace, you will fail in a company that maintains critical infrastructure.
Example 4: Innovation versus stability
Some roles are about innovating and challenging the status quo, others are about maintaining and optimizing existing systems.
If you say you are constantly reinventing established processes, teams that value stability won’t think you’re a good fit.
Alternatively, stories that demonstrate you follow only established patterns will fall flat with teams seeking creative problem solving.
Example 5: Being direct versus diplomatic
Some cultures value radical candor and want you to say exactly what you think. Others value harmony and communication in an effort to not burn any bridges.
If you are too blunt, you will not fit in well at a relationship-focused company. If you are not direct enough, you will not like working at a company that values “disagree and commit.”
Example 6: Do you make data-driven decisions or focus on intuition?
Some companies need data to justify each decision (“data-driven” cultures) whereas others trust their judgment and go more on gut feel.
Showing that you make decisions based on instinct does not impress analytical companies, and telling a company that values experienced judgment that you conduct 3 A/B tests to choose a button color will get you struck off their list.
Example 7: Are you a specialist or generalist?
Big companies often look for deep experts who master 1 domain, while smaller companies need people who like to wear multiple hats. This is crucial to understand when you are showcasing your experince through stories.
Important: Understanding the fit is crucial. That’s how you can pick stories that match the company and the role.
Now that we understand how the “fit” works, let’s go through 4 dimensions that determine your level.
The 4 dimensions that determine your level
Companies measure your level across 4 dimensions that are present across every story you tell. Each dimension represents a different part of your ability. Together, they show the company where you operate most effectively.
We’ll go through each, next, and also define what’s expected for a specific level.
Scope
Scope provides a measure of the number of people on your team and, extending outward as you advance, whose work was affected by your actions. The greater the number affected, the higher your level for this dimension.
Entry Level:
Your work affects your own productivity and starts to help other team members. For example, you might improve how you handle assigned tasks or fix issues that were slowing down a few teammates.
Mid Level:
Your work affects aspects of the team and shapes how it operates.
You might redesign a process that changes a significant part of how your team works or solve problems that affect most of the team’s effectiveness.
Senior Level:
Your work directly impacts your entire team and is beginning to influence at least one other team.
You create solutions that change how your whole team operates and affect workflows in adjacent teams, or you solve problems that require coordination with other groups.
You may also start collaborating more closely with product or design partners on your immediate team’s work.
Staff Level:
Your work directly impacts at least two teams and is beginning to have an influence on the broader division or organization. Examples of this include developing technical strategies that change how multiple teams make decisions and solving problems that require buy-in across several parts of engineering.
Your influence extends beyond engineering into product, design, and program management as you shape solutions that affect how cross-functional partners work.
Principal Level:
Your work affects many teams or changes how large parts of the organization operate.
You have created technical strategies that have influenced how dozens of teams make decisions.
You have solved problems that cut across a large engineering organization.
At this level, your influence regularly extends into business strategy, shaping decisions alongside product, design, program, and business leadership.
Contribution
Contribution captures what you did, not what happened around you. It is important to be precise about the line between “I” and “we.” Companies will expect to see evidence of increasing leadership and ownership as you advance in your career.
Entry Level:
You execute assigned work and are beginning to take ownership of small pieces. Examples: implementing solutions designed by others; fixing bugs in existing systems; taking full responsibility for well-defined features within larger projects.
Mid Level:
You own complete solutions from problem to implementation while also guiding others.
You have identified issues, designed the approaches, implemented them, and you have verified that they work, and you have helped your teammates understand the reasons for your decisions.
Senior Level:
You lead initiatives requiring coordination.
You’re expected to make progress even when the requirements are unclear or the path forward is uncertain. Examples of this include driving technical decisions for your team; mentoring others through complex problems; architecting solutions to be implemented by others; and ensuring quality work outcomes for many people.
Staff Level:
You lead cross-team initiatives and establish technical direction, often in situations where the right approach isn’t obvious and stakeholders have competing priorities.
You are defining technical approaches that are adopted by multiple teams, creating systems that enable other teams to solve problems on their own, or driving agreement on complex technical decisions across several teams.
Principal Level:
You create organizational capabilities and establish new ways of working.
You’re frequently operating in highly ambiguous environments where you must define the problem before you can solve it.
You define technical standards that guide dozens of teams, build systems that enable others to solve entire classes of problems, or transform how the organization approaches its hardest challenges.
Impact
Impact shows what changed for the better as a result of your work. Companies want to see that your work produced results worth the investment. Strong stories put numbers on the impact and connect technical wins to business or user outcomes.
Entry Level:
You improve your personal productivity and are starting to help the team work better. Examples include reducing the time you spend on repetitive tasks, fixing issues that were slowing down teammates, or improving the quality of code in the areas you touch.
Even simple measures matter at this level: time saved or bugs prevented.
Mid Level:
You improve team effectiveness in specific areas and influence team-wide practices.
You reduce deployment times for specific workflows, eliminate categories of bugs in your domain, and/or you create tools that have made the team more productive in particular areas.
You can quantify these improvements and connect them to broader outcomes like feature velocity or reliability.
Senior Level:
You transform how your entire team works and are starting to have an impact beyond your team. For example, you might have introduced new workflows that changed your team’s capabilities. Or perhaps you eliminated major sources of operational problems, or the improvements that you have created have been adopted by adjacent teams.
Your impact extends beyond just engineering metrics to product outcomes, user experience, or operational costs.
Staff Level:
You improve how multiple teams operate and drive organizational improvements.
Your impact comes from achievements such as establishing practices that several teams adopt, solving infrastructure problems that were impeding multiple teams, or creating new capabilities that open up new types of work across teams.
Your measurable impact can be tied to business metrics like revenue, customer retention, or time-to-market.
Principal Level:
You create organizational capabilities and drive strategic changes.
Impact at this level could come from establishing technical foundations that dozens of teams use to build upon, solving problems that were blocking major business initiatives, or creating leverage that compounds benefits across the company.
Your impact is measured in business outcomes and strategic capability, not just technical improvements.
Difficulty
Difficulty reflects the complexity of problems you’ve tackled, the constraints you have faced, and the trade-offs you have managed.
Under this category, solving easy problems with big impacts is less impressive than hard problems solved well.
Entry Level:
You work on straightforward problems within established patterns. For example, you might face challenges learning new technologies or debugging unfamiliar code, but the path forward becomes clearer once you understand the problem or ask for help.
Mid Level:
You work through challenges and obstacles in your work. The problems you tackle have more moving parts and less obvious solutions. These could be competing requirements or having to work through technical complexity you haven’t seen before. Or perhaps you have had to manage dependencies within your team that affected your timeline or figure out solutions when the approach wasn’t immediately obvious.
Senior Level:
You manage constraints and make technical decisions with team-level architectural implications.
The problems you solve involve multiple interacting systems and competing concerns.
You might have to balance needs across multiple stakeholders with different priorities. Maybe you make architectural decisions that affect how your whole team works, or you have to work around technical limitations that require creative solutions, or solve problems that require you to address both technical and business factors.
Staff Level:
You manage competing trade-offs across multiple teams while handling problems with significant technical and organizational complexity.
You balance different technical approaches when teams have genuinely conflicting needs.
You create solutions that affect how several teams work together.
You make architectural decisions that have to work across diverse contexts.
You get teams to agree when the technically optimal solution differs for each team.
Principal Level:
You handle fundamental trade-offs between competing organizational needs or solve problems where no clear solution exists.
The complexity at this level often involves novel problems that lack established patterns or precedents.
You balance technical excellence against delivery speed at organizational scale; work within organizational constraints while maintaining technical integrity; create approaches for entire classes of problems the company hasn’t solved before; or make decisions that affect company strategy and require executive buy-in.
Putting it all together
Companies aren’t just evaluating whether you can do the job. They’re also assessing whether you’ll thrive in their specific environment and at what level you’ll be most effective.
Both role fit and company fit determine not just whether you will get an offer, but also whether that offer will position you for success.
Understanding fit helps you know which of your experiences will connect most with what the company values.
Small companies need someone who ships fast and figures things out alone. And enterprises need someone who navigates processes and builds consensus.
Neither is inherently better than the other. They’re simply different environments that reward different approaches.
Last words
Special thanks to Steve for sharing all these important insights! Make sure to check him out on LinkedIn, and also check out his book Technical Behavioral Interview: An Insider’s Guide for more info on how to do well on behavioral interviews.
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Interested in sponsoring this newsletter? Check the sponsorship options here.
Check out my book “The Multiplier Mindset” coming out later this year, here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
the scope, contribution, impact, difficulty framing reads like a useful lens for any career. most people over-index on contribution and under-index on difficulty. worth stealing for self reviews.
One thing candidates often miss is that the story itself isn’t the signal - the decision logic inside the story is. Two people can describe similar projects, but one makes the constraints, trade-offs and ownership visible while the other mainly recites the outcome. That difference is often what lets an interviewer infer level.