Behavioral Questions, Salary Talk, and Closing Strong

Previously, in Part 7, you designed a booking system out loud like a pro. One round remains — and it's the one candidates prepare for least, even though it decides more offers than any algorithm question: the behavioral interview, the questions you ask them, and the money conversation. Let's close strong.

STAR, without sounding like a robot

The framework you'll hear about is STAR: Situation, Task, Action, Result. Set the scene in a sentence, say what needed doing, spend most of your time on what you did, and land on what happened — ideally with a number or a changed outcome. It works because it stops the two classic failure modes: rambling context that never arrives at a point, and "we did X" stories where the interviewer never learns what you contributed. But here's the anti-robot advice: STAR is a skeleton, not a script. Tell the story the way you'd tell a colleague over coffee — "so the deploy went out Friday at 4 p.m., and of course..." — and let the structure sit invisibly underneath. Interviewers can smell a rehearsed monologue in seconds; a real story told with energy is unbeatable.

"Tell me about a tough bug you fixed."

Why they ask it: This is every interviewer's favorite question, because a bug hunt is a character test in miniature: how you reason under uncertainty, whether you use tools or guesswork, and who you blame when things break.

A strong answer: Pick a bug with a genuine hunt — not "I forgot a null check." The best stories have a false lead ("we were sure it was the cache"), a turning point, and a specific tool that cracked it: structured logs that revealed the pattern, a memory profiler, or git bisect walking the history to the exact commit that introduced the break. Naming the tool is what makes the story credible. (If your Git is shaky beyond commit and push, our Git basics series covers the moves that make stories like this possible.) End with what changed afterward — a regression test, an alert, a habit.

Follow-ups to expect:

• "How did you make sure it never came back?" — Have the regression test or monitoring answer ready.
• "What would you do differently now?" — They want self-awareness, not perfection.
• "How long did it take?" — Honesty wins; a three-day hunt told well beats a fake afternoon.

"Tell me about a disagreement with a colleague."

Why they ask it: Every team has friction; this question tests ego versus collaboration. The interviewer is deciding whether disagreeing with you will be a conversation or a siege.

A strong answer: Pick a real, technical disagreement — a library choice, an API shape, a rewrite-versus-refactor debate. Show that you argued your case with evidence, genuinely listened, and then committed fully to whichever direction won, even if it wasn't yours. The strongest ending is generous: "we prototyped both in a day and their approach handled our edge cases better — I was glad we went with it." Being demonstrably wrong and demonstrably fine about it is one of the most senior signals you can send.

Follow-ups to expect:

• "What if you were sure they were making a mistake?" — Escalate with data and respect, then commit to the outcome.
• "How did the relationship end up?" — Show the disagreement stayed about the work, not the person.

"Why are you leaving? Why us?"

Why they ask it: They're checking whether you're running toward something or just away from something — and whether you know anything about them beyond the salary range.

A strong answer: is forward-looking, and never trash-talks. Not "my current place is a mess" but "I've learned a lot maintaining a large system, and I want to be somewhere I can own features end to end." For "why us," one genuine, specific reason beats five generic ones: their tech stack, their product, something from their engineering blog, the problem space. Whatever frustration is actually driving your search — and there usually is one — translate it into the positive thing you're seeking. The interviewer knows the translation is happening; performing it gracefully is the test.

Follow-ups to expect:

• "What would make you stay where you are?" — Stay positive and consistent with your "why leaving."
• "Where do you want to be in three years?" — Growth in craft is always a safe, true answer.

Five great questions to ask them

"Any questions for us?" is not a formality — it's the part of the interview you control completely. Asking nothing says you don't care; asking well says you evaluate teams like a professional. Five that consistently land:

• "Walk me through how a feature goes from idea to production here." — Reveals the whole engineering culture in one answer.
• "What does code review look like on this team?" — Thorough and kind, rubber-stamp, or battleground? You want to know now.
• "How often do you deploy, and how scary is it?" — Deployment pain is daily-life pain.
• "What would success look like for this role in six months?" — Shows you think in outcomes, and surfaces vague expectations early.
• "What keeps you here?" — Asked warmly, this gets the most honest answer of the day. Watch how long they pause.

Let's talk about money — briefly and honestly

A few rules cover most situations. Research a range before any interview — salary surveys, job-board filters, people in your network — so numbers have context. When you can, let them name a figure first; if pressed, give your researched range rather than a single number. Think total compensation, not just base: bonus, benefits, leave, remote flexibility, and learning budget are all real money. And remember that silence is allowed — when an offer lands, "thank you, I'd like a day or two to consider it" is professional, expected, and often the moment the offer improves. You don't need to be a shark negotiator; you just need to not answer instantly.

The full-loop checklist

And that's the series. Look at what you've covered — this is the entire interview loop, end to end:

• Part 1 — the shape of the .NET interview loop, so nothing surprises you
• Part 2 — the C# fundamentals every screen starts with
• Part 3 — async and await, explained so you can explain them
• Part 4 — collections and LINQ, chosen deliberately
• Part 5 — middleware, DI lifetimes, REST design, and JWTs
• Part 6 — indexes, N+1, tracking, and debugging like a senior
• Part 7 — a full system design walkthrough on home turf
• Part 8 — stories, questions, and the money talk: you're reading it

Here's the part worth saying plainly: if you actually did the 🧪 try-its along the way, you didn't just read about interviews — you built an execution-plan story, an N+1 fix in your own code, a rehearsed design narration, and a two-minute bug hunt. Those are real talking points from real work, and they are exactly what interviewers remember after a long day of candidates.

Go get the offer. And when you do — or when an interviewer throws you a question this series didn't cover — write and tell me about it. Interview stories from readers are how this series gets its next edition.