Behavioural & HR — Notes
How behavioural and HR interviews really work, and how to answer them: the STAR method, a story bank, every core competency, the HR round, salary talk and company-specific styles. Print this page for a PDF.
1. What Interviewers Are Really Assessing
A behavioural question asks about something you actually did in the past: "Tell me about a time you disagreed with a teammate." The idea is simple: how you behaved before is the best guide to how you will behave next.
There is no single right answer. The interviewer is collecting signals (small pieces of evidence) about how you work with people, handle problems and take responsibility. Your job is to give them clear, specific evidence.
It is like a reference check you give about yourself. A good reference does not say "she is great"; it says "when our release broke on a Friday night, she stayed, found the cause and wrote down how to stop it happening again". Stories, not adjectives.
The competencies they look for
A competency is a skill or habit the company cares about. Most companies, from startups to large product and service firms, look for roughly the same set, even if they name them differently.
| Competency | Junior / fresher answer shows… | Senior (3–5 yrs) answer shows… |
|---|---|---|
| Teamwork | You helped others, shared work fairly, asked for help early. | You made the whole team work better: unblocked people, improved a process. |
| Conflict handling | You disagreed politely and used facts, not feelings. | You resolved a disagreement between people or teams and kept the relationship. |
| Ownership | You finished what you started and fixed your own mistakes. | You took responsibility beyond your task: incidents, orphaned projects, follow-ups. |
| Leadership | You led a college project or a small task; people followed your plan. | You influenced without authority, mentored, and set direction. |
| Learning from failure | You admitted a mistake and said what you learned. | You changed a process so the whole team would not repeat it. |
| Problem solving | You broke a problem into steps and debugged it patiently. | You picked the right problem to solve and weighed trade-offs. |
| Handling pressure | You stayed calm near a deadline and prioritised. | You negotiated scope, protected quality and kept others informed. |
| Communication | Your answer is clear and in order. | You adjust your message for engineers, managers and customers. |
| Customer focus | You thought about the user of your feature. | You traced your work to business results and customer pain. |
How they score you
Most structured interviews use a rubric: a sheet listing the competencies and a scale for each. After the call, the interviewer writes notes and gives a rating per competency, then an overall "hire" or "no hire". What moves your score up:
- Specific over general. "Last March, on the checkout page…" beats "I usually…".
- Your own actions. They can only score what you did, so "we" answers score low.
- Real stakes. A story with a deadline, a customer, or money involved gives stronger evidence than a trivial one.
- A result and a lesson. What happened, ideally with a number, and what you would do again or differently.
- Honesty and self-awareness. Admitting a gap and showing growth is a positive signal, not a negative one.
| Rating (typical scale) | What the notes usually say |
|---|---|
| Strong yes | Clear, specific story; candidate drove the outcome; measurable result; good reflection. |
| Leaning yes | Good story, but some parts vague, or result not clear. |
| Leaning no | Mostly "we"; hypothetical ("I would…"); needed many follow-up questions. |
| Strong no | Blamed others, showed a red flag (dishonesty, disrespect), or had no example at all. |
Follow-up questions are part of the test
Good interviewers dig: "What exactly did you say to him?", "What would you do differently?", "What did your manager think?". These check that the story is real and that you understand it deeply. Pick stories you lived through, so the follow-ups feel easy.
The behavioural round (often by an engineer or manager) tests competencies through past stories. The HR round checks fit and practical details: why this company, salary, notice period, relocation. The two overlap, and this page covers both: Parts 1–2 are behavioural, Part 3 is HR.
Before an interview, read the job description and the company's values page. Circle 3–4 competencies they clearly care about ("ownership", "customer first") and make sure you have a story ready for each.
Giving opinions instead of evidence: "I am a great team player and very hard-working." Every candidate says this. Without a story behind it, the interviewer has nothing to write down.
2. The STAR Method
STAR is a simple order for telling a work story: Situation, Task, Action, Result. It stops you rambling and makes sure you cover what the interviewer needs to score you.
Situation and Task set the scene. Action is what you did, and it is where most of the marks are. Result is what changed, plus what you learned.
Like a good movie trailer: a few seconds of setting, one clear problem, most of the time on the hero's moves, and a satisfying ending. Nobody wants a trailer that is all opening credits.
Each part, with an example (story A)
| Part | What to say | Example: checkout speed (A) |
|---|---|---|
| Situation | Where, when, who, what was wrong. 1–2 sentences. | "At Brightcart, our checkout page took 4.2 seconds to load at p95, and the product team saw users dropping off." |
| Task | Your job or goal in it. 1 sentence. | "I was asked to own the performance work and get it under 2 seconds before the next quarter." |
| Action | 3–4 steps you took, with the "why" for each. Use "I". | "I profiled the page and found three causes: a large JS bundle, five API calls in sequence, and uncompressed images. I split the bundle, merged the calls into one endpoint with the backend team, and moved images to a CDN with modern formats. I added a performance budget to CI so it would not slip back." |
| Result | What changed, a number if honest, and a lesson. | "p95 dropped to 1.6 seconds and conversion rose about 6% over the next month. I learned to measure first; my first guess about the cause was wrong." |
Variants: CAR and SOAR
| Format | Parts | When to use it |
|---|---|---|
| STAR | Situation, Task, Action, Result | The default for most "tell me about a time" questions. |
| CAR | Challenge, Action, Result | Short answers, rapid-fire rounds, or when the task is obvious from the situation. Good for freshers with small stories. |
| SOAR | Situation, Obstacle, Action, Result | When the story is about overcoming a blocker: a difficult person, missing information, a tight deadline. Naming the obstacle makes the difficulty clear. |
| STAR + L | STAR, then Learning | Failure and mistake questions. The learning is the point of the answer (section 9). |
Timing
- 1.5 to 2 minutes for a full answer. Under 1 minute usually means it is too thin; over 3 minutes and the interviewer stops listening.
- About 60% on Action. If you notice you are still describing the situation after 30 seconds, jump: "So what I did was…".
- Leave room for follow-ups. A crisp answer invites good questions; a long one uses up the interview on one story.
The "I vs we" rule
Software is team work, so "we" feels natural and modest. But the interviewer is hiring you. Use "we" for the team's goal and context, and "I" for every action you personally took.
| Weak | Strong |
|---|---|
| "We fixed the webhook bug and refunded everyone." | "I traced the bug to retries without idempotency, wrote the fix, and worked with finance to refund the 38 customers." |
| "We decided to refactor." | "I proposed a two-day spike to compare both options, and after the results the team agreed to refactor." |
It is fine to credit others: "Priya handled the database side while I…". That shows teamwork and makes your own part clearer.
Quantifying results honestly
- Use numbers you actually know: time saved, errors reduced, users affected, load time, tickets closed, marks or rank for freshers.
- Round and say "about": "about 6%", "roughly 30 hours a month". Never invent precision.
- If there is no number, describe the change: "the support team stopped escalating this issue", "the intern started submitting clean pull requests by week four".
- Be ready for "How did you measure that?". If you cannot answer, do not use the number.
Write each story as four short bullet points (S, T, A, R), not a script. Practise saying it out loud with a timer. Aim for about 90 seconds, then stop and let them ask.
Spending a minute on company background and tech stack before anything happens. Also avoid ending on the action with no result; the interviewer is left asking "so, did it work?".
3. Building Your Story Bank
A story bank is a short list of 8–10 real experiences you have prepared in STAR form. Each one can answer several different questions. With a good bank, you never have to invent a story on the spot.
Most behavioural questions fall into about 10 themes. If you have 2–3 stories for each theme, you are covered for almost anything.
Like a cook's prepared ingredients. Chopped onions, boiled rice and a ready sauce can become many different dishes quickly. Your prepared stories become answers to many different questions.
The worksheet: stories mapped to competencies
Here is the example profile's bank (the Brightcart developer, about 3 years' experience). A dot means the story is a strong fit for that theme. Stories are referred to by letter throughout these notes and the Q&A page.
| Story | Team | Conflict | Ownership / lead | Failure | Pressure | Problem solving | Learning | Customer |
|---|---|---|---|---|---|---|---|---|
| (A) Checkout speed: 4.2 s → 1.6 s, conversions up ~6% | • | • | • | • | ||||
| (B) Webhook bug double-charged 38 customers; fix, refunds, postmortem | • | • | • | • | • | |||
| (C) Rewrite vs refactor disagreement; ran a spike | • | • | • | |||||
| (D) Took over delayed reporting tool; re-scoped, shipped in 3 weeks | • | • | • | |||||
| (E) Mentored two interns; one struggling with reviews | • | • | ||||||
| (F) Missed estimate: 1 sprint became 3 | • | • | • | |||||
| (G) Learned Kubernetes basics in two weeks | • | • | ||||||
| (H) Pushed back on skipping tests before a sale | • | • | • | • | ||||
| (I) B2B bulk-import failures; joined call, built validation report | • | • | • |
Fresher version. The final-year student's bank is smaller but works the same way: the internship admin dashboard (ownership, learning fast, problem solving), the college team project where one member stopped contributing (teamwork, conflict, leadership), and the hackathon (pressure, teamwork, result: 2nd place). Add one academic or personal story, such as a failed exam you recovered from, for the failure theme.
How to find your 8–10 stories
- List raw moments (15 minutes). Go through your résumé line by line, your last 12–18 months of commits or tickets, performance reviews, and messages where someone thanked you. Write every moment you remember, however small.
- Look for tension. Good stories have a problem: a bug, a deadline, a disagreement, a mistake, something unclear. Smooth projects make weak stories.
- Pick for variety. Choose 8–10 that together cover the columns in the table. Include at least one failure and one conflict; these are asked almost everywhere.
- Prefer recent and yours. Last 2 years if possible, and stories where you made decisions. Freshers can use college, internships, clubs, part-time jobs or family responsibilities.
- Write STAR bullets. Four lines each. Add one number if you honestly have one.
- Fill the worksheet. Copy the table above with your own stories. Any empty column is a gap to fill before the interview.
Story name: (a short label you will remember, like "webhook bug")
S: where, when, what was wrong T: my responsibility A: 3–4 things I did R: result + number + lesson
Fits: which 2–4 themes Likely follow-ups: "What would you do differently?", "What did others think?"
Reusing one story for several questions
The same story can answer different questions if you change the angle: which part you stretch and what lesson you end on. Story (B), the webhook bug, is a good example:
| Question | Angle to stress |
|---|---|
| "Tell me about a mistake you made." | What went wrong in your code review or testing, and what you changed after. |
| "Tell me about a time you took ownership." | You stepped in without being asked, coordinated refunds, wrote the postmortem. |
| "How do you work under pressure?" | Customers being charged twice, fast triage, clear updates to the team. |
| "Describe a hard technical problem." | Tracing retries, designing idempotency keys, testing the fix. |
Keep the bank in one document you can read in 10 minutes before an interview. Before each interview, pick your "top 5" for that company based on its values, and know which story you will use for failure and conflict.
Using the same story for three questions in one interview. Reuse across interviews is fine; within one interview, the interviewer wants to see range. Also avoid made-up stories: follow-up questions expose them quickly.
4. Tell Me About Yourself
"Tell me about yourself" is usually the first question. It is not asking for your life story or your résumé read aloud. It is asking: "Who are you professionally, and why are you a fit for this role?"
Use a simple order: present (what you do now), past (how you got here, with one or two highlights), future (why this role is the next step). Aim for 60–90 seconds.
Like the first slide of a good presentation: it tells the audience who is speaking, why they should listen, and where the talk is going. It sets up the rest of the conversation.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about yourself." | Can you summarise yourself clearly and confidently? |
| "Walk me through your résumé." | Is there a sensible story behind your moves? |
| "Introduce yourself." | Which parts of your background match this job? |
Template: experienced (60–90 s)
Present: "I'm a ___ developer with about ___ years of experience, currently at ___, where I work on ___ using ___."
Past: "I started out ___. Some work I'm proud of: ___ (result with a number), and ___ (a second highlight showing a different skill)."
Future: "I'm now looking for ___, and this role interests me because ___."
Example (Brightcart developer): "I'm a full-stack developer with about three years' experience at Brightcart, an e-commerce SaaS company. I work across React on the front end and Node and Java Spring services on the back end, with PostgreSQL. I joined as a front-end developer and moved to full-stack in my second year. Two things I'm proud of: I led the checkout performance work that brought load time from 4.2 to 1.6 seconds and lifted conversions by about 6%, and I took over a delayed reporting tool after a teammate left and shipped its core in three weeks. I also mentor our interns. I'm now looking for a role with more ownership of backend systems at larger scale, which is why this team's work on payments interests me."
Template: fresher (60 s)
Past: "I'm a final-year ___ student at ___. I got into programming through ___."
Present: "Recently I ___ (internship or best project), where I built ___ and learned ___. I also ___ (hackathon, team project, competitive coding)."
Future: "I want to start my career in ___, and I'm excited about this role because ___."
Example: "I'm a final-year B.Tech Computer Science student. Over the last year I've focused on web development. In a two-month internship at a startup, I built an admin dashboard in React that the operations team now uses daily, and I learned how real code reviews work. I also led our college team's attendance app and, with three friends, came second in a 24-hour hackathon. I want to start as a software engineer where I can learn from strong engineers and ship real features, and your graduate programme's focus on mentoring is a big reason I applied."
Good vs weak answer
| Weak | Strong |
|---|---|
| Starts with school marks, hometown and hobbies. | Starts with who you are professionally today. |
| Lists every job and technology in order. | Picks 1–2 highlights relevant to this role, with results. |
| Ends with "…so yes, that's me." | Ends with why this role is the logical next step. |
| 3–4 minutes long. | 60–90 seconds, leaving them curious. |
Plant "hooks": mention one or two stories briefly (like the checkout speed-up) so the interviewer asks about them. You then get to tell your best, most prepared stories.
Memorising word for word; it sounds robotic and you freeze if you lose a line. Memorise the three parts and your key numbers, and say it naturally each time. Also avoid personal details (age, marital status, family) unless they are relevant.
5. Communication, Delivery & Virtual Interviews
A good story told badly still scores badly. Delivery is how you say it: order, pace, clarity, confidence. In behavioural rounds, your communication is part of what is being assessed, because you will explain your work to others every day on the job.
Like food in a restaurant: the dish can be excellent, but if it arrives cold and messy on the plate, the diner remembers the mess. Delivery is the plating.
Structure: signpost your answer
- Headline first. Start with one sentence that answers the question: "Yes, the clearest example is when I disagreed with a senior developer about rewriting our orders service."
- Signpost. "There were three things I did…", "The result was…". These words help the listener follow.
- Close the loop. End with a result and one line of learning, then stop. Silence after your answer is fine.
Pace and filler words
- Nervous speakers speed up. Slow down on purpose, especially on numbers and names.
- Fillers ("um", "like", "basically", "actually", "you know") are normal in small amounts. Replace them with a short pause; a pause sounds thoughtful, a filler sounds unsure.
- Record yourself answering two questions on your phone. Listen once. Most people notice one habit to fix, and fixing that one habit helps a lot.
- Avoid heavy jargon with non-technical interviewers (HR, managers from other teams). Explain terms in plain words: "p95 load time, meaning the slowest 5% of page loads".
Thinking time and "I don't know"
| Situation | What to say |
|---|---|
| You need a moment to pick a story | "That's a good question, let me think for a second about the best example." Then take 5–10 seconds. |
| You do not have an exact example | "I haven't faced exactly that, but the closest was…" and tell a related story. Do not invent one. |
| The question is unclear | "Do you mean a disagreement about technical direction, or with a person's behaviour?" |
| You genuinely do not know (a fact, a process) | "I'm not sure. Here is how I would find out…". Honesty scores better than a guess. |
| You lose your thread mid-answer | "Let me step back: the key point is…". Recovering calmly is itself a good signal. |
Virtual interview setup checklist
| Item | Check |
|---|---|
| Internet | Stable connection; mobile hotspot ready as backup; other devices off the Wi-Fi. |
| Device | Laptop charged and plugged in; notifications and other apps closed; meeting app updated and tested. |
| Camera | At eye level (put the laptop on books); face well lit from the front, not a window behind you. |
| Audio | Wired or tested earphones with a mic; quiet room; tell family or flatmates the time. |
| Background | Plain and tidy, or a simple blur. Nothing distracting. |
| Notes | A small sticky note with story names is fine. Do not read from a screen; it shows in your eyes. |
| Timing | Join 5 minutes early; keep the recruiter's phone number handy in case the link fails. |
| Dress | Clean, simple, one level smarter than the company's daily wear. |
Body language
- Eye contact: on video, look at the camera when you make a key point, not at your own image.
- Posture: sit upright, slightly forward; hands visible, calm gestures.
- Face: a natural smile at the start and end; nod when listening.
- In person: a firm handshake if offered, greet everyone on the panel, and do not check your phone while waiting.
- Panel interviews: answer the person who asked, but glance at the others too.
Do one full mock interview on the same app, at the same desk, at the same time of day as the real one. It removes most technical surprises and a lot of nerves.
Talking non-stop to fill silence, interrupting the interviewer, or answering a question different from the one asked. If you are unsure what they want, ask a short clarifying question first.
6. Teamwork & Collaboration
Teamwork questions check whether people will enjoy and benefit from working with you. Can you share work, communicate, help others, and put the team's goal above your own credit?
Like a cricket team: a batter who scores a century but runs out three partners is not a good team player. Interviewers look for someone who makes the whole side stronger.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about working in a team." | What role you naturally take, and whether you share credit. |
| "How do you work with other teams?" | Can you coordinate across functions: design, QA, product, backend? |
| "A teammate is not pulling their weight…" | Do you address it directly and kindly, or complain and do it yourself silently? |
| "Have you helped a colleague?" | Generosity with time and knowledge, without being asked. |
Common questions in this area
- Tell me about a time you worked well in a team.
- Describe a project where you had to collaborate with another team.
- Tell me about a time a teammate was not contributing. What did you do?
- How have you helped a teammate who was struggling?
- Describe a time you had to rely on someone else to finish your work.
- What role do you usually play in a team?
- Tell me about a time you worked with someone very different from you.
- Describe a time you had to share credit, or give credit to someone else.
How to answer
Use STAR, and make the other people visible in your actions: who you spoke to, how you divided work, how you kept everyone informed.
S: "On ___, our team of ___ needed to ___."
T: "My part was ___, but the work depended on ___."
A: "I ___ (set up a way to coordinate), ___ (helped or unblocked someone), ___ (communicated progress or a risk)."
R: "We ___ (outcome). What I took away about working in teams: ___."
Best stories from the bank: (A) checkout speed, which needed the backend team to merge API calls; (D) taking over the reporting tool with the PM; (E) mentoring interns. Fresher: the college attendance app, where one member stopped contributing, or the hackathon.
Good vs weak answer
"In our college project one person did nothing, so I just did his part as well. We still submitted on time and got good marks. I'm the kind of person who gets things done."
"In our four-person attendance app, one teammate stopped committing code in week three. I messaged him privately and learned he was struggling with the backend and too embarrassed to say. I paired with him for two evenings on the API setup and we split his remaining work into smaller tasks on our board so progress was visible. He finished the reports module, we submitted on time, and I learned to check in early instead of assuming someone is lazy."
Name people's roles ("our QA engineer", "the PM") and show at least one moment where you helped someone else succeed. End with a team result, then your personal lesson.
Stories where you are the hero and everyone else is weak. Also avoid blaming a teammate by name or calling them lazy; interviewers imagine you describing them the same way one day.
7. Conflict & Disagreement
Conflict questions check whether you can disagree without damage: raise a concern, listen, use evidence, reach a decision, and still work well together afterwards. They are asked in almost every behavioural round.
A story with no conflict is a weak answer. So is a story where you "won" and the other person looks foolish. The ideal story shows respect on both sides and a decision based on facts.
Like two doctors disagreeing about a treatment. They do not shout; they look at the test results together, maybe order one more test, and agree on what is best for the patient.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about a disagreement with a colleague." | Do you stay calm and use facts rather than rank or emotion? |
| "…with your manager?" | Can you push back respectfully, and accept a decision you lost? |
| "…with a difficult person?" | Empathy: do you try to understand why they behave that way? |
| "What happened afterwards?" | Is the relationship still healthy? Did you commit to the final decision? |
Common questions in this area
- Tell me about a time you disagreed with a teammate.
- Describe a disagreement with your manager. How did it end?
- Tell me about a time you had to work with a difficult person.
- Have you ever pushed back on a requirement or deadline?
- Describe a time you were wrong in a disagreement.
- Tell me about a time you disagreed but went along with the decision.
- How do you handle a code review comment you disagree with?
- Describe a conflict between two other people that you helped resolve.
How to answer
S/T: "___ and I disagreed about ___. It mattered because ___."
A: "First I asked about their reasons and learned ___. I explained mine: ___. We agreed the shared goal was ___. To decide, I suggested ___ (data, a spike, asking a third person)."
R: "We chose ___. The result was ___. Our working relationship ___. I learned ___."
Best stories from the bank: (C) rewrite vs refactor with a senior developer, which is the main conflict story; (H) pushing back on the PM who wanted to skip tests before the sale weekend, for "pushback" and manager-type questions. Fresher: the college project member who stopped contributing, or a disagreement over the hackathon idea.
Good vs weak answer
| Weak | Strong (story C) |
|---|---|
| "A senior dev wanted to rewrite the whole orders service, which was a bad idea. I told him it was risky and eventually the manager agreed with me." | "A senior developer wanted to rewrite our orders service; I felt an incremental refactor was safer. I asked what pain he was seeing, and he was right that the code was hard to change. We agreed the goal was faster changes without risking orders. I proposed a two-day spike: he sketched the rewrite, I refactored one module. The refactor showed most of the gain with far less risk, so we chose it, and he led the design of the new module boundaries. We still pair regularly." |
| Other person looks foolish; manager "picked a winner". | Both sides respected; evidence decided; relationship improved. |
Show that you considered you might be wrong. It is even stronger to have one story where the other person's idea won and you committed fully: "I disagreed, we went with her approach, and I made sure it succeeded."
"I don't really have conflicts, I get along with everyone." It sounds either untrue or conflict-avoidant. Also avoid stories about personal dislikes, gossip, or escalating to a manager as your first move.
8. Leadership & Ownership
Ownership means treating a problem as yours until it is solved, even when it is not strictly your job. Leadership for engineers rarely means having a title; it means influencing people and direction without authority: proposing a plan, mentoring, taking charge in a crisis.
Freshers are not expected to have managed people. They are expected to show initiative: taking a lead in a project, a club, or a hackathon.
Like a flatmate who notices the water tank is leaking. A tenant says "not my problem, tell the landlord". An owner puts a bucket under it, calls the plumber, and tells everyone which tap to avoid.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about a time you took ownership." | Do you step in when something falls between the cracks? |
| "Tell me about a time you led without authority." | Can you persuade peers with clarity and evidence? |
| "Describe going beyond your role." | Initiative, and judgement about when it is worth it. |
| "Have you mentored anyone?" | Patience, and whether you grow other people. |
| "What happened after it shipped?" | Do you follow through: monitoring, docs, follow-up fixes? |
Common questions in this area
- Tell me about a time you took ownership of a problem that was not yours.
- Describe a time you led a project or initiative.
- Tell me about a time you influenced a decision without formal authority.
- Describe a time you took over someone else's work mid-way.
- Have you mentored or trained someone? How did it go?
- Tell me about a time you had to make a decision with incomplete information.
- Describe a time you went beyond what was asked.
- Tell me about something you owned end to end, from idea to production.
How to answer
S: "___ was at risk because ___, and nobody clearly owned it."
T: "I decided to take it on because ___ (impact on users or the team)."
A: "I ___ (got clarity: scope, owners, deadline), ___ (made a plan and shared it), ___ (did the hard part myself or brought in the right people), ___ (followed through after launch)."
R: "___ (outcome with a number). Afterwards I ___ (doc, process, handover) so it would not depend on me."
Best stories from the bank: (D) took over the delayed reporting tool, re-scoped with the PM, shipped the core in 3 weeks: the main ownership story; (B) owned the webhook bug fix, refunds and postmortem; (E) mentoring two interns: the main leadership story; (A) led the checkout performance work. Fresher: leading the college attendance app, or the internship dashboard you owned end to end.
Good vs weak answer
"When my teammate left, I was given his reporting project. I worked extra hours every day and finished it. I always give 100%."
"When a teammate left, our internal reporting tool was already four weeks late and had no clear scope. I read his code and open tickets for two days, then met the PM and listed the 12 requested features by how often finance used them. We agreed to ship the top four first. I set a weekly demo so stakeholders saw progress, and asked a colleague to review the data queries because that was the riskiest part. We shipped the core in three weeks and the finance team stopped building the reports by hand. I also wrote a short handover doc so nobody would be stuck the way I was."
Show judgement, not just effort: how you decided what mattered, who you involved, and how you made the outcome last beyond you (docs, tests, process).
Equating ownership with long hours or doing everything alone. Also avoid taking over someone's work without telling them or your manager; that reads as poor collaboration, not leadership.
9. Failure, Mistakes & Learning
Everyone who ships software breaks something sooner or later. When an interviewer asks about a failure, they are not hunting for a perfect person. They want to know what you do after things go wrong: do you hide, blame, or own it and fix it?
The best failure answers are honest, show a real cost, and end with a change you still follow today.
Think of a good doctor who once gave the wrong dose. You do not trust the doctor who says "that never happens to me". You trust the one who says "it happened once, I caught it, told the patient, and now I double-check every chart".
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about a time you failed." | Self-awareness. Can you name a real failure without shrinking it to nothing? |
| "What was your role in it?" | Ownership. You say "I", not "the team" or "the PM". |
| "What did you do next?" | Calm action under stress: contain the damage first, then fix the cause. |
| "What would you do differently?" | Learning. A specific habit or process change, not "I learned to be careful". |
| "Has it happened again?" | Proof the lesson stuck. Ideally a later moment where the new habit helped. |
Common questions in this area
- Tell me about a time you failed.
- Describe a mistake you made at work and how you handled it.
- Tell me about a bug you shipped to production.
- When did you miss a deadline or an estimate?
- What is a decision you regret?
- Tell me about a project that did not go as planned.
- Describe a time you received criticism you agreed with.
- What is the biggest lesson you have learned in your career so far?
How to answer
Use STAR, but give the Result two parts: what happened to the problem, and what changed in you or the process. A good split is about 20% on the mistake, 50% on what you did, 30% on the lesson and proof.
S/T: "On [project], I was responsible for [your part]."
The mistake: "I [what you did or missed]. The impact was [users, money, time]."
A: "First I [contained it: rollback, told the lead]. Then I [fixed the cause]. I also [told people affected / wrote a postmortem]."
R: "[Outcome]. Since then I always [specific habit]. For example, on [later project] that caught [problem]."
Which story fits: story (B), the payment-webhook bug that double-charged 38 customers, is the best choice: real impact, clear ownership, and a lasting fix (idempotency keys and a postmortem). Story (F), the search estimate that took 3 sprints instead of 1, is a good second choice for "missed deadline" questions. A fresher can use the college team project that fell behind, or a hackathon feature they had to drop.
Good vs weak answer
| Weak answer | Strong answer |
|---|---|
| "We had a bug in the payment system once. QA should have caught it, but it slipped through. We fixed it quickly and everything was fine. I learned that testing is important." | "I shipped a webhook handler that did not check for duplicate events. When the payment provider retried, 38 customers were charged twice. I owned it: I disabled the retry path within the hour, worked with support to refund everyone the same day, and wrote the postmortem. The root cause was a missing idempotency check, so I added idempotency keys to every payment webhook. Now any handler that moves money needs a duplicate-event test before review. Two months later that test caught the same issue in the refunds flow." |
The weak answer blames QA, has no numbers, and the lesson is too vague to believe. The strong one names the cost, shows fast action, and ends with a rule that proved itself later.
Pick a real failure with a real cost. Say "I" for the mistake. Show you contained the damage before fixing the root cause. End with a specific habit and, if you can, a later moment where it helped.
A fake failure ("I worked too hard"), blaming others, a disaster so big it scares the interviewer (a data breach you caused and hid), or a story with no lesson. Do not pick something from so long ago that it says nothing about you now.
10. Pressure, Deadlines & Prioritisation
Software work always has more to do than time to do it. These questions check whether you stay calm, decide what matters most, and tell people early when something will not fit.
The interviewer is not impressed by "I worked all night". They are impressed by "I cut the scope in a smart way and told the PM on day two, not on the last day".
It is like packing for a flight with a 7 kg bag limit. You cannot take everything. The skill is choosing what goes in, what gets shipped later, and not arguing with the scale at the airport.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "How do you handle tight deadlines?" | A method, not a mood. How you break work down and decide order. |
| "What did you drop or delay?" | That you can say no, or "not now", with a reason. |
| "Who did you tell, and when?" | Early, honest communication with the PM or lead. |
| "How did you keep quality up?" | You did not quietly skip tests or reviews to hit a date. |
| "How do you handle stress?" | Healthy habits. Pressure is normal; panic and burnout are not a plan. |
Common questions in this area
- Tell me about a time you worked under a tight deadline.
- How do you prioritise when everything is urgent?
- Describe a time you had to juggle several projects at once.
- Tell me about a time you could not meet a deadline. What did you do?
- Have you ever had to push back on a deadline or a request?
- How do you handle stress or pressure at work?
- Tell me about a time priorities changed suddenly.
- Describe a time you had to cut scope to ship.
How to answer
STAR works well. In the Action, show three moves in this order: list and rank, talk early, protect quality.
S/T: "We had [time] to deliver [thing] because [reason for the deadline]."
A: "I listed [the tasks] and ranked them by [user impact / risk]. On day [N] I told [PM/lead] that [X] would not fit, and proposed [smaller scope]. I kept [tests/reviews] for the risky parts and moved [Y] to the next sprint."
R: "We shipped [core] on time. [Metric]. [Y] followed [when]."
Which story fits: story (H), pushing back on skipping tests before the sale weekend, shows pressure handled with a safe smaller scope. Story (D), taking over the delayed reporting tool and shipping the core in 3 weeks after re-scoping, is ideal for "behind schedule" questions. Freshers can use the 24-hour hackathon: what the team cut to finish and still come 2nd.
Good vs weak answer
"I am very good under pressure. When we had the sale deadline, I just worked late every night for two weeks and got everything done. I actually enjoy the adrenaline."
"Five days before our biggest sale, the PM asked for a new discount feature and suggested we skip tests to save time. I listed the work and saw the risky part was the price calculation. I proposed shipping only percentage discounts, fully tested, and moving bundle offers to after the sale. The PM agreed. We shipped on time, had zero pricing incidents over the weekend, and bundles went out the next sprint."
The weak answer relies on overtime and tells the interviewer you may burn out. The strong answer shows judgement, a trade-off, and early communication.
Name what you ranked and why. Say when you raised the risk (early). Show one thing you deliberately cut or delayed. Mention how you kept quality for the risky part.
Hero stories built on all-nighters, "I never feel stress", quietly missing a date and telling people at the end, or cutting tests and calling it speed.
11. Problem Solving & Initiative
These questions look for two things. Problem solving: when something is broken or unclear, can you break it down, find the real cause, and fix it? Initiative: do you act on problems nobody assigned to you, or wait to be told?
Your answer should show your thinking steps, not just the final fix. The interviewer is judging how you would behave on their messy, real problems.
A good mechanic does not just replace parts until the noise stops. They listen, test one thing at a time, find the loose bolt, and then tell you how to stop it happening again. Initiative is the mechanic who also mentions your worn tyres without being asked.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about a hard problem you solved." | A clear method: measure, guess, test, confirm. Not luck. |
| "How did you find the root cause?" | Data and tools (logs, profiler, metrics), not guesswork. |
| "What options did you consider?" | You compared choices and picked one for a reason. |
| "Did anyone ask you to do this?" | Initiative. You spotted it and acted within sensible limits. |
| "What was the impact?" | A result you measured: time saved, errors cut, money earned. |
Common questions in this area
- Tell me about the most difficult technical problem you have solved.
- Describe a time you went beyond your job description.
- Tell me about a time you improved a process without being asked.
- How do you approach a problem you have never seen before?
- Describe a time you had to make a decision with incomplete information.
- Tell me about a creative or unusual solution you came up with.
- Tell me about a time you simplified something complex.
- Describe a time you debugged a tricky production issue.
How to answer
Use STAR, and inside the Action walk through a mini problem-solving loop. Keep the technical depth to what a non-specialist can follow, then go deeper if they ask.
S/T: "I noticed [problem] was hurting [users/team] — [number]. It was [not assigned to anyone / assigned to me]."
A: "I measured [how]. My first guess was [X], but [data] ruled it out. The real cause was [Y]. I considered [option 1] and [option 2] and chose [one] because [reason]."
R: "[Before → after number]. I also [documented it / added a check] so it does not come back."
Which story fits: story (A), the checkout speed project (p95 load from 4.2 s to 1.6 s, conversions up about 6%), is a textbook problem-solving story with clear before/after numbers. Story (I), building a validation report for a B2B client's failing bulk imports, shows initiative beyond the ticket. Story (G) also works for "unfamiliar problem". Freshers can use the internship admin dashboard: a slow table they fixed, or a feature they suggested.
Good vs weak answer
| Weak answer | Strong answer |
|---|---|
| "Our checkout page was slow, so I optimised it. I used lazy loading and some caching and it became much faster. The team was happy." | "Checkout had a p95 load of 4.2 seconds and we were losing buyers. I profiled it and found two causes: a 900 KB JavaScript bundle and three API calls made one after another. I tested code-splitting first because it was cheapest, then combined the API calls into one endpoint. p95 dropped to 1.6 seconds and conversions rose about 6%. I added a bundle-size check to CI so it cannot quietly grow again." |
Show the steps of your thinking, including a guess that turned out wrong. Give before-and-after numbers. For initiative, say how you got buy-in (a quick chat with the lead) so it is clear you did not go rogue.
Jargon floods that hide your reasoning, "I just tried things until it worked", taking credit for a team fix, or initiative that ignored your manager and broke a process.
12. Adaptability & Learning Fast
Tech stacks, teams, managers and priorities change all the time. These questions test whether you adjust calmly and can pick up something new quickly without waiting for a perfect course.
The answer they love has a clear learning plan: what you needed to know, how you learned just enough, and the real result it unlocked.
Like moving to a new city. You do not memorise the whole map first. You learn the route to work, the nearest shop and the bus number, and you explore the rest as you go.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about learning something new quickly." | A method: goal first, just-enough learning, practice on the real task. |
| "How did you handle a sudden change?" | Calm reaction, fast re-planning, no drama or complaining. |
| "What was hard about it?" | Honesty. You admit what confused you and how you got unstuck. |
| "Who did you ask?" | You use people and docs well, and do not suffer in silence for days. |
| "How do you keep up with technology?" | Steady curiosity, not hype-chasing. |
Common questions in this area
- Tell me about a time you had to learn a new technology quickly.
- Describe a time priorities or requirements changed mid-project.
- How do you handle change you did not agree with?
- Tell me about working outside your comfort zone.
- Describe a time you joined a team or codebase you knew nothing about.
- How do you keep your skills up to date?
- Tell me about a time your manager or team changed suddenly.
- What is something you have taught yourself recently?
How to answer
Use STAR, and make the Action a short learning plan. Interviewers like hearing the scope you chose: "I did not need all of X, only these three parts."
S/T: "We needed [change/new tool] by [time], and I had [no / little] experience with it."
A: "I decided I only needed [the key parts]. I spent [time] on [docs/course], paired with [person] for [task], and practised on [safe environment]. When I got stuck on [thing], I [how you got unstuck]."
R: "[What it unlocked, with timing]. I wrote [notes/runbook] so the next person ramps up faster."
Which story fits: story (G), learning Kubernetes basics in two weeks to unblock the deployment migration, is the clear choice. Story (D), taking over the reporting tool mid-project, fits "sudden change" questions. Freshers can use the internship: picking up React for the admin dashboard, or switching tech mid-way through the college project.
Good vs weak answer
"I am a fast learner. I learned Kubernetes very quickly when we needed it. I watched a lot of tutorials and it was fine."
"Our deployment migration to Kubernetes was blocked because the one engineer who knew it was on leave. I had two weeks. I scoped it to what we needed: Deployments, Services, ConfigMaps and reading pod logs. I worked through the official tutorial on a local cluster, then paired with a platform engineer for an hour to review my manifests. The first rollout failed on a missing health check, which taught me more than any video. We migrated three services on schedule, and my notes became the team's starter guide."
Show a narrow, smart learning scope, a moment you got stuck and how you recovered, and a result the business cared about. For "change you disagreed with", show you raised your view once, then committed fully.
Just saying "I am a fast learner" with no proof, listing ten technologies you "learned in a weekend", or complaining about the change or the people who made it.
13. Giving & Receiving Feedback
Teams grow through honest feedback. These questions test two sides: can you hear criticism without getting defensive, and can you give it kindly and clearly so the other person can act on it?
A simple tool for giving feedback is SBI: describe the Situation, the Behaviour you saw, and its Impact. It keeps feedback about facts, not about the person.
Good feedback is like a GPS saying "in 200 metres you missed the turn; take the next left". It does not say "you are a bad driver". It says where, what, and what to do next.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about critical feedback you received." | You listened, did not argue, and changed something visible. |
| "How did you feel about it?" | Honest emotions handled maturely: "it stung, then I saw the point". |
| "Tell me about giving tough feedback." | Courage plus kindness. Private, specific, focused on behaviour. |
| "What happened afterwards?" | Follow-up. Feedback is a conversation, not a one-time verdict. |
| "How do you ask for feedback?" | You seek it out; you do not wait for the yearly review. |
Common questions in this area
- Tell me about a time you received critical feedback.
- Describe feedback that changed how you work.
- Tell me about a time you gave difficult feedback to a peer.
- Have you ever given feedback to someone senior to you?
- Tell me about a time you disagreed with feedback you got.
- How do you ask for feedback?
- How would your manager describe you? What would they say you should improve?
- Tell me about helping someone improve.
How to answer
Receiving: STAR where the Action is "listen → ask questions → try the change → check back". Giving: STAR where the Action is "prepare → private conversation using SBI → listen → agree next step → follow up".
"[Person] told me that [specific feedback]. Honestly, my first reaction was [feeling], but I asked [a question to understand]. I realised [the point]. I started [specific change]. [Time] later, [evidence it worked, or they noticed]."
"I noticed [pattern] was affecting [impact]. I asked [person] for a private chat. I said: in [situation], [behaviour], and the effect was [impact]. Then I asked [open question]. We agreed [next step], and I [followed up / supported by]. Result: [change]."
Which story fits: story (E), mentoring an intern who struggled with code reviews, is ideal for giving feedback. For receiving, the postmortem in story (B) or the estimate lesson in story (F) both include feedback from a lead. Freshers can use the college project where one member stopped contributing (giving), or review comments from their internship mentor (receiving).
Good vs weak answer
| Weak answer | Strong answer |
|---|---|
| "One intern was careless with code reviews, so I told him he needed to be more serious. After that he improved." | "One of my interns kept opening large PRs with no description, and reviews took days. I asked him for a quick one-to-one and said: in last week's cart PR, there was no description and 1,200 changed lines, so reviewers could not tell what to check and it waited four days. I asked what made it hard. He said he did not know what reviewers wanted. We agreed on a short PR template and a 400-line soft limit. I reviewed his next two PRs the same day. Within a month his PRs were merging in under a day." |
For receiving, admit the sting, then show the change and its result. For giving, use SBI, keep it private, ask for their side, and follow up. Show you ask for feedback regularly.
"I have never had negative feedback", defending yourself in the story, feedback about personality ("he was lazy"), or giving feedback in public. Never make the other person the villain.
14. Customer Focus & Impact
Code exists to help someone: a shopper, a business client, a support agent, or another team. These questions check whether you think about the person using what you build, and whether you can explain your work in terms of its effect on them.
"Customer" can be external (paying users) or internal (the teams that use your API or tool). Both count.
A good chef tastes the dish before it leaves the kitchen and watches whether plates come back half-eaten. A cook who only follows the recipe card never finds out the food is too salty.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about going the extra mile for a customer." | You cared about their outcome, not just closing the ticket. |
| "How did you know what they needed?" | You listened, looked at data, or talked to them directly. |
| "What was the impact of your work?" | You measure and speak in outcomes: time, money, errors, happiness. |
| "When did you say no to a customer?" | Balance. You protect the long term, and offer another path. |
| "How did you handle an angry customer?" | Calm, empathy first, then action and follow-through. |
Common questions in this area
- Tell me about a time you went above and beyond for a customer or user.
- Describe a time you dealt with an unhappy customer or stakeholder.
- How do you make sure you understand what users need?
- Tell me about a time you used customer feedback to change a product.
- Which project had the biggest impact, and how did you measure it?
- Tell me about a time you had to balance customer wants with technical limits.
- Describe a time you said no to a customer request.
- Who are the customers of your current work?
How to answer
Use STAR, but open with who the customer was and what pain they had, and close with impact on them, ideally a number.
S: "[Customer] was facing [pain], which cost them [impact]."
T: "My job was [task], but the real need was [deeper need]."
A: "I [talked to them / looked at data] and found [insight]. I built [solution] and [kept them updated]."
R: "[Their result]. [Follow-up: tickets down, renewal, product change]."
Which story fits: story (I), joining a call with a B2B client whose bulk imports kept failing and building a validation report, is the best customer story. Story (A), the faster checkout with about 6% more conversions, is the best "impact" story. Freshers can use the internship admin dashboard (who used it, what it saved them) or the college attendance app (feedback from classmates or teachers).
Good vs weak answer
"A client complained that imports were failing. I checked the logs, found some rows had bad data, and told support to ask them to fix their file. Ticket closed."
"A B2B client's bulk imports kept failing and their team was re-uploading files for hours. I joined a call with them and support, and saw the problem: our error said only 'import failed'. The real issues were date formats and missing SKUs, spread across thousands of rows. I built a validation report that listed every bad row with the reason and a fix. Their next import went through on the second try, and we made the report available to all clients. Import-related support tickets dropped noticeably over the next month."
The weak answer solves the ticket. The strong one solves the customer's problem and then the problem for every customer.
Name the customer and their pain in the first sentence. Show how you found out what they needed. End with a result on their side, and mention if the fix helped others too.
Stories where you never learned who used your work, "the customer is always right" (building anything they ask), blaming the customer, or impact claims you cannot explain if asked "how did you measure that?".
15. Ethics & Integrity
These questions test whether you can be trusted with code, data, money and credit when nobody is watching. They include pressure to cut corners, spotting something wrong, and owning up to mistakes.
A good answer shows you notice the issue, raise it through the right channel, and stay respectful. You are not a lone hero; you are a professional who does the right thing calmly.
Like a cashier who finds the till is ₹500 over at the end of the day. The honest move is not to pocket it, and not to shout that someone is stealing. It is to report it to the manager and let the numbers be checked.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Were you ever asked to cut corners?" | You protect users and quality, and offer a safer path instead of just refusing. |
| "What if you saw a colleague do something wrong?" | Judgement: talk to them first if it is small, escalate if it is serious. |
| "Tell me about a time you made a mistake no one noticed." | You own up anyway. |
| "How do you handle user data?" | Respect for privacy and security rules by default. |
| "Did you ever take credit…?" | You give credit fairly and share wins. |
Common questions in this area
- Tell me about a time you were asked to do something you felt was wrong.
- Describe a time you had to choose between a deadline and doing the right thing.
- What would you do if you saw a teammate copying code with a restrictive licence, or sharing customer data?
- Tell me about a mistake you made that no one else noticed.
- Have you ever disagreed with a company decision on principle?
- How do you handle confidential information?
- Tell me about a time you had to deliver bad news.
- What would you do if your manager asked you to hide a bug from a client?
How to answer
For past-behaviour questions, use STAR. For "what would you do" questions, use a simple judgement ladder and say it out loud.
S/T: "[Person] asked us to [shortcut] because [pressure]."
A: "I was worried about [risk to users/data/company]. I explained that to [person] privately and suggested [safer option]. [If needed: I raised it with (lead/security).]"
R: "[Outcome]. The relationship stayed [good], and [process changed / risk avoided]."
Which story fits: story (H), pushing back when the PM wanted to skip tests before the sale weekend, is a good example of protecting users without being dramatic. Story (B) shows integrity after a mistake: owning the double-charge, refunding every customer, and writing an honest postmortem. Freshers can talk about a group project where someone suggested copying another team's code, or reporting a bug in their own internship work that nobody had spotted.
Good vs weak answer
| Weak answer | Strong answer |
|---|---|
| "I would never do anything unethical. If my manager asked me to hide a bug, I would refuse and report them to HR immediately." | "First I would make sure I understood the request; sometimes 'don't mention it yet' means 'we are still confirming the impact'. If the bug affects the client's data or money, I would say to my manager privately that I am not comfortable hiding it, and suggest we tell the client what we know, with a fix date. If they still insisted, I would take it to their manager or the relevant team. I would keep a short written note of the facts." |
Show calm steps: facts, private conversation, safer alternative, escalate only if needed. Keep the other person's dignity. Show that integrity includes admitting your own mistakes.
Moral speeches, instant escalation for small things, stories that make a past employer look dishonest in detail, or sharing confidential details of your current company to make your story vivid.
16. Why This Company, Why This Role
This question checks two things: did you do your homework, and is there a real fit between what they do and what you bring? A generic answer ("great culture, good growth") tells them you would say the same thing to every company.
The fix is simple: research a few specific things, then connect their thing to your evidence and to what you will add.
It is like a wedding toast. "She is a lovely person" could be about anyone. "She once drove four hours to bring me soup when I had fever" proves you actually know her.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Why do you want to work here?" | Specific knowledge of the product, business or engineering work. |
| "Why this role?" | The role matches your skills and your direction, not just "any job". |
| "Why are you leaving your current job?" | A pull towards them, not only a push away from your current employer. |
| "What do you know about us?" | You spent real time on research. |
| "Where else are you interviewing?" | Honesty and a clear reason this company stands out. |
Research checklist (30–45 minutes before every interview)
| Look at | What to note | Where to find it |
|---|---|---|
| The product | Use it yourself. Who is the customer? One thing you liked, one thing you would improve. | Sign up, free trial, app store, product demo videos |
| Recent news | A launch, funding round, expansion or big customer in the last 6–12 months. | Company blog, press page, news search, LinkedIn posts |
| Engineering blog / talks | One technical problem they wrote about, and the tools they use. | Engineering blog, conference talks, GitHub, job description stack |
| Values | Their stated values or principles; pick one or two that match a story of yours. | Careers page, "about us", culture docs |
| The team | What this team owns, who you will meet, their background. | Job description, recruiter call, interviewer LinkedIn profiles |
Common questions in this area
- Why do you want to join us?
- Why this role, and not a different one?
- What do you know about our company or product?
- Why are you leaving your current company?
- Why should we hire you?
- What excites you about this team?
- Would you choose us over a bigger or better-paying company?
- (Fresher) Why do you want to work at a product company / service company?
How to answer
Pick one or two reasons. Build each with the formula: their thing + my evidence + what I'll add. End with a short line about the role itself.
"I have been following [their thing: product / blog post / launch]. It connects to what I did at [place]: [short evidence with a number]. I would like to bring [skill] to [their team/problem], and I want to grow in [area], which this role offers because [reason from JD]."
Which story fits: choose the story closest to their business. For an e-commerce or payments company, use story (A) (checkout speed) or (B) (payments reliability). For a developer-tools or platform company, story (G) (Kubernetes migration). For a B2B SaaS company, story (I) (client imports). Freshers use the internship or hackathon project that is closest to the company's product.
"Why are you leaving?" Keep it positive and forward-looking: "I have learned a lot at Brightcart, especially on performance and payments. I am now looking for bigger scale and a team where [their thing] is the core problem." Never criticise your current manager or company.
Good vs weak answer
| Weak answer | Strong answer |
|---|---|
| "You are a big, well-known company with a great culture and good work-life balance. I think I will get a lot of learning and growth here." | "Two things. First, your checkout handles huge spikes during sale events, and I read your engineering post on how you cache pricing. At Brightcart I cut our checkout p95 from 4.2 to 1.6 seconds, so I know how much speed matters for conversions, and I want to do that at much larger scale. Second, the role is full-stack with ownership of a customer-facing flow, which is exactly the work I enjoy most." |
Use the product before the interview. Mention one specific thing you read or used. Link it to a real story with a number. Say what you want to learn, too; it shows you plan to stay and grow.
"Good brand, good salary, good culture" with nothing specific, reading their "about us" page back to them, only talking about what you will get, or badmouthing your current employer.
17. Strengths & Weaknesses
This classic HR question checks self-awareness. For strengths: can you name something real and prove it? For weaknesses: can you be honest about a genuine gap, and show you are actively working on it?
Interviewers have heard "I am a perfectionist" thousands of times. A real weakness, told with the steps you took, sounds far more confident than a disguised boast.
Like a cricket player's stats. A batter who says "I am great against spin, here are my numbers, and I am working on short-pitched bowling with extra nets every week" sounds like a professional. One who says "my weakness is that I score too many runs" sounds like he is hiding something.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "What are your strengths?" | Two or three strengths that matter for this role, each backed by a story. |
| "What is your greatest weakness?" | Honesty, self-awareness, and a clear improvement plan already under way. |
| "What would your manager say you need to improve?" | That you have listened to real feedback. |
| "How are you working on it?" | Specific steps and some evidence of progress. |
| "Why should we hire you?" | Your strengths matched to their needs, clearly and without arrogance. |
Common questions in this area
- What are your greatest strengths?
- What is your biggest weakness?
- Tell me three words your colleagues would use to describe you.
- What would your manager say you should improve?
- What is one skill you are actively working on?
- What makes you different from other candidates?
- Why should we hire you?
- What do you find hardest about your job?
How to pick real strengths with proof
- List 5–6 candidates from your story bank: what do people come to you for? What did reviews or feedback praise?
- Keep the 2–3 that match the job description. A backend role wants "debugging production issues"; a startup wants "owning things end to end".
- Make each one specific. Not "hard-working" but "I get to the root of performance problems".
- Attach proof: one story with a number, or feedback someone gave you.
"One of my strengths is [specific strength]. For example, [short story with a number]. [Optional: my lead mentioned this in my review.] I think it would help here because [link to the role]."
Example with the profile: "I am good at finding the real cause of performance problems. On our checkout I profiled the page instead of guessing, found an oversized bundle and chained API calls, and took p95 from 4.2 to 1.6 seconds (story (A))." A second strength could be ownership in a crisis, using story (B), or learning fast, using story (G).
How to choose a genuine weakness
A good weakness passes three tests:
| Test | Why it matters | Example |
|---|---|---|
| It is real | Fake weaknesses sound rehearsed and destroy trust. | "I used to give estimates too quickly." |
| It is not a core requirement of the role | Do not tell a frontend team you struggle with CSS, or a client-facing role that you avoid talking to people. | For a developer role: public speaking, estimating, saying no, delegating. |
| You are already fixing it | The steps and progress are the real answer. | "I now break work into tasks and add a buffer, and I check against actuals." |
"Something I have been working on is [weakness]. It showed up when [short example and its cost]. Since then I [step 1] and [step 2]. [Evidence: it has improved to…]. I still [how you keep an eye on it]."
Example with the profile (story (F)): "I used to under-estimate work. I once said a search feature would take one sprint, and it took three, which pushed back a release. Since then I break features into tasks of one day or less before estimating, add a buffer for unknowns, and compare my estimates to actuals each sprint. My estimates are now usually within about 20%, and I flag risk early instead of at the end."
Fresher examples: "I found it hard to speak up in group discussions, so I volunteered to present our college project demo and joined a weekly speaking club." Or "I used to jump into coding before planning; in my internship I started writing a short plan and getting my mentor's review first."
Clichés to avoid
| Cliché | Why it fails | Say instead |
|---|---|---|
| "I'm a perfectionist." | A boast dressed as a weakness; every interviewer has heard it. | "I sometimes spend too long polishing low-impact details. I now time-box them and ask 'does the user notice?'" |
| "I work too hard." | Not believable, and hints at burnout. | A real habit, like estimating or delegating. |
| "I care too much." | Dodges the question. | A concrete behaviour with steps taken. |
| "I don't have any weaknesses." | Shows low self-awareness. | Anything honest and non-core. |
| "I'm impatient with slow people." | A real weakness, but a red flag for teamwork. | Pick one that does not hurt colleagues. |
Good vs weak answer
"My strengths are that I am hard-working, a team player and a fast learner. My weakness is that I am a perfectionist, so I sometimes work too hard on things."
"My main strength is getting to the root of performance problems: I took our checkout from 4.2 to 1.6 seconds by profiling rather than guessing. A weakness I have worked on is estimating. I once promised one sprint for search and it took three. Now I split work into small tasks, add a buffer, and compare estimates with actuals; I am usually within about 20% these days."
Choose 2–3 strengths that match the role and prove each with a story. Choose one real weakness that is not central to the job. Spend most of the weakness answer on the steps you took and the progress so far.
Lists of adjectives with no proof, clichés, weaknesses that are core to the role, or weaknesses that sound like character flaws (dishonesty, laziness, temper). Do not ramble. Each answer should take about a minute.
18. Career Goals
"Where do you see yourself in five years?" is not a request for a prophecy. The interviewer wants to know three things: do you have a direction, does this job fit that direction, and will you stay long enough to be worth the training they give you.
A good answer links your goal to the role in front of you. You want to grow in a way that also helps them.
It is like a cab driver asking "Where to?" before you get in. "Anywhere" is worrying. "Towards the airport, and this road goes there" is exactly what they want to hear.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Where do you see yourself in 5 years?" | A realistic direction that runs through this job, not away from it. |
| "What are your long-term goals?" | Self-awareness: you know what you enjoy and what you want to get better at. |
| "Why this role at this stage of your career?" | The role is a planned next step, not a random application. |
| "Do you plan to do an MBA / MS / start a company?" | Whether you will leave in a year. They are checking flight risk. |
| "Do you want to be a manager or stay technical?" | That you have thought about it; either answer is fine if it is honest and reasoned. |
Common questions in this area
- "Where do you see yourself in five years?"
- "What are your short-term and long-term career goals?"
- "What does success look like for you in this role after one year?"
- "How does this job fit into your career plan?"
- "Are you planning higher studies?" (common for freshers)
- "Individual contributor or management — which path do you want?"
- "What skill do you most want to build in the next two years?"
- "What would make you leave a job?"
How to answer
Use a near – far – link structure. Keep it to about one minute.
Far (3–5 years): the kind of engineer you want to become, described by impact, not by title.
Link: why this company and this role are the right road to get there.
Template to fill in:
"In the next year or two I want to get really strong at [skill the role needs] and own [kind of work] end to end. Over five years I see myself as [senior engineer / tech lead / specialist in X] — someone who [impact: designs systems, mentors people, owns a product area]. This role fits because [specific thing about the team or product], which is exactly where I want to grow."
Which story fits: goals are forward-looking, but one short proof makes them believable. The example profile can point to (E) mentoring two interns ("I enjoyed it, and I want more of it") and (G) learning Kubernetes in two weeks ("I like going deep on infrastructure when the product needs it"). A fresher can point to the internship dashboard or the hackathon.
Sample answer — experienced (example profile)
"For the next year or two I want to go deeper on backend and performance work. At Brightcart I cut checkout load time from 4.2 to 1.6 seconds, and that is the kind of problem I want more of. In five years I see myself as a senior engineer who owns a whole area — design, reliability and mentoring. I already mentor two interns and I enjoy it. Your platform team works at a bigger scale than Brightcart, so it is the right place to build exactly those skills."
Sample answer — fresher
"In my first year I want to become a dependable developer on the team — learn your codebase, your review standards and how you ship to production. During my internship I built a React admin dashboard and realised I enjoy full-stack work most. In three to five years I want to be the person who can take a feature from idea to production on their own and help new joiners do the same. A structured training programme and real projects here are the best start for that."
Handling the tricky versions
- "Are you planning an MBA / MS?" If you are not sure, say so honestly and put the job first: "Not in the near future. My focus for the next few years is to build strong engineering skills." Do not promise something you already plan to break.
- "Manager or technical?" "I want to stay hands-on for the next few years. Later I am open to leading, maybe as a tech lead first, because I enjoyed mentoring." Reasoned and open is the best tone.
- "Do you want to start your own company?" "Maybe one day, but that is far away. Right now I want to learn how good products are built at scale, which is what this role offers."
Good vs weak answer
| Weak | Strong |
|---|---|
| "I see myself in your position." (sounds like a joke or a threat) | "I see myself leading the design of a product area and mentoring newer engineers." |
| "I want to be a manager in two years." (unrealistic, ignores the role) | "I want to own features end to end first; leading comes after I have earned it." |
| "I haven't really thought about it." | A clear near and far goal, even if modest. |
| "I plan to do an MS abroad next year." (they now expect you to leave) | An honest answer that shows commitment to the next few years. |
| Goals that have nothing to do with the job (data science goals for a testing role) | Goals that run through the role you are applying for. |
Describe your goal in terms of skills and impact, not titles. Link it to something specific about this team. Keep it realistic for your experience. Back it with one small proof from your past.
Saying you want the interviewer's job, naming a job at a different company, a goal that clearly means leaving soon, or a vague "I want to grow". Do not over-promise ("I will stay here forever"); it sounds rehearsed.
19. Salary, Notice Period & Negotiation
Salary talk makes most people nervous, but it is a normal business conversation. The company wants to hire you within its budget. You want a fair offer. Both sides do better when you know the market rate and speak calmly about it.
Two words you will hear a lot in India: CTC (cost to company — everything the company spends on you in a year, including fixed pay, variable pay, bonuses and employer PF) and in-hand (what actually reaches your bank account each month). They are very different numbers, so always ask which one is being discussed.
It is like selling a used bike. If you check the market price first, you can name a fair number with confidence. If you guess, you either scare the buyer or undersell yourself.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "What is your current CTC?" | A baseline for their offer. Also honesty — this is checked later. |
| "What is your expected CTC?" | Whether you fit their band, and whether your expectation is based on reason or on a guess. |
| "What is your notice period?" | When you can actually join, and whether they must plan for a delay. |
| "Can you join earlier? Is buyout possible?" | How flexible you are, and whether you understand your own company's policy. |
| "Do you have other offers?" | How urgent it is to close you, and whether you are using them only as leverage. |
Common questions in this area
- "What is your current CTC, and what is the fixed / variable split?"
- "What are your salary expectations?"
- "This is the top of our band. Can you accept it?"
- "What is your notice period? Is it negotiable?"
- "Are you currently serving notice? What is your last working day?"
- "If we make an offer, will you join? Do you have any other offers in hand?"
- "Would you be open to a lower fixed with a higher joining bonus?"
- For freshers: "Are you okay with the package and the location offered?"
Step 1 — Research the range
- Salary sites: Glassdoor, AmbitionBox and Levels.fyi show reported pay by company, role and experience. Look at several and take the middle, not the highest entry.
- People: ask seniors, alumni and friends at similar companies. Ask "what is the range for 3 years' experience?" rather than "what do you earn?".
- Recruiters: a recruiter who calls you often shares the band if you ask directly: "What is the budget for this role?"
- Know your own numbers: current fixed, variable, bonus, stock, and your in-hand. Know what your total would be if you stayed another year (appraisal, pending bonus, unvested stock).
Step 2 — When to say a number
If asked very early (first screening call), you can politely defer: "I would like to understand the role and the responsibilities first. I am sure we can agree on something fair if it is the right fit." If they insist, or the form has a mandatory field, give your researched range. Many Indian companies ask for current and expected CTC on the first call, and refusing entirely can look evasive, so do not stonewall.
Step 3 — Give a range anchored on research
"Based on what I have seen for [role] with [X years] in [city], and the scope of this role, I am looking at [low] to [high] CTC, with most of it fixed. I am flexible on the structure if the overall package is right."
Make the bottom of your range a number you would genuinely be happy with, because companies often offer near the bottom. Base it on market data and the role, not only on "current CTC plus a percentage".
Step 4 — Negotiate politely
- Thank them first and show you want to join: "Thank you, I am really excited about this role."
- Ask one clear question: "Is there any flexibility on the fixed component? Based on my research and my experience with (A) the checkout performance work, I was expecting closer to [number]."
- If the fixed cannot move, ask about other parts: joining bonus, notice buyout, stock, relocation support, an early salary review.
- Only mention another offer if it is real, and state it plainly without threats.
- Once you agree, stop negotiating. Accept graciously.
Notice period and buyout (India context)
| Situation | What to say |
|---|---|
| 30-day notice | "My notice period is 30 days. I can join on [date] after resigning." |
| 60 or 90-day notice | "My official notice is 90 days. I will request an early release once I have the offer, and I have seen colleagues released in about [X] days. If needed, I can discuss a buyout." |
| Buyout | Buyout means paying your current employer for the unserved notice days (by you, or by the new company if they agree to reimburse it). Ask: "Would you support a notice buyout?" Do not assume it. |
| Already serving notice | "I have resigned and my last working day is [date]." Be ready to explain why you resigned without an offer, calmly. |
| Fresher | "I can join immediately after my final exams, from [month]." Know your college's rules about accepting multiple offers. |
Good vs weak answer
| Weak | Strong |
|---|---|
| "Whatever you think is fair." (gives away all control) | "Based on my research, [low] to [high], mostly fixed. I am flexible on the structure." |
| "I need a 100% hike, otherwise I am not interested." (no reason, a threat) | "For this scope and the market range for my experience, I was expecting closer to [number]. Is there flexibility?" |
| Inflating current CTC by counting unpaid bonuses as fixed | "My current CTC is [X]: [Y] fixed and [Z] variable." |
| "I can join tomorrow" when your notice is 90 days | "Official notice is 90 days; I will request early release and can discuss buyout." |
| Accepting verbally, then asking for more a week later | Negotiate once, clearly, before accepting. Then commit. |
Research before the first call. Know CTC vs in-hand and your fixed / variable split. Give a range where the bottom is still a good outcome for you. Negotiate on the total package, with thanks and reasons. Get the final offer in writing before you resign.
Lying about current pay or other offers. Naming a number with no research. Ultimatums. Negotiating over chat in one-word messages. Resigning on a verbal offer. Accepting two offers and "ghosting" one — companies and campus placement cells remember.
20. Tricky HR Questions: Gaps, Switches, Relocation
Some HR questions poke at something on your CV that looks like a risk: a gap, several short jobs, a layoff, a move to a new city. The interviewer is not trying to trap you. They want to hear that you understand why it looks risky and that the risk does not apply now.
The formula is always the same: short honest fact, what you did or learned, why it is not a problem for this job. Then stop talking.
It is like a scratch on a second-hand phone. A seller who hides it loses your trust. A seller who says "small scratch from a drop, screen tested, works perfectly" usually makes the sale.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Why is there a gap on your CV?" | That you were not idle by accident, and that you are ready to work now. |
| "You changed jobs three times in four years. Why?" | Whether you will leave them in a year too. |
| "Why are you leaving your current job?" | Maturity. Do you move towards something, or just run away and complain? |
| "Are you okay with relocation / night shifts / a bond?" | A clear yes or no, so they do not hire someone who drops out later. |
| "Why should we hire you?" | A crisp summary that matches their needs to your proof. |
Common questions in this area
- "Can you explain this gap between 2023 and 2024?"
- "Why have you switched jobs so often?"
- "Why do you want to leave your current company?"
- "You were laid off. What happened?"
- "Are you willing to relocate to Pune / Hyderabad / any location?"
- "This role has US-shift / night-shift support. Is that okay?"
- "There is a two-year service agreement. Are you comfortable signing it?"
- "Are you interviewing anywhere else?"
- "Why should we hire you over other candidates?"
- "Why did you take a job outside your field?"
How to answer
"[Short fact]. During that time I [what you did: learned, built, handled]. That is behind me now, and I am looking for [stability / a long-term role], which is why this position fits."
Answers for each situation
| Situation | Sample answer |
|---|---|
| Employment or study gap | "I took eight months off to care for a family member. In that time I also completed a cloud certification and built a small booking app to stay sharp. Things are settled at home now and I am ready for a full-time role." (Health, family, exam preparation and upskilling are all acceptable reasons. You do not need to share private details.) |
| Frequent switches | "Fair question. My first move was because the startup shut down; the second was to move from testing to development, which I wanted from the start. At Brightcart I have been three years because I found the work I want to do. I am looking for a place to stay and grow for the long term." |
| Why leaving current job | "I have learned a lot at Brightcart — I led the checkout performance work and fixed our payment webhooks. I now want to work at a bigger scale and go deeper on distributed systems, which your platform team does every day." (No complaints about people or pay.) |
| Layoff | "My team was part of a company-wide layoff in [month] when the company cut [the product line]. It was not performance-based; my manager is happy to be a reference. Since then I have [upskilled / freelanced] and I am focused on finding the right long-term role." |
| Relocation | If yes: "Yes, I am open to relocating to [city]. I have already thought about it with my family." If limited: "I would prefer Bangalore or Hyderabad; I can relocate for the right role with some notice." Never say yes if the real answer is no. |
| Night / rotational shifts | "Yes, I understand the role supports US clients. I have done late-evening releases before and can manage it." Or honestly: "I can do occasional late calls, but a permanent night shift would be hard for health reasons." |
| Service bond / agreement | "I would like to read the terms first — the duration and what happens if I leave early. If they are reasonable, I plan to stay longer than that anyway." Read every bond carefully before signing. |
| Interviewing elsewhere? | "Yes, I am in process with a couple of companies, which is normal when switching. This role is my first preference because [reason]." Honest, not boastful. Do not name companies unless asked. |
| Why should we hire you? | "You need someone who can own backend performance and work closely with product. I have done exactly that: I cut checkout load time from 4.2 to 1.6 seconds, fixed a payments bug end to end with a postmortem, and I mentor interns. I can contribute from the first month." |
Which story fits: "Why should we hire you" is where you use your two or three strongest stories in one breath — for the example profile, (A) checkout speed, (B) payment-webhook bug and (E) mentoring. For "why leaving", mention (A) or (G) as what you have already achieved.
Good vs weak answer
| Weak | Strong |
|---|---|
| "My manager never listens and the company is a mess." | "I have learned a lot there; now I want bigger scale and deeper backend work." |
| A long, nervous story about the gap with too many private details | Two sentences: the reason, what you did, and that you are ready now. |
| Hiding a layoff or calling it a resignation | "It was a company-wide layoff, not performance-related. Here is what I did since." |
| "No, I am not interviewing anywhere." (when you are) | "Yes, a couple of processes; this one is my first preference because…" |
| "Because I am hardworking and a fast learner." | Their need + your proof with numbers + "I can contribute from month one". |
Keep risky topics short and factual. Show what you did during the gap or after the layoff. Frame every move as a step towards something. Give clear yes / no answers on relocation, shifts and bonds, and read bond terms before agreeing.
Badmouthing any past employer, manager or colleague — even if it is true. Lying about dates or reasons (background checks catch it). Over-explaining. Saying "yes" to relocation or shifts you will later refuse. Sounding bitter about a layoff.
21. Questions to Ask the Interviewer
Almost every interview ends with "Do you have any questions for us?" Saying "No, I think you covered everything" wastes your last chance to make an impression. Good questions show curiosity, show that you are judging them too, and give you real information to decide whether to join.
Prepare 5–6 questions and ask 2–3. Pick the ones that suit the person: an engineer knows the code and the team; a manager knows growth and priorities; HR knows policy and process.
It is like visiting a flat before renting it. You do not only answer the landlord's questions; you also check the water pressure, the neighbours and the power backup.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Any questions for me?" | Genuine interest in the work, not only in the salary. |
| (silently, from your question) | Whether you have researched the company and listened during the interview. |
| (silently, from your follow-up) | Whether you can hold a real two-way conversation, like a future colleague. |
Good questions to ask, grouped
| Area | Questions | Best asked to |
|---|---|---|
| Team | 1. "How big is the team, and how is it split between frontend, backend and QA?" 2. "How does the team usually make technical decisions — design docs, reviews, the lead decides?" 3. "Who would I work with most closely in the first few months?" 4. "How do you handle on-call and production issues?" | Engineer, manager |
| Work | 5. "What would I work on in my first 90 days?" 6. "What is the biggest technical challenge the team faces right now?" 7. "What does a typical week look like — meetings vs focused coding?" 8. "How does code get from a pull request to production here?" | Engineer, manager |
| Growth | 9. "What does success look like for this role after six months?" 10. "How do engineers here grow to the next level? Is there a clear framework?" 11. "How is feedback given — regular one-on-ones, reviews, both?" 12. "Is there support for learning — courses, conferences, internal tech talks?" | Manager, HR |
| Culture | 13. "What do you personally enjoy most about working here?" 14. "How does the team handle disagreements about technical direction?" 15. "How has the team changed in the last year?" 16. "How do remote and office team members work together?" | Anyone |
| Process | 17. "What are the next steps, and when can I expect to hear back?" 18. "Is there anything in my background you would like me to clarify?" | HR, last interviewer |
How to ask
"Earlier you mentioned [thing they said]. [Question about it]?" … then: "That is interesting — at Brightcart we [similar thing], so I would enjoy that."
Which story fits: a follow-up can quietly add one more proof. If they say the team struggles with slow pages, a line about (A) the checkout speed project fits naturally. If they mention mentoring juniors, mention (E).
Questions to avoid
| Avoid | Why | Ask instead |
|---|---|---|
| "What does your company do?" | Shows zero research. | "I read about your new [product]. How is the team involved?" |
| "How many leaves do I get?" in the first technical round | Sounds like you care most about time off. | Ask HR about policies at the offer stage. |
| "Did I pass?" / "How did I do?" | Puts the interviewer in an awkward spot. | "Is there anything I should clarify?" |
| "How soon can I get promoted?" | Sounds impatient. | "How do engineers grow to the next level here?" |
| Questions already answered in the interview | Shows you were not listening. | A follow-up on something they said. |
| Salary questions to a technical interviewer | Wrong person. | Keep pay questions for HR or the recruiter. |
Good vs weak answer
| Weak | Strong |
|---|---|
| "No, I think you covered everything." | "Yes, two. What would I work on in the first 90 days? And how does the team decide between rewriting and refactoring old services?" |
| Ten questions read out from a list | Two or three well-chosen questions with a real follow-up. |
| A generic question you could ask any company | A question linked to their product or to something said in the interview. |
Prepare 5–6 questions, ask 2–3. Match them to the person. Link at least one to something said in the interview. Write them down; it is fine to glance at your notes. Thank the interviewer for their answers.
Saying "no questions". Asking about leave, pay or promotion in early technical rounds. Asking what the company does. Asking questions that sound like a test of the interviewer. Going far over time with questions.
22. Amazon Leadership Principles
Amazon publishes a list of 16 Leadership Principles (LPs). They are not decoration — interviewers use them as the scoring sheet. Almost every behavioural question at Amazon is really "show me a time you lived this principle". Even technical rounds usually include one or two LP questions.
So the preparation is simple to describe: know all 16, and have at least one story for each, with the most common ones covered twice. Your story bank from section 3 already does most of the work.
It is like an exam where the syllabus is printed on the front page. Nobody knows the exact question, but you know every topic it can come from — so there is no excuse for leaving a topic out.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about a time…" (for a specific LP) | A real, specific story with your actions and a measurable result. |
| Follow-ups: "What exactly did you do?", "What data did you use?", "What would you do differently?" | Depth. Amazon interviewers dig several layers into one story to check it is real and that you drove it. |
| "What was the result?" | Numbers and business impact, not "it went well". |
| "Tell me about a time you failed / were wrong" | Ownership and learning, without blaming others. |
How the loop works
A typical Amazon interview loop has several interviewers. Each one is usually given a few LPs to probe, so the same principle is rarely tested twice. One of them is often a Bar Raiser: an experienced interviewer from outside the hiring team, trained to keep the hiring standard high across the company. The Bar Raiser pays close attention to LPs and has a strong voice in the final decision. You will not always know who it is, so treat every round the same.
All 16 Leadership Principles
Stories (A)–(I) are from the example profile in section 3. Use them as a model for mapping your own.
| # | Principle | In simple words | Typical question | Story from the bank |
|---|---|---|---|---|
| 1 | Customer Obsession | Start from the customer and work backwards. | "Tell me about a time you went above and beyond for a customer." | (I) bulk-import escalation; (A) checkout speed |
| 2 | Ownership | Act like an owner; never say "not my job". | "Tell me about a time you took on something outside your responsibility." | (D) took over the reporting tool; (B) webhook bug |
| 3 | Invent and Simplify | Find simpler ways; new ideas welcome. | "Tell me about a time you simplified a process." | (I) validation report; (B) idempotency keys |
| 4 | Are Right, A Lot | Good judgement; seek other views; test your beliefs. | "Tell me about a decision you made with incomplete data." | (C) spike to decide rewrite vs refactor |
| 5 | Learn and Be Curious | Always learning, curious about new things. | "Tell me about something you learned quickly." | (G) Kubernetes in two weeks |
| 6 | Hire and Develop the Best | Raise the bar in hiring; coach others. | "Tell me about a time you helped someone grow." | (E) mentoring the interns |
| 7 | Insist on the Highest Standards | High bar for quality; fix defects so they stay fixed. | "Tell me about a time you would not accept 'good enough'." | (B) postmortem and idempotency; (H) refusing to skip tests |
| 8 | Think Big | Bold direction; see beyond the immediate task. | "Tell me about a time you proposed something much bigger than asked." | (A) turning one fix into a performance budget for all pages |
| 9 | Bias for Action | Speed matters; many decisions are reversible. | "Tell me about a time you acted without all the information." | (G) unblocking the migration; (D) re-scoping fast |
| 10 | Frugality | Do more with less. | "Tell me about a time you delivered with limited resources." | (D) shipped core scope in 3 weeks; (C) refactor, not rewrite |
| 11 | Earn Trust | Listen, be honest, admit mistakes. | "Tell me about a time you had to admit you were wrong." | (F) missed estimate; (B) telling customers about double charges |
| 12 | Dive Deep | Stay close to details; question the numbers. | "Tell me about a problem you solved by digging into data." | (B) root cause of double charges; (A) profiling p95 |
| 13 | Have Backbone; Disagree and Commit | Challenge respectfully, then commit fully once decided. | "Tell me about a time you disagreed with your manager." | (H) pushing back on skipping tests; (C) senior-dev disagreement |
| 14 | Deliver Results | Deliver on time and with quality despite setbacks. | "Tell me about your most significant achievement." | (A) 4.2 s to 1.6 s, conversions up about 6%; (D) |
| 15 | Strive to be Earth's Best Employer | Build a safe, fair, growing workplace for others. | "Tell me about a time you made your team a better place to work." | (E) making code reviews less scary for an intern |
| 16 | Success and Scale Bring Broad Responsibility | Think about the wider effects of your work. | "Tell me about a decision where you considered impact beyond your team." | (H) protecting customers during the sale; (B) refunds |
How to answer
Use STAR (section 2) and aim for 2–3 minutes, because Amazon expects more detail than most companies. Then expect follow-ups.
- Say "I", not "we". They score what you did.
- Bring data: numbers before and after, how many users, how much time or money.
- Prepare for 3–4 follow-ups per story: "why that approach?", "what was the hardest part?", "what did you learn?", "what would you do differently?".
- Use recent stories (last 2–3 years where possible). Freshers can use internship, project and hackathon stories.
- Do not repeat the same story with every interviewer. Spread (A)–(I) across the loop.
Good vs weak answer
"We had a payments issue once. The team looked into the logs and found the bug and fixed it. It was a good learning experience."
"38 customers were charged twice during a sale. Support said it was random, but I pulled the webhook logs and saw every duplicate had the same event ID arriving twice within 2 seconds. Our handler was not idempotent. I added idempotency keys, wrote a script to find every affected order, and got all 38 refunded within a day. I also wrote the postmortem. We have had zero duplicate charges since."
Map at least one story to all 16 LPs, and two stories to Customer Obsession, Ownership, Dive Deep, Deliver Results and Have Backbone. Practise the follow-ups aloud. Include a failure story you can tell without blaming anyone.
Hypothetical answers ("I would…"). "We" all the way through. Stories without results. Making up stories — deep follow-ups expose them quickly. Bad-mouthing a colleague in a conflict story.
23. Google, Microsoft, Meta & Startups
Every company asks the same kinds of behavioural questions, but each one listens for slightly different things. Knowing what they value lets you pick the right story from your bank and stress the right part of it. You do not need a new set of stories for each company.
It is like cooking the same dal for different guests: a little less spice for one, a little more ghee for another. The recipe is yours; you only adjust the seasoning.
What they are really asking
| Company type | What they listen for | Stories that fit (example profile) |
|---|---|---|
| How you think through problems, knowledge for the role, leading without authority, and "Googleyness". | (C) spike to decide, (A) performance work, (I) customer problem | |
| Microsoft | Growth mindset: learning from mistakes, curiosity, helping others succeed. | (F) missed estimate, (G) Kubernetes, (E) mentoring |
| Meta | Handling conflict, growing from feedback, working through ambiguity, driving impact. | (C) conflict, (F) growth, (D) ambiguity, (A) impact |
| Startups | Ownership, speed, wearing many hats, comfort with little structure. | (D) took over the tool, (G) learned fast, (I) joined a customer call |
Google has publicly described four broad attributes it looks for:
- General cognitive ability — how you approach and break down problems, not just your grades.
- Role-related knowledge — the skills and experience for this particular job.
- Leadership — stepping up when needed, even without a formal title, and stepping back when someone else should lead.
- "Googleyness" — broadly: comfort with ambiguity, collaboration, humility, a bias to act, and doing the right thing for users and the team.
Behavioural questions often come as hypotheticals too: "What would you do if a teammate kept missing deadlines?" Answer the hypothetical with a clear approach, then add "I faced something similar…" and give a short real story.
For story (C), stress the reasoning: how you framed rewrite vs refactor, what data the spike gave, and how you brought the senior dev along without authority.
Microsoft
Microsoft talks openly about a growth mindset: the belief that ability grows with effort and learning. Interviewers listen for curiosity, learning from failure, asking for feedback, and helping colleagues succeed.
- Expect questions like "Tell me about a time you failed", "What did you learn from feedback?", "Tell me about something new you learned recently".
- Use words like "I learned", "I changed how I…", "I asked for feedback", and show the change actually happened.
For story (F), spend more time on what changed: "Since then I break estimates into tasks, add a buffer for unknowns, and flag risk at the first stand-up. My last four estimates were within a few days."
Meta
Meta's behavioural interview is commonly described as focusing on a few themes:
- Conflict — disagreements with peers or managers, and how you resolved them.
- Growth — feedback you received, weaknesses you worked on, how you have changed.
- Ambiguity — making progress when the goal or plan was unclear.
- Impact — the biggest results you drove, and how you chose what mattered most.
Answers should show scope and impact that match the level you are applying for. Expect "what would you do differently?" as a follow-up.
For story (D), stress the ambiguity: no documentation, a half-built tool, unclear priorities — and how you re-scoped with the PM to ship the core in 3 weeks.
Startups
Startups have small teams and few processes. They want people who own outcomes, move fast, and are happy to do things outside their job title.
- Expect: "Tell me about a time you did something outside your role", "How do you handle changing priorities?", "What would you build first in our product?".
- Show ownership (you finish things), speed (you ship and learn), and many hats (a developer who also talks to customers or sets up deployment).
- Try the product before the interview and have one thoughtful suggestion.
Stories (G) and (I) are perfect: you learned Kubernetes to unblock a deployment, and you joined a customer call and built a validation report nobody asked for.
Common questions across these companies
- "Tell me about a time you had a conflict with a teammate." (Meta, Google)
- "Tell me about a time you failed and what you learned." (Microsoft, all)
- "Tell me about a time you worked on something with an unclear goal." (Meta, Google)
- "What is the most impactful project you have worked on?" (all)
- "Tell me about a time you led without formal authority." (Google)
- "How do you learn a new technology quickly?" (Microsoft, startups)
- "Why do you want to work at a startup instead of a big company?" (startups)
- "What would you improve in our product?" (startups, Meta)
Good vs weak answer
| Weak | Strong |
|---|---|
| Telling every company the same story in the same way | Same story, but stress reasoning for Google, learning for Microsoft, impact for Meta, ownership for startups. |
| Memorising "Googleyness" as a buzzword and saying "I am very Googley" | Showing the traits in a story: humility, helping others, acting for the user. |
| At a startup: "I prefer clear processes and a fixed role." | "I like owning things end to end, even outside my job title." |
Read the company's own careers and culture pages. Pick 5–6 stories that fit what they value. Practise one answer for each theme (conflict, growth, ambiguity, impact). Research the product, and for startups try it yourself.
Relying on rumours or forum posts as facts. Repeating culture buzzwords without proof. Treating big-company interviews as purely technical — behavioural rounds can decide the level you get, or whether you get an offer at all.
24. Service Companies & Campus Placements
Large IT service companies such as TCS, Infosys, Wipro, Accenture and Cognizant hire freshers in big numbers, mostly through campus drives and national hiring tests. Their HR round is usually shorter and friendlier than a product-company behavioural round. They mainly check communication, attitude, flexibility and whether you will join and stay.
Many students lose these offers not on skill but on small things: a nervous self-introduction, saying no to relocation, or not knowing basic facts about the company.
It is like a driving test for a licence, not a racing trial. They are not looking for the fastest driver; they want someone safe, steady and willing to follow the road rules.
What they are really asking
| They ask… | They want to see… |
|---|---|
| "Tell me about yourself." | Clear, confident English (or the language of the interview) and a structured answer. |
| "Are you willing to relocate / work in shifts?" | Flexibility. Service companies place people where projects need them. |
| "Are you comfortable with any technology we assign?" | Willingness to learn — you may not get your favourite stack. |
| "Why our company?" | Basic research and genuine interest, not "because it came to campus". |
| "Do you plan higher studies?" | Whether you will leave during or soon after training. |
The campus placement flow
Most of these companies also run off-campus national hiring tests and different hiring tracks with different packages (for example a standard role and a higher "digital" or "specialist" role, depending on the company). Names, rounds and packages change often, so check each company's official careers page for the current year.
What each company's HR round tends to focus on
| Company | HR round usually checks | Prepare |
|---|---|---|
| TCS | Communication, willingness to relocate and work in shifts, basic company awareness. Sometimes a combined technical + managerial + HR panel. | A crisp introduction, your final-year project, a clear yes on relocation if true. |
| Infosys | Attitude, learning ability, comfort with a long training programme, flexibility on location and technology. | Why you want to train and grow there; examples of learning something fast. |
| Wipro | Communication, project understanding, service agreement and relocation acceptance. | Read the terms of any service agreement before the interview. |
| Accenture | Communication (often also assessed in an earlier round), teamwork, client-facing attitude. | Team project stories and how you handle a client or teammate who is unhappy. |
| Cognizant | Confidence, basics of your CV, flexibility, willingness to learn any technology. | Every line of your CV — they will pick from it. |
Group discussions (GD)
Some companies and many campus drives use a GD of 8–12 students on a topic for 10–20 minutes. Evaluators watch how you contribute, not only what you say.
| Stage | How to do it well |
|---|---|
| Entering | Starting first earns points only if you start well: define the topic and give a structure ("Let us look at this from the student, company and society angles"). If you cannot start, enter in the first few minutes. Use a pause, or build on someone: "Adding to what Priya said…". |
| Adding value | Bring a fact, an example or a new angle — not a repeat. Keep each point to 20–30 seconds. Balance both sides of the topic. |
| Handling others | Invite a quiet member in ("Rahul, what do you think?"). If someone dominates, wait for a breath and say "Let me add a different view". Never shout or interrupt repeatedly. |
| Summarising | If you get the chance, summarise in 30–45 seconds: the main points from both sides and a balanced conclusion. A good summary can make up for fewer points earlier. |
Common GD topics: AI and jobs, remote work vs office, social media and youth, electric vehicles in India, online education, startups vs service jobs. Read the news for two weeks before placements.
Common HR questions for freshers
- "Tell me about yourself." (See section 4.)
- "Why do you want to join our company?"
- "What are your strengths and weaknesses?"
- "Tell me about your final-year project. What was your role?"
- "Tell me about a problem in your team project and how you solved it."
- "Are you willing to relocate anywhere in India? Work in night shifts?"
- "Are you okay with the service agreement?"
- "Do you plan to go for higher studies?"
- "Why should we hire you?"
- "Where do you see yourself in five years?"
- "Why did you choose engineering / computer science?"
- "Do you have any backlogs?" (Answer honestly; know your current status.)
How to answer
"I want to start my career at [company] because [its training programme / range of clients and domains / something specific you learned in the pre-placement talk]. It will let me work on [kind of projects] and learn [skills]. During my internship I built [project], and I would like to use that experience on real client projects."
Which story fits (fresher variant): use the internship admin dashboard for "tell me about your project", the college attendance app where one member stopped contributing for teamwork or conflict, and the 24-hour hackathon (finished 2nd) for pressure and learning fast.
Good vs weak answer
| Weak | Strong |
|---|---|
| "I want to join because it is a big company and it came to our campus." | A specific reason: training, domains, something from the pre-placement talk. |
| "I only want to work in Bangalore on Python." | "I am open to any location and technology; I learn fast, as I did in my internship." |
| In a GD: repeating others louder | One fresh point with an example, then inviting a quiet member in. |
Practise your introduction until it is smooth. Know every line of your CV and your project. Attend the pre-placement talk and note two facts. Be honest and clear about relocation, shifts, bonds and higher studies. Dress formally and carry printed copies of your CV and documents.
Treating the HR round as a formality. Memorised answers delivered like a speech. Lying about backlogs or marks (they are verified). Accepting an offer you do not plan to take — it can block a classmate and may break your college's placement rules.
25. Common Mistakes & Red Flags
Interviewers often reject a candidate for one red flag — a moment that makes them worry about working with you — even if the rest was fine. Most red flags are easy to avoid once you know them.
It is like a cricket innings: a hundred good balls do not matter if you get run out by a silly mistake. Avoiding the run-out is part of batting well.
What they are really asking
| They notice… | They worry that… |
|---|---|
| Blaming others in every story | You will blame the team here too. |
| Only "we", never "I" | You did not actually do the work. |
| Vague answers with no results | The story is made up, or had no impact. |
| Arrogance or dismissing feedback | You will be hard to work with. |
| Inconsistencies with your CV | You are not honest. |
The top 15 mistakes and how to fix them
| # | Mistake | Why it hurts | Fix |
|---|---|---|---|
| 1 | Rambling for 5 minutes | The interviewer loses the point and runs out of time. | Aim for 1.5–2 minutes with STAR; end with the result. |
| 2 | "We did…" all the way through | They cannot tell what you did. | Say "I" for your actions; "we" only for team context. |
| 3 | No result, or "it went well" | No proof of impact. | Give a number or a clear outcome: "4.2 s to 1.6 s", "38 refunds in a day". |
| 4 | Blaming teammates, managers or clients | Red flag for teamwork and ownership. | Describe the situation neutrally; focus on what you did. |
| 5 | Badmouthing a past employer | They imagine you saying the same about them. | Talk about what you are moving towards (section 20). |
| 6 | Hypothetical answers ("I would…") | They asked for a real example. | "Let me share a time that happened": then STAR. |
| 7 | A fake weakness ("I work too hard") | Sounds rehearsed and evasive. | A real, safe weakness plus the steps you take (section 17). |
| 8 | A failure story with no real failure | Shows low self-awareness. | Use a real mistake like (F) the missed estimate, and what changed. |
| 9 | Using the same story for every question | Looks like you have only one experience. | Build a bank of 8–10 stories (worksheet below). |
| 10 | Made-up or exaggerated stories | Follow-up questions expose them fast. | Only real stories; it is fine if they are small. |
| 11 | Lying about CTC, dates or reasons for leaving | Background checks catch it; offers get withdrawn. | Be honest and frame it well. |
| 12 | No research on the company | Signals low interest. | Read the product, careers page and recent news; try the product. |
| 13 | "No questions" at the end | Looks uninterested. | Prepare 5–6, ask 2–3 (section 21). |
| 14 | Arguing with the interviewer or getting defensive on follow-ups | Shows you handle challenge badly. | "That is a fair point" — then explain calmly or admit what you would change. |
| 15 | Poor setup in virtual interviews: noise, bad camera, late joining | First impression is lost before you speak. | Test audio, camera and internet; join 5 minutes early (checklist below). |
Smaller red flags people miss
- Checking your phone or looking away for notes constantly.
- Talking about salary or leave in the first technical round.
- Negative body language: crossed arms, no eye contact, sighing at a question.
- Over-rehearsed, robotic answers that do not match the question asked.
- Not letting the interviewer finish a question.
- Forgetting the details of your own CV.
How to recover in the moment
Mistakes happen. What matters is how you recover.
- Went blank: "Can I take a moment to think of the best example?" — then take 10 seconds.
- Rambling: "Let me get to the result…" and finish.
- Said something wrong: "Actually, let me correct that — it was 3 sprints, not 2."
- Wrong story for the question: "I realise that answered a slightly different question. A better example is…"
Good vs weak answer
"Our search feature was late because the PM kept changing things and the backend team was slow. We eventually shipped it."
"I estimated our search feature at one sprint and it took three. I had not broken it into tasks or checked the indexing work with the backend team. I told the PM as soon as I saw the slip and re-planned. Since then I break work into tasks under two days and flag risks in the first stand-up. My estimates have been much closer since."
Record yourself answering five questions and watch it back for the mistakes above. Ask a friend to note every time you say "we" or blame someone. Keep answers to about two minutes with a clear result.
Blame, lies, rambling and "no questions". Any one of these can undo an otherwise good interview.
Story Bank Worksheet
This is the one page to fill in before any interview. Write 8–10 real stories in short notes (not full scripts), tag each with the competencies it proves, and list the questions it can answer. On the day, you only need to glance at this table.
Like a spice box in the kitchen: a few well-stocked jars cover almost every dish.
Blank template
Copy this into a notebook or spreadsheet. Keep each cell short — a few words or one line.
| Story | Situation | My actions | Result / number | Competencies | Questions it answers |
|---|---|---|---|---|---|
| 1. | |||||
| 2. | |||||
| 3. | |||||
| 4. | |||||
| 5. | |||||
| 6. | |||||
| 7. | |||||
| 8. | |||||
| 9. | |||||
| 10. |
Filled-in model (example profile)
| Story | Situation | My actions | Result / number | Competencies | Questions it answers |
|---|---|---|---|---|---|
| (A) Checkout speed | Checkout p95 load 4.2 s; users dropping off | Profiled, split bundles, lazy-loaded, cached API calls, set a performance budget | p95 4.2 s to 1.6 s; conversions up about 6% | Impact, customer focus, problem solving, initiative | Proudest achievement; biggest impact; went beyond scope |
| (B) Webhook double charge | 38 customers charged twice in a sale | Found duplicate events in logs, added idempotency keys, ran refunds, wrote postmortem | All 38 refunded in a day; no repeats since | Ownership, dive deep, integrity, pressure | A mistake / production issue; worked under pressure; high standards |
| (C) Rewrite vs refactor | Senior dev wanted to rewrite the orders service | Proposed a small spike, compared effort and risk with data, discussed openly | Agreed on incremental refactor; no big-bang risk | Conflict, influence, judgement | Disagreed with a senior; persuaded someone; decision with limited data |
| (D) Reporting tool rescue | Delayed tool; owner left mid-project | Read the code, re-scoped with the PM, cut to core features, shipped | Core shipped in 3 weeks | Ownership, ambiguity, prioritisation, delivery | Took over a mess; unclear requirements; tight deadline |
| (E) Mentoring interns | Two interns; one struggling with code reviews | Paired weekly, review checklist, explained the "why" of comments | Intern's reviews needed fewer rounds; confidence up | Leadership, feedback, empathy | Helped someone grow; gave hard feedback; leadership without title |
| (F) Missed estimate | Said 1 sprint for search; took 3 | Told PM early, re-planned, changed estimating method | Later estimates much closer | Failure and learning, honesty, growth mindset | Biggest failure; missed deadline; what you learned |
| (G) Kubernetes in 2 weeks | Deployment migration blocked | Focused learning plan, practised on a test cluster, asked the infra team | Migration unblocked | Learning fast, adaptability, bias for action | Learned something new quickly; out of comfort zone |
| (H) No-tests pushback | PM wanted to skip tests before a sale weekend | Explained risk, proposed a smaller safe scope with tests | Safe release; no incidents over the sale | Backbone, customer focus, standards, ethics | Pushed back on a manager; said no; quality vs speed |
| (I) Bulk-import escalation | B2B client's bulk imports failing | Joined the call, found the bad rows, built a validation report | Client unblocked; report reused for others | Customer obsession, problem solving, communication | Difficult customer; went above and beyond; explained tech to non-tech |
| Fresher: team project | 4-person attendance app; one member stopped contributing | Talked to them privately, re-split tasks, kept the team on track | App delivered on time | Teamwork, conflict, leadership | Difficult teammate; team conflict; leadership |
Night-Before & 30-Minute Checklist
The last 24 hours are for calm review and logistics, not new learning. Go through these lists once and you will walk in with nothing left to worry about.
The night before
| Area | Check |
|---|---|
| Stories | Read the story bank once. Say the one-line result of each story aloud. |
| Introduction | Say "Tell me about yourself" aloud twice; time it (about 1.5–2 minutes). |
| Company | Re-read your notes: product, recent news, values (for Amazon, the 16 LPs). |
| Role | Re-read the job description; match two stories to its top requirements. |
| Numbers | Current CTC split, expected range, notice period and earliest joining date. |
| Questions | Write 5–6 questions for the interviewer. |
| CV | Read every line. Anything on it is fair game. |
| Logistics | Location and travel time, or meeting link and platform. Interviewer names if known. |
| Documents | Printed CV copies, ID, mark sheets or payslips if requested (campus: all certificates in a folder). |
| Clothes | Ironed and ready. Formal for campus and service companies; smart casual is usually fine elsewhere. |
| Sleep | Stop preparing at a fixed time. Sleep well — it helps more than one more hour of revision. |
30 minutes before
- Eat something light and drink water.
- Virtual: close other apps and notifications, phone on silent, test camera, mic and internet, plug in the charger, check lighting (face the light), plain background.
- In person: reach 15 minutes early; find the washroom and reception first.
- Keep water, a pen, a notepad and your one-page story list nearby.
- Read your three strongest stories' results once: for the example profile, (A), (B) and (C).
- Say your opening line aloud once to warm up your voice.
- Take three slow breaths. Remind yourself: they want you to do well — they need to hire someone.
- Join the call 3–5 minutes early.
Right after the interview
- Write down every question you were asked and how you felt about each answer.
- Note what to improve for the next round.
- Send a short thank-you email to the recruiter if appropriate (two or three lines).
Prepare logistics the night before so the morning is calm. Review, do not cram. Keep a one-page story list next to you.
Learning new stories or frameworks the night before. Staying up late. Joining a video call from a noisy place or on low battery.
2-Week Practice Plan
Behavioural skill comes from saying answers aloud, not from reading about them. This plan needs about 45–60 minutes a day. Week 1 builds your material; week 2 turns it into smooth, timed answers.
Like learning a song: first you write down the lyrics, then you sing it until you do not need the paper.
Week 1 — Build your material
| Day | Task | Output / target |
|---|---|---|
| 1 | Read sections 1–3. List every project, incident, conflict, success and mistake from the last 2–3 years (or college, internship and hackathon for freshers). | A raw list of 15+ moments |
| 2 | Pick the best 8–10. Fill in the story bank worksheet. | Complete worksheet; every competency covered twice |
| 3 | Write and say aloud your "Tell me about yourself" (section 4). Record it on your phone. | 1.5–2 minutes, no reading |
| 4 | Write STAR bullet notes for stories 1–5. Say each aloud and time it. | Each 1.5–2 minutes; Action about 60% |
| 5 | STAR notes for stories 6–10. Record two of them and watch back. | List of fillers and "we" moments to fix |
| 6 | HR round: strengths and weaknesses, career goals, why leaving, salary range and notice answer (sections 16–20). | One-line answers written; salary range researched |
| 7 | Review day. Re-record your intro and your two weakest stories. | Clear improvement from day 3 |
Week 2 — Rehearse under pressure
| Day | Task | Output / target |
|---|---|---|
| 8 | Research your target companies (sections 22–24). Map stories to their values. | A company-to-story sheet; Amazon: all 16 LPs mapped |
| 9 | Random-question drill: shuffle 20 questions; answer each within 10 seconds of reading it. | Pick the right story quickly |
| 10 | Mock interview 1 with a friend (30–45 min). Ask them to push with follow-ups: "what exactly did you do?", "what would you change?". | Friend's notes on clarity, length and confidence |
| 11 | Fix the weak spots from the mock. Practise the failure and conflict stories until they sound calm, not defensive. | No blame words; clear learning at the end |
| 12 | Mock interview 2 on video, like a real virtual interview. Include "Any questions for us?" and a salary question. | Setup tested; 2–3 good questions ready |
| 13 | Timed run: intro + 6 stories back to back, recorded. Freshers: add a practice GD with friends. | Every answer under 2 minutes 30 seconds |
| 14 | Light day. Read the story bank once, go through the checklist, sleep early. | Calm and rested |
Timing targets
| Answer type | Target length |
|---|---|
| Tell me about yourself | 1.5–2 minutes |
| STAR story | 1.5–2 minutes (up to 3 at Amazon), about 60% on Action |
| Short HR answers (relocation, notice, why us) | 20–45 seconds |
| Strengths / weaknesses | About 1 minute each |
| GD point | 20–30 seconds; summary 30–45 seconds |
Speak aloud every day. Record and watch yourself at least three times over the two weeks. Do at least two mocks with a real person who asks follow-ups. Track the length of every answer.
Only reading and never speaking. Memorising full scripts word for word — keep bullet notes so you sound natural. Skipping the failure and conflict stories because they feel uncomfortable; those are exactly the ones interviewers ask.