The technical part is over and you think it went well. Then the interviewer closes her laptop lid slightly and says, "Tell me about a time you had a conflict with a teammate."
You have no work experience. The only teammates you have ever had were the three people in your final-year project group, and one of them stopped replying on WhatsApp in the last month. You are not sure that counts. So you say something safe: "I generally get along with everyone, I'm a good team player, I try to understand the other person's point of view." The interviewer writes something short and moves on.
That answer did not hurt you, exactly. It just scored nothing.
The short answer
Behavioural questions ask for evidence of how you have actually behaved, and the only evidence that counts is a specific situation, what you did in it, and what changed as a result. "I am a good team player" is a claim. The group member who went silent is evidence, and the STAR method is simply a way of telling that story in the order a listener needs: the Situation, your Task in it, the Action you took, and the Result. Freshers do have these stories. College projects, hackathons, internships, coding clubs and even coursework deadlines produce them. The work is in choosing six of them and learning to tell each in under two minutes.
Why freshers answer these badly
It is not a lack of stories. It is three habits that a college education builds and interviews punish.
The first is answering with qualities instead of events. Four years of writing "I am hardworking and a quick learner" in forms and SOPs makes it the reflex answer to any question about yourself. Interviewers have heard it from every candidate that day.
The second is undervaluing your own experience. Freshers assume a college project does not count because it was not "real work". It counts. The interviewer knows you are a fresher and is asking about college projects on purpose. A group member who disappeared, a demo that crashed in front of the external examiner, a hackathon where you had to drop a feature at 3 a.m.: these are exactly the situations that reveal how you behave under pressure.
The third is staying in "we". The team decided, we fixed it, we shipped. The interviewer cannot score a team. They need to know which part was yours.
The STAR structure
STAR is the standard structure for behavioural answers, recommended by career services such as MIT's and used in one form or another by the people on the other side of the table. It works because it forces the story into the order the listener needs.
The Situation is one or two sentences of context. What was happening and why it mattered. Not the whole history of the project.
The Task is what you specifically were responsible for. This is where "we" has to become "I". Say your role precisely, even if it was small.
The Action is what you did, step by step, and why. This should be at least half of the answer, and it should be decisions, not activity. "I decided to roll back the change rather than fix it live, because we had a demo in an hour and the rollback was one command" is an action. "We worked hard and fixed it" is not.
The Result is what changed because of what you did. Give a number when you honestly have one. When you do not, describe the concrete outcome, and add what you learned or did differently afterwards. That last part matters more for freshers than for anyone else, because interviewers hiring at entry level are betting on how fast you learn.
A good STAR answer takes ninety seconds to two minutes. Shorter, and the action is too thin. Longer, and the interviewer has stopped following.
A worked example from a college project
Question: "Tell me about a time something went wrong in a project."
Weak answer: "In our final-year project the app crashed during the demo. It was very stressful but we stayed calm, found the bug and fixed it. We learned to test more before demos."
The same event, structured.
"In our final-year project, a hostel complaint-tracking app, the backend crashed during the internal demo, about a week before the external evaluation. There were four of us; I owned the backend and the database, so this was mine to fix. First I reproduced it: it only happened when two complaints were submitted within a few seconds, which was why we had never seen it in testing alone. The cause was that I was generating complaint IDs by counting rows, so two requests got the same ID and the second insert failed and took the server down with it. I had two options: switch to a database-generated ID, which meant changing the schema a week before evaluation, or add a lock around the counter. I chose the schema change, because the lock would have hidden the real problem, and I wrote down exactly which files I changed so my teammates could review it. The external demo ran without a crash. What I actually learned was that 'it works when I test it' means very little for anything two people can do at once, and I have used database-generated IDs in every project since."
Roughly two minutes. Every part of it can be scored: a real problem, ownership, a decision with a stated trade-off, communication with the team, a result, and a lesson that changed later behaviour. Nothing in it needed a job.
Which six stories to prepare
You do not need a story for every possible question. Six true stories from projects, internships, hackathons or coursework will cover almost everything, because each can be told with a different emphasis. The Tech Interview Handbook's behavioural guide suggests a similar story bank. Aim for stories about a hard technical problem you solved, a disagreement with a teammate or a reviewer, a mistake you made and what you changed, a deadline under pressure and the trade-off you took, something you had to learn quickly, and a time you took responsibility for something that was not strictly your job.
The demo crash above can answer "tell me about pressure", "tell me about a decision with incomplete information", "tell me about a mistake", and "tell me about ownership". Same facts, different emphasis. Keep the facts constant across tellings, because interviewers on a panel compare notes.
If your experience is thin, look harder before deciding you have nothing. A group member who stopped contributing is a real conflict story. A bug that ate a weekend is a real problem-solving story. Learning a framework in ten days because the hackathon required it is a real learning story. The scale matters far less than the specificity.
The questions to expect
Behavioural questions cluster, and companies that publish their interview criteria, such as Amazon with its Leadership Principles, overlap heavily with the ones that do not. In Indian campus and off-campus interviews, expect some version of: a time you disagreed with someone and what you did; a time you failed or missed a deadline; the hardest technical problem you have worked on; a time you had to learn something quickly; a time you received feedback you did not like; a time you had to decide without enough information. Map your six stories to that list and each question will have a candidate ready.
The mistakes that make true stories sound weak
Staying in "we" is the most common, and the easiest to fix: say "I" for the parts that were yours and "the team" for the rest. The honesty about which is which is itself a signal.
Skipping the result is the second. Candidates run out of energy after the action and stop. The result, and especially the sentence about what you changed afterwards, is where ownership shows.
Choosing a story with no tension is the third. "Tell me about a challenge" answered with something that was never actually at risk scores low, because nothing was tested. Pick the stories where it could have gone badly.
Making yourself flawless is the fourth. A failure story in which you did nothing wrong is not a failure story. Interviewers trust the candidate who says "I should have tested with two users, and now I always do" far more than the one whose every story ends in triumph.
Memorising word for word is the fifth. Know the beats of each story, not the sentences. A recited answer sounds recited, and it falls apart the moment the interviewer asks a follow-up that does not fit the script.
Practise them aloud, with follow-ups
Behavioural stories improve fastest when told to someone who asks "what happened next?", "why did you do that?" and "what would you do differently?" Those are the follow-ups real interviewers ask, and they are what a memorised story cannot survive.
Tell each story to a friend and let them interrupt. If you do not have that, a practice round works: on 99Interview the behavioural track has an AI interviewer that asks a question, follows up on your answer and scores the transcript, and a live mock interview with a working engineer adds the thing a script cannot, a person telling you which of your stories they believed. Behavioural questions also turn up in the last minutes of most technical rounds, so if you are preparing for a frontend or backend interview, expect one or two there as well; the options are on the pricing page.
Frequently asked questions
How do I answer behavioural questions with no work experience?
Use college projects, internships, hackathons, club work and coursework. Interviewers hiring freshers expect these and ask about them deliberately. A group project where a member stopped contributing is a real conflict story; a demo that crashed is a real pressure story.
How many STAR stories should I prepare?
Five or six true stories with some tension in them, each tellable with different emphasis. That covers almost every behavioural question a fresher will get.
How do I answer "tell me about a time you failed" as a fresher?
Pick a real failure where something you did contributed to it, say plainly what you got wrong, describe what you did next, and finish with what you changed afterwards. A failure story where you did nothing wrong is not believed.
How long should a STAR answer be?
Ninety seconds to two minutes. The action should be about half of it.
Are behavioural questions asked in the technical round or the HR round?
Both. In many Indian companies the HR round is where most of them live, but one or two commonly appear at the end of the technical round, and product companies often have a dedicated behavioural round.
What is the difference between STAR and STARL?
STARL adds "Learning" as a fifth step. For freshers it is worth including anyway: interviewers at entry level are betting on how quickly you learn, so ending with what you changed afterwards strengthens almost every story.
Tonight
Write down the six events from your college years that were most stressful or most instructive, in one line each. Tomorrow, tell one of them to a friend in under two minutes and let them ask why.
You already have the stories. Which one would you tell if the next interviewer asked about the time something went wrong?