Most people prepare for coding rounds for weeks and then walk into the behavioural round with nothing but a smile. It is the round they feel is "just a chat". It is also the round that quietly rejects a lot of good engineers.
This note explains what that round is, what the person across the table is actually doing, and how to get ready in a week without turning yourself into a robot.
What a behavioural round is
In a coding round, the interviewer gives you a problem and watches you solve it. In a behavioural round, they ask you to talk about things you already did. "Tell me about a time you disagreed with a teammate." "Tell me about a project that went wrong."
The idea behind it is simple. The best guide to how you will act next year is how you acted last year. So they ask for the past and listen closely.
Think of a driving test. The examiner could ask, "Are you a careful driver?" Everyone says yes. So they put you in a car and watch what you do at a red light. A behavioural question is the red light. The story you tell is the driving.
What it is really testing
It is not testing whether you are nice. Nobody is hired for being pleasant alone, and nobody is rejected for being a bit shy.
The interviewer is trying to answer a few plain questions about you.
- When something is unclear or broken, do you wait to be told what to do, or do you move?
- When you disagree with someone, can you do it without making a mess?
- When you fail, do you learn from it, or do you explain it away?
- Would the team enjoy working with you on a bad week, not just a good one?
- Do you understand what you actually did, and can you explain it?
That last one catches many people out. If you cannot explain your own project in clear steps, the interviewer starts to wonder how much of it was you.
There is also a quiet side goal. The interviewer is picturing you in their team's chat channel. They are asking themselves, "If this person joins, will I be glad or tired?" You cannot fake that for forty five minutes, so do not try. Just be clear and honest.
The usual themes
Companies word their questions differently, but almost all of them come from the same short list.
| Theme | A typical question |
|---|---|
| Ownership | Tell me about something you took on that was not your job. |
| Conflict | Tell me about a time you disagreed with someone. |
| Failure | Tell me about a mistake you made. |
| Ambiguity | Tell me about a time you had to start with unclear requirements. |
| Teamwork | Tell me about a time you helped a teammate who was stuck. |
| Learning | Tell me about something you had to learn quickly. |
Some companies add a few more: handling pressure, giving or receiving hard feedback, making a decision with little data, and pushing back on a manager. If you have a good story for each of the six above, you can bend them to fit most of these.
You do not need forty stories. You need a handful of good ones. The next note in this series shows how to build that bank.
How interviewers write notes and score
Here is something most candidates never see. The interviewer is typing while you talk. They are not writing a poem about you. They are filling a form.
A common form has a few lines, one for each theme the company cares about. Under each line the interviewer writes short facts: what you did, what happened, what number you quoted. Then they pick a rating. It may look like this.
| Rating | What it usually means |
|---|---|
| Strong no | Red flag. Blamed others, or the story did not hold together. |
| No | Vague, no result, or too small for the level. |
| Lean yes | Real story, decent detail, some gaps. |
| Strong yes | Clear story, clear role, clear result. They would fight for you. |
Afterwards, the interviewers meet or send their notes to a hiring group. Nobody remembers your voice or your jokes. They read the notes. So the best thing you can do is make it easy to write good notes about you.
What does an easy to write answer look like? One where the facts come in a clear order: what the problem was, what you did, what changed. When the interviewer can type "reduced page load from 4s to 1.2s by adding a cache and fixing two queries", you have helped them write your yes.
When your answer is a long wander, they type "talked about a project, not sure what the candidate did". That sentence rejects people.
What "level" means
The same question is scored very differently for different levels. A junior and a senior can both answer "tell me about a failure" and one of them can be a strong yes while the other is a no, with the same words.
| Level | What they expect from your stories |
|---|---|
| Fresher or intern | Small scope: a college project, an internship task, a team assignment. Clear learning. Honest about what you did. |
| Junior, 1 to 3 years | You finished tasks well, asked for help at the right time, and learned from a mistake. Scope is a feature or a bug. |
| Mid level, 3 to 6 years | You owned a whole piece of work. You handled a disagreement with a teammate. You improved something nobody asked you to. |
| Senior, 6 years and up | You shaped a decision across a team. You dealt with unclear goals. You grew other people. You can say what you would do differently. |
The mistake almost everyone makes here is telling a story that is below their level. A person with six years of work who tells a story about fixing a typo in a button is saying, without meaning to, "I have not done anything bigger." The reverse also happens. A fresher who claims to have "led the architecture" of a college project sounds like they are stretching it.
Pick stories at your level or slightly above, and tell the truth about your part.
What bad answers look like
Four patterns show up again and again. Learn to spot them in your own practice.
The "we" cloud
"We built a new service. We decided to use Kafka. We tested it and we deployed it."
Who is "we"? Two people? Twelve? The interviewer cannot tell which part was yours, so they write down "unclear contribution". Teams do real work, and saying "we" is natural. But you are being hired, not the team. Somewhere in the story, there must be an "I".
No result
"So I added the cache, and it went live, and yeah, that was it."
A story with no ending is like a film that stops in the middle. What got better? How much? How did you know? Even a rough number helps. "The slow endpoint went from about 3 seconds to under 1 second" is far better than "it got faster".
Blaming others
"The product manager kept changing requirements, and the other team never replied to my messages, so the project failed."
Maybe it was all true. It still sounds like you do not see your own part. Interviewers hear this and think, "If I hire them, will I be the next person they blame?" You can mention that others were involved. Just also say what you did about it, and what you would change in your own behaviour.
The made up hero story
"Production was down. Everyone was panicking. I stayed up all night and single handedly fixed it."
Interviewers have heard this one many times. They ask a follow up like "What was the root cause?" or "Who else was on the call?" and the story starts to wobble. A made up or inflated story is easy to catch because real stories have small boring details: the wrong config file, the Slack message at 11pm, the teammate who spotted the typo. If your story has no boring details, it sounds invented.
The fix is not to make your stories smaller. It is to make them true and specific.
What good looks like
A good answer does not need to be dramatic. Here is a short one.
"Our report page took about eight seconds to load. I was the one on call that week, so I took it. I checked the logs and found one query that scanned the whole orders table. I added an index and moved one heavy calculation to a nightly job. The page dropped to about two seconds, and support tickets about slow reports stopped within a week."
It is short and has a clear "I". It has a number and an ending. It does not claim anything it cannot prove. The interviewer can write it down in one line.
Good answers also have a few quiet qualities.
- You say what you did, not just what happened around you.
- You say why you made a choice, not only the choice.
- You are fine saying "I got that wrong at first".
- You stop talking when the story is done.
If the interviewer asks a follow up, that is good news. They are leaning in. Answer it directly and calmly.
A rough shape of the conversation
Most behavioural rounds run about 45 minutes. Here is how the time often goes.
In the story section, the interviewer usually asks one main question and then two or three follow ups. This means you do not need a new story for every question. One good story, told clearly, can carry ten minutes of conversation.
Your own questions at the end count too. Ask something real, such as "What does a good first three months look like here?" or "What is the hardest part of this team's work right now?" A blank "No, I am fine" is a missed chance.
Preparing in a week
You do not need a month. If you can give about an hour a day, here is a plan that works. Change the order to suit your life.
| Day | What to do | Time |
|---|---|---|
| 1 | Read the job post. List the six themes and note which ones it stresses. Write down every project you have worked on, even small ones. | 60 min |
| 2 | Pick 6 to 8 stories from that list. Write each as rough bullet points. Do not polish yet. | 75 min |
| 3 | Shape each story into Situation, Task, Action, Result. Add one real number to each. | 75 min |
| 4 | Say each story out loud with a timer. Aim for about two minutes. Record it on your phone. | 60 min |
| 5 | Prepare "tell me about yourself", "why this company", and "why are you leaving". Say them out loud too. | 60 min |
| 6 | Do a mock interview with a friend or a colleague. Ask them to throw in two surprise follow ups. | 60 min |
| 7 | Listen to your recordings. Fix the weak spots. Rest. Do not learn new stories tonight. | 45 min |
A few honest notes on this plan.
Saying stories out loud matters more than writing them. Written words feel fine in your head and then fall apart in your mouth. You will find the clumsy sentences only by speaking.
Do not memorise word for word. A memorised story sounds like a school recital, and the moment the interviewer interrupts, you lose your place. Remember the order of the events and a few numbers. Let the words come fresh each time.
Also, a bad mock interview is a good thing. It is better to stumble in front of a friend than in front of the real panel.
Things people ask
Can I use a story from college? If you are a fresher, yes, and it is expected. If you have work experience, use work stories first and keep college for a theme you cannot cover otherwise.
Can I use a story about a failure that was not my fault? Be careful. The interviewer wants to see you owning something. Pick a failure where you had a part, even a small one.
What if I forget a number? Say it honestly: "I do not remember the exact figure, but it was roughly a 30 percent drop." A rough number you admit is rough is fine. A number that you make up and cannot defend is not.
What if my work is confidential? Change the names and hide the company details, but keep the shape of the story and the size of the result. You can say "a payments service at my current company" without naming anything private.
Try it yourself
- Open the job post for a role you want and underline three words that point to a theme (for example "ownership", "cross team", "fast paced").
- Write the six themes on a sheet of paper. Next to each, write one project from your life that could fit. Leave blanks where nothing comes to mind.
- Pick one story and say it out loud for two minutes. Record it. Listen back and count how many times you said "we" and how many times you said "I".
- Find one place in that story where you said what happened but not what you did. Add the missing sentence.
- Ask a friend to type notes while you talk, then read their notes back. If the notes are different from what you meant, your story is not yet clear.