Behavioral answers, STAR stories & negotiation

How do you structure a behavioral answer?

STAR: Situation (context, briefly) → Task (your responsibility) → Action (what you did, the bulk of the answer) → Result (the outcome, quantified).

Timing: 20 seconds of situation, 15 of task, 60-90 of action, 20 of result. The most common failure is spending two minutes on background and never reaching what you did.

Rules that matter more than the acronym:

• Say "I", not "we". Interviewers cannot score a team. Use "we" for context and "I" for actions.
• Quantify the result. "Cut p95 latency from 1.2 s to 240 ms" beats "made it much faster". If you have no metric, use a proxy: "support tickets on that flow dropped from about ten a week to none".
• Include what you learned or would do differently. It signals self-awareness and is often an explicit rubric line.

Which stories should you prepare?

Seven, written out, each usable for several questions:

1. A hard technical problem you solved — your depth story. Know it well enough to draw the architecture.
2. A conflict with a colleague — how you disagreed, and how it resolved.
3. A failure or an outage you caused — what broke, what you did, what changed afterwards.
4. Something you led or drove without authority — influence, not a title.
5. A time you disagreed with a decision and either changed it or committed to it anyway.
6. A time you had to learn something fast under real pressure.
7. Something you improved that nobody asked you to — ownership.

Write each in STAR form, out loud, timed at two minutes. Then practise mapping questions to stories: "tell me about a time you handled ambiguity" and "tell me about a project that went off track" can both be story 4 with a different emphasis.

How do you answer "tell me about yourself"?

Ninety seconds, three parts: now (what you do and the scope of it), how you got here (two or three moves, each with a reason), why this role (specific to them). End on a forward-looking note that invites their first question.

"I'm a backend engineer at X, where I own the payments service — about 400 requests a second and the part of the system that cannot be down. I started in a full-stack role at a small startup, which is where I learned to ship end to end, then moved to X specifically to work on systems at scale, and over the last two years I've focused on reliability: I led the migration off our monolithic billing job to an event-driven design and cut failed payments by a third. I'm talking to you because the role is squarely on the infrastructure side of a product I actually use, and I want to keep going deeper there rather than broader."

What it must not be: a chronological recitation of your CV, or personal biography. They have the CV; they want the narrative and the signal.

"What is your greatest weakness?"

Give a real one, with the mechanism you use to manage it. Not a humblebrag ("I care too much"), not a disqualifier ("I miss deadlines"), and not something core to the job you are applying for.

"I default to solving things myself instead of asking, which used to mean I'd spend a day on something a colleague could have unblocked in ten minutes. I now hold myself to a rule: 45 minutes stuck, then I write up what I've tried and ask in the team channel. It's noticeably shortened a few of my worst weeks, and honestly it made me better at writing up problems clearly."

The structure is: honest weakness → concrete cost → specific system → evidence it works.

"Tell me about a time you failed."

Pick a real failure with real consequences, own it fully, and spend most of the answer on what changed. Do not choose a fake failure ("I shipped early and it was too good"), do not blame teammates, and do not pick something that reveals a character problem rather than a judgement one.

"I ran a migration that added a NOT NULL column on a 40-million-row table during business hours. It locked writes for eleven minutes and took checkout down. I rolled it back, wrote the incident report myself, and led the postmortem. The concrete outcomes: we added a migration review checklist, a linter that fails CI on unsafe DDL patterns, and a rule that schema changes ship in a separate release window. I've run maybe forty migrations since with no incidents — and it made me the person on the team people ask about safe schema changes."

That last line matters: failure stories should end with you as the person who now prevents that failure.

How do you handle "why are you leaving?"

Be positive, brief and forward-facing. Never criticise your employer, manager or colleagues — even when justified, it reads as a risk. Frame it as moving towards something.

"I've learned a lot there and I'm proud of the payments work, but the team's roadmap for the next year is mostly maintenance, and I want to be building systems at higher scale. That's what drew me to this role."

If you were laid off, say so plainly and without apology — it is extremely common and carries no stigma: "My team was cut in the October restructuring, along with about 15% of engineering."

If you were fired, be brief, honest, non-defensive, and pivot to what you changed. One sentence, then move on.

What questions should you ask the interviewer?

Ask questions whose answers would actually change your decision. Have six ready, because two will get answered before you can ask.

• "What does the first 90 days look like for whoever takes this role?"
• "What is the biggest technical problem the team is dealing with right now?"
• "How do changes get from a laptop to production — what does that pipeline look like?"
• "How much of the team's time goes to new work versus maintenance and on-call?"
• "What is on-call actually like — how many pages in a typical week?"
• "How are decisions made when engineers disagree on an approach?"
• "What separates someone who is doing well in this role from someone who is doing exceptionally?"
• To the manager: "What happened to the last two people in this role?"

Avoid, in the first rounds: salary specifics, remote-work negotiations, holiday policy. Those come at offer stage, when you have leverage.

How do you talk about salary before you have an offer?

Do not name a number first if you can avoid it. The recruiter has a band; the first number spoken anchors the negotiation.

Deflection that works:

"I'd rather learn more about the scope of the role first. What range is budgeted for this position?"

If pressed and you must answer, give a researched range with the top of your target at the bottom of it, based on levels.fyi, Glassdoor and your network for that company, level and location: "Based on what I've seen for this level in this market, I'd be looking at something in the region of X to Y, but I'm flexible depending on the overall package."

Note that asking for salary history is illegal in many US states and several other jurisdictions — you can simply decline: "I'd rather focus on the value of this role than what I was paid previously."

How do you negotiate an offer without losing it?

First: an offer is very rarely rescinded for polite negotiation. They have spent thousands of dollars and weeks of engineer time to reach this point; restarting is far more expensive than the raise you are asking for.

The process:

1. Thank them, express real enthusiasm, ask for the full details in writing — base, bonus, equity (number of units, strike price, vesting schedule and current valuation), sign-on, start date.
2. Do not accept on the call. "This is great and I'm excited. Can I take a couple of days to look at the details properly?" Nobody reasonable refuses this.
3. Anchor with a reason, not a demand. Competing offers are the strongest lever; if you have none, use market data and scope: "I'm very keen to join. Based on the market for this level and the on-call ownership in the role, I was hoping for base closer to X. If you can get there, I'll sign today."
4. Negotiate the whole package. Base is often the most constrained by band; sign-on bonus, equity refresh, level, start date and a written review at six months are frequently more flexible.
5. Get every agreed change in the written offer before you resign anywhere.
6. Be someone they still want to hire. Warm, decisive, never adversarial, never using a fake competing offer — that gets discovered more often than people expect.

A single ten-minute conversation routinely moves compensation by 5-20%, and every future raise compounds off that number. Not negotiating is the most expensive ten minutes you can save.

What do you do after the interview?

Send a short thank-you email within 24 hours — three sentences: thanks, one specific thing from the conversation that stuck with you, one line reaffirming interest. If a question tripped you up, this is a legitimate place to add two sentences with the better answer; it shows you kept thinking.

Then write your own debrief while it is fresh: what they asked, what you fumbled, what you would say next time. Over ten interviews that document becomes the most valuable preparation material you own — far better than any question list, because it is specifically about your gaps.