Behavioural Interview Questions for Freshers (2026): STAR Answers When You Have No Work History
Updated August 2026
Behavioural questions ask you to narrate a specific past event: a time you failed, a disagreement, a deadline you missed. They are not the HR-round classics — "tell me about yourself", strengths and weaknesses, relocation, salary, five years — which are a different round with different rules and are covered in our HR interview questions guide. This page is only the situational ones, because they are where freshers lose the most marks and get the least preparation.
The structure interviewers are listening for is STAR: the Situation (where and when, briefly), the Task (what you specifically had to do), the Action (what you actually did, step by step) and the Result (what happened, including numbers or consequences). Most freshers give the Situation, skip straight to a general claim — "so I managed it well and we completed the project" — and never supply an Action or a Result. That is the single most common failure in these rounds, and it is a structural mistake rather than a lack of experience.
You do have material. Interviewers know you have no work history and are not expecting one: your evidence is course projects, a final-year team, a hackathon, a fest committee, an internship, tutoring, a club you ran. What they are testing is whether you can describe a real event honestly, say what you personally did rather than what the group did, and be straight about how it turned out. Do not memorise fifteen answers — prepare four or five real stories, know their details cold, and learn to angle them, because one messy team project can honestly answer a conflict question, a deadline question and a failure question depending on which part you lead with.
Frequently asked questions
Tell me about a time you failed.
The interviewer is testing whether you can own an outcome without either collapsing or deflecting. Pick a real failure with a real consequence — a module that did not work at the demo, a hackathon submission that missed the deadline — not a disguised achievement. Structure: what you were responsible for, the specific decision or omission that caused the failure, what actually happened as a result, and what you changed afterwards with evidence that the change stuck. The two fatal versions are the humble-brag ("I worked too hard on it") and the blame-shift ("my teammates did not deliver"). A genuine failure where you name your own contribution to it is what earns the mark.
Tell me about a conflict you had with a teammate.
They want to know how you behave when you are annoyed, because that predicts how you will behave on a team. Choose a real disagreement — a technical direction, a division of work, someone who kept redoing your code — and describe what you did to resolve it rather than who was right. Strong answers include a specific conversation you initiated, an attempt to understand the other position, and a concrete resolution, even a partial one. Avoid stories where you are entirely right and the other person is simply incompetent; that tells the interviewer more about you than about them. "I stayed quiet to avoid conflict" is also a weak answer — it says the situation went unaddressed.
Tell me about a time you missed a deadline.
This is a question about estimation and communication, not about the miss itself. Answer with a real one: a submission, a sprint in an internship, a module you promised your team by Friday. The critical part is what you did when you realised it was slipping — did you tell someone early, or did the team find out on the deadline? Interviewers care much more about early warning than about perfect delivery. Close with what you now do differently: how you estimate, how you flag slippage, and evidence that it changed the next time. Claiming you have never missed a deadline reads as either untrue or as never having taken on anything difficult.
Tell me about a time you persuaded someone to your point of view.
The test is whether you can influence without authority, which is exactly your position as a fresher. Good fresher material: convincing a project team to change an approach, persuading a professor to allow a different topic, getting a fest committee to reallocate a budget. Describe the other person's actual objection — this is the part most candidates skip and it is the part that proves the story is real — then what evidence or argument you used, and how they responded. Note honestly if they only partly agreed. Answers where everyone immediately sees your point are not persuasion stories; they are announcements.
Tell me about a time you had to learn something quickly.
They are testing your learning method, not your intelligence. Pick something concrete with a deadline attached: a framework needed for a project two weeks out, a tool an internship expected you to know. Describe the actual method — what you read, what you built to test your understanding, who you asked, what you skipped deliberately — and the point where you realised you had it. Then give a result: what you shipped with it. The weak version is "I learn fast and I picked it up in a week", which contains no method and no evidence, and is exactly what everyone says.
Tell me about working with someone who was not contributing.
Nearly every student has this story and most tell it badly, as a complaint. The interviewer is checking whether you addressed it or absorbed it silently. Describe what you noticed, what you did first — usually a direct, private conversation rather than escalation — what the person said, and what you did when it did or did not improve. It is fine and often realistic to say that you ended up doing part of their work, provided you also say what you did to try to change the situation and what you would do differently now. Answers where you went straight to the professor without ever speaking to the person read as poor judgement.
Tell me about a time you received harsh feedback or criticism.
This tests coachability, which for a fresher matters more to a recruiter than current skill. Use real criticism with a sting to it: a mentor calling your code unreadable, a reviewer saying your presentation had no structure. Report the feedback accurately — including the uncomfortable wording — say what your first reaction honestly was, then what you actually did about it and how you know it worked. Answers where the feedback was mild, or where you agreed instantly and improved effortlessly, do not demonstrate anything. The useful signal is that you can hear something unpleasant and act on it rather than defend against it.
Tell me about a time you took initiative without being asked.
They are looking for evidence that you act when nobody assigns you the work, because that is the difference between a fresher who needs supervision and one who does not. Good material: automating something tedious your team was doing manually, writing documentation nobody asked for, starting a study group before a placement season, fixing a bug outside your module. Say what you noticed, why you decided it was worth your time, what you did, and who benefited — the benefit is what turns initiative into a result rather than a hobby. Avoid initiative that ignored the team and created work for others; that is a different signal entirely.
Tell me about a decision you made without enough information.
This is a judgement question and it is asked more often than freshers expect. Pick a real fork: choosing a library with no time to evaluate alternatives, deciding what to cut when a project was running late, picking a topic with incomplete guidance. The interviewer wants your reasoning under uncertainty — what you knew, what you could not find out in the time available, what assumption you made explicit, and how you limited the damage if you were wrong. Then the outcome, honestly, including if the decision turned out badly. A defensible bad decision, clearly reasoned, scores better than a lucky good one with no reasoning behind it.
Tell me about a project you are proud of — and what went wrong in it.
The second half is the real question, and interviewers add it precisely because rehearsed project answers are uniformly glowing. Describe the project briefly and concretely, then be specific about what did not work: a component you built twice, an approach abandoned late, a feature that never worked properly and was quietly dropped before the demo. Every real project has these. A candidate who says nothing went wrong is either not being straight or was not close enough to the work to know — and a follow-up question will usually reveal which. Naming a genuine problem and what you learned from it is the strongest thing you can do here.
Tell me about a time you had to manage competing priorities.
For a fresher this is almost always exams, a project deadline and something else — a fest, a certification, a family obligation — landing in the same fortnight. That is a perfectly acceptable answer. Describe how you decided what mattered most, what you consciously dropped or postponed, and who you told about it. The last part is what separates a real answer from an ordinary one: people who manage competing work well tell the affected parties early rather than silently under-delivering on one of them. Give the outcome, including anything that suffered — claiming everything went perfectly is not credible.
Tell me about a time you helped a teammate succeed.
They are checking whether you notice other people, since a fresher who lifts a team is worth more than one who only performs individually. Use something specific: teaching a batchmate a tool before a deadline, taking over a piece of work when someone was ill, restructuring how a group divided tasks so a struggling member could contribute. The mark of a good answer is that the other person's outcome is the result you report, not your own. Be careful not to describe rescuing someone incompetent — that is a story about you, and it usually lands badly.
Tell me about a time you disagreed with a senior, a mentor or a professor.
This tests whether you can push back respectfully on someone with authority — which recruiters care about because a fresher who silently implements something they know is wrong is a real cost. Pick a genuine disagreement: an approach you thought would not scale, a requirement you believed was misread. Describe how you raised it — privately, with evidence, framed as a question rather than a challenge — and then, crucially, what you did when the decision went against you. "I disagreed, said so with my reasoning, and then committed fully to their call" is a strong ending. So is being proved right without gloating about it.
Tell me about a time you explained something technical to a non-technical person.
Communication is being tested directly, so the answer must demonstrate it rather than describe it. Real fresher material: explaining your project to an examiner from another department, to parents, to a fest sponsor, to junior students. Say who they were, what they actually needed to understand and why, the analogy or framing you used, and how you knew it landed — a question they asked back is the best evidence. Then, if you can, briefly demonstrate it in the interview by explaining the same thing simply. Candidates who say "I simplified it for them" without showing how have not answered the question.
Tell me about a time something changed at the last minute.
Adaptability, asked concretely. Good material: a requirement that changed days before a review, a teammate dropping out before submission, an API or dataset that stopped working, a venue or schedule change during an event you were running. Describe what changed, what you had to abandon, how you decided what the new minimum viable outcome was, and what you delivered. Interviewers are listening for whether you re-planned deliberately or simply worked longer hours — the second is common and much weaker. Mention who you informed, because handling change well is mostly about telling people early.
Tell me about a time you were wrong about something technical.
A quieter question that separates honest candidates from rehearsed ones. Use a real technical misconception you held and had corrected: a wrong mental model of how something worked, a bug you insisted was in someone else's code and was in yours, a design you defended and then had to abandon. Say how you found out you were wrong, what convinced you, and what you did next. The valuable signal is the speed and grace of the update. Freshers who cannot produce any example of having been technically wrong are usually telling the interviewer they have not built enough to find out yet.
Don't just read Behavioural (STAR) questions — get asked them
Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.
Start a free AI mock interviewHow to prepare
- Prepare four or five real stories, not fifteen answers. One difficult team project can honestly answer conflict, missed deadline, non-contributing teammate and failure questions depending on which part you lead with — and five well-known stories are far more robust under follow-up questions than fifteen half-remembered ones.
- Say "I", not "we". The single most common fresher mistake is narrating a group achievement without ever specifying your own contribution. Interviewers will keep asking "and what did you do?" until they get it, and every time they have to ask, the answer weakens.
- Give a Result every time, and let it be a bad one when it was bad. A failure story with no consequence is not a failure story, and interviewers notice immediately. Numbers help — how many users, how much time saved, how late the delivery was — but a plainly stated outcome works too.
- Keep the first pass to sixty or ninety seconds. Behavioural rounds are conversations: give the tight version, then let the interviewer take it deeper with follow-ups. Candidates who narrate an entire semester unprompted lose the room before the interesting part.
- Never invent a story, and never inflate an internship. Two follow-up questions collapse a fabricated example — what was the teammate's objection, what exactly did the error say — and an interviewer who catches one invention discounts everything else you have said.
- Avoid the story where you are the hero and everyone else is useless. Even when it is accurate, it reads as poor judgement about people, and there is almost always a version of the same event that shows what you did without indicting everyone around you.
- Practise them out loud, not in your head. These answers are almost always the first time a fresher has narrated their own work aloud to a stranger, and the gap between a story you know and a story you can tell under mild pressure is the entire difficulty of a behavioural round.
Where these questions get asked
- TCS NQT guide and Infosys hiring guide — the two biggest exams these questions appear in.
- All company placement guides — pattern, syllabus and rounds for every mass recruiter.