A
Amney Mounir
Guest
Most engineers I talk to prepare for interviews the same way. They grind coding problems for weeks, skim a system design primer, and leave the behavioral round for the night before.
The data says that plan is upside down.
At Dataford we collect interview reports from candidates after they finish a loop. For Software Engineer roles alone we have 320k+ candidate reports, 245k+ reported questions and guides for 11k+ companies. When we group those questions by category, behavioral and leadership questions come out on top.
Here is how reported Software Engineer questions break down by category:
Behavioral questions outnumber coding questions by roughly 20k. That surprised me the first time I saw it, and I have spent most of my career around data.
The most common individual questions tell the same story. Of the eight questions that show up in the most Software Engineer company guides, seven are behavioral:
Linked list reversal is the only coding question in that group. Everything else is a story about how you work.
When we summarize what each company's Software Engineer loop tests, the headline skills look very technical. Problem solving leads at about 25% of guides, then system design at about 21% and Java at about 19%. Behavioral interviewing shows up as a headline skill in only about 12% of guides.
So the headline skills point you at code, while the questions themselves spread across the whole loop.
I think there are two reasons for that gap.
First, behavioral questions show up everywhere, including inside technical rounds. A recruiter screen happens in about 79% of Software Engineer guides, and those calls often include a "tell me about a time" question. A coding interviewer often opens with five minutes on a past project. A system design interviewer will ask how you handled a disagreement about the architecture. None of those rounds get labeled behavioral, yet each one adds behavioral questions to the count.
Second, behavioral questions are cheap for interviewers to ask and hard for candidates to fake. A coding round can tell you whether someone can reverse a linked list. It says much less about whether that person will tell you a project is slipping before it is too late. Hiring teams care a lot about the second thing.
Software Engineer is the largest role in our data, so I checked whether the pattern was specific to it. It mostly holds.
In every one of these roles, behavioral questions land in the top three categories. For most of them they are first or second.
A few questions also repeat across roles. "Explaining a technical concept clearly" is among the most common questions for Software Engineer, Data Analyst, Data Scientist and Machine Learning Engineer. "Prioritizing across competing client projects" shows up near the top for Software Engineer, Data Analyst, Data Engineer and Machine Learning Engineer. If you prepare those two answers well, you can reuse them in almost any tech loop.
I have seen plenty of strong engineers do well on code and then struggle to talk about their own work. Here is the approach I recommend.
Build a story bank before you study algorithms. Write down six to eight real situations from your work. Good ones cover a hard technical problem you resolved, a disagreement with a teammate or manager, a time priorities changed halfway through, a project that went badly, and a time you had to learn something new quickly. Most of the common questions above map to one of those.
Write each story in four parts. What was the situation, what did you specifically do, what happened, and what you would do differently. Keep each story to about two minutes when spoken. Interviewers lose interest past that point, and follow-up questions do the rest.
Put the numbers in. "I reduced build time" is forgettable. "I cut our build time from about 20 minutes to about 6, which unblocked three teams" gets remembered and written down in the feedback form. If you do not know the exact number, a careful estimate is fine. Say it is an estimate.
Practice the technical explanation question out loud. "Explain a technical concept clearly" sounds easy, so people skip it. Pick something you know well, like caching, indexing or eventual consistency, and explain it to a friend who is not an engineer. Time yourself. If you need more than two minutes or any jargon, try again.
Prepare for disagreement questions carefully. "Disagreeing on a technical direction" is near the top of the list for a reason. Interviewers want to see that you push back with evidence, that you listen, and that you can commit once a decision is made. Avoid stories where you were right and everyone else was wrong. Pick one where you changed your mind, or where you lost the argument and still helped the team ship.
Rehearse with the real questions. Generic lists of behavioral questions are fine for warming up. The better move is to practice the exact questions candidates report for your target company and role. We keep a list of the most reported behavioral questions on Dataford, and it is a good place to start.
I would never tell an engineer to stop practicing coding. Coding is still about 28% of reported questions, and failing a coding round usually ends the loop.
What I would change is the split. If you have four weeks before a Software Engineer loop, I would put roughly a third of your time on behavioral prep. In practice that means writing your stories in week one, practicing them out loud every few days, and doing at least one mock interview where someone pushes back with follow-ups.
The return on that time is high. Coding prep has a long tail of problem types. Behavioral prep has a short list of question themes that repeat across companies, levels and even roles.
These numbers come from Dataford's role guides, which aggregate candidate-submitted interview reports into company and role guides. Each reported question is tagged with a category. The category shares above are each category's count divided by all reported questions for that role. The "most common questions" ranking counts how many company guides include each question. Figures are from the role pages as of mid-October 2026.
Self-reported data has limits. Candidates remember some questions better than others, and behavioral questions may be easier to recall than the details of a coding problem. People who write reports are also not a random sample of all applicants. I would treat the exact percentages as approximate and the overall pattern as the useful part.
If you want to see the full breakdown for your role, the Software Engineer interview guide shows the categories, the most common questions and the typical loop.
The short version is this. Coding gets you to the final round. In most tech loops, your stories decide what happens after that.
The data says that plan is upside down.
At Dataford we collect interview reports from candidates after they finish a loop. For Software Engineer roles alone we have 320k+ candidate reports, 245k+ reported questions and guides for 11k+ companies. When we group those questions by category, behavioral and leadership questions come out on top.
What the question counts show
Here is how reported Software Engineer questions break down by category:
- Behavioral and leadership: about 88k questions, or about 36%
- Coding: about 68k, or about 28%
- Execution: about 25k, or about 10%
- System design: about 23k, or about 9%
- Technical fundamentals: about 13k, or about 5%
Behavioral questions outnumber coding questions by roughly 20k. That surprised me the first time I saw it, and I have spent most of my career around data.
The most common individual questions tell the same story. Of the eight questions that show up in the most Software Engineer company guides, seven are behavioral:
- Prioritizing across competing client projects (about 960 guides)
- Resolving a high-stakes technical problem (about 940 guides)
- Linked list reversal (about 890 guides)
- Explaining a technical concept clearly (about 680 guides)
- Prioritizing conflicting high-stakes work (about 640 guides)
- Disagreeing on a technical direction (about 630 guides)
- Adapting to mid-project requirement changes (about 570 guides)
- Learning new technology under deadline (about 540 guides)
Linked list reversal is the only coding question in that group. Everything else is a story about how you work.
Why this is easy to miss
When we summarize what each company's Software Engineer loop tests, the headline skills look very technical. Problem solving leads at about 25% of guides, then system design at about 21% and Java at about 19%. Behavioral interviewing shows up as a headline skill in only about 12% of guides.
So the headline skills point you at code, while the questions themselves spread across the whole loop.
I think there are two reasons for that gap.
First, behavioral questions show up everywhere, including inside technical rounds. A recruiter screen happens in about 79% of Software Engineer guides, and those calls often include a "tell me about a time" question. A coding interviewer often opens with five minutes on a past project. A system design interviewer will ask how you handled a disagreement about the architecture. None of those rounds get labeled behavioral, yet each one adds behavioral questions to the count.
Second, behavioral questions are cheap for interviewers to ask and hard for candidates to fake. A coding round can tell you whether someone can reverse a linked list. It says much less about whether that person will tell you a project is slipping before it is too late. Hiring teams care a lot about the second thing.
It holds across other tech roles
Software Engineer is the largest role in our data, so I checked whether the pattern was specific to it. It mostly holds.
- Data Analyst: behavioral and leadership is the biggest category at about 43% of reported questions, well ahead of SQL at about 23%.
- Product Manager: behavioral is about 30%, tied with execution as the top category.
- Data Engineer: pipelines lead at about 39%, and behavioral is second at about 22%.
- Data Scientist: machine learning leads at about 20%, and behavioral is a close second at about 19%.
- Machine Learning Engineer: machine learning leads at about 32%, and behavioral is second at about 16%.
- AI Engineer: system design leads at about 19%, with generative AI and behavioral close behind at about 16% and 14%.
In every one of these roles, behavioral questions land in the top three categories. For most of them they are first or second.
A few questions also repeat across roles. "Explaining a technical concept clearly" is among the most common questions for Software Engineer, Data Analyst, Data Scientist and Machine Learning Engineer. "Prioritizing across competing client projects" shows up near the top for Software Engineer, Data Analyst, Data Engineer and Machine Learning Engineer. If you prepare those two answers well, you can reuse them in almost any tech loop.
How I would prepare
I have seen plenty of strong engineers do well on code and then struggle to talk about their own work. Here is the approach I recommend.
Build a story bank before you study algorithms. Write down six to eight real situations from your work. Good ones cover a hard technical problem you resolved, a disagreement with a teammate or manager, a time priorities changed halfway through, a project that went badly, and a time you had to learn something new quickly. Most of the common questions above map to one of those.
Write each story in four parts. What was the situation, what did you specifically do, what happened, and what you would do differently. Keep each story to about two minutes when spoken. Interviewers lose interest past that point, and follow-up questions do the rest.
Put the numbers in. "I reduced build time" is forgettable. "I cut our build time from about 20 minutes to about 6, which unblocked three teams" gets remembered and written down in the feedback form. If you do not know the exact number, a careful estimate is fine. Say it is an estimate.
Practice the technical explanation question out loud. "Explain a technical concept clearly" sounds easy, so people skip it. Pick something you know well, like caching, indexing or eventual consistency, and explain it to a friend who is not an engineer. Time yourself. If you need more than two minutes or any jargon, try again.
Prepare for disagreement questions carefully. "Disagreeing on a technical direction" is near the top of the list for a reason. Interviewers want to see that you push back with evidence, that you listen, and that you can commit once a decision is made. Avoid stories where you were right and everyone else was wrong. Pick one where you changed your mind, or where you lost the argument and still helped the team ship.
Rehearse with the real questions. Generic lists of behavioral questions are fine for warming up. The better move is to practice the exact questions candidates report for your target company and role. We keep a list of the most reported behavioral questions on Dataford, and it is a good place to start.
How I would split prep time
I would never tell an engineer to stop practicing coding. Coding is still about 28% of reported questions, and failing a coding round usually ends the loop.
What I would change is the split. If you have four weeks before a Software Engineer loop, I would put roughly a third of your time on behavioral prep. In practice that means writing your stories in week one, practicing them out loud every few days, and doing at least one mock interview where someone pushes back with follow-ups.
The return on that time is high. Coding prep has a long tail of problem types. Behavioral prep has a short list of question themes that repeat across companies, levels and even roles.
How the data was built
These numbers come from Dataford's role guides, which aggregate candidate-submitted interview reports into company and role guides. Each reported question is tagged with a category. The category shares above are each category's count divided by all reported questions for that role. The "most common questions" ranking counts how many company guides include each question. Figures are from the role pages as of mid-October 2026.
Self-reported data has limits. Candidates remember some questions better than others, and behavioral questions may be easier to recall than the details of a coding problem. People who write reports are also not a random sample of all applicants. I would treat the exact percentages as approximate and the overall pattern as the useful part.
If you want to see the full breakdown for your role, the Software Engineer interview guide shows the categories, the most common questions and the typical loop.
The short version is this. Coding gets you to the final round. In most tech loops, your stories decide what happens after that.