The motivation questions usually come at the start or the end of a round, and candidates often treat them as small talk: “Why do you want to work here?” “Why are you leaving your current job?” “Where do you see yourself in five years?” And then, at the end, “Do you have any questions for us?”
None of them is small talk. Each is scored, and the last one is scored more often than people realise. This post covers what each is really asking, how to answer without a script or a complaint, the salary question, the questions you should ask them, and a checklist for the night before.
“Why this company?”
The interviewer is checking two things: that you have done your homework, and that there is a real overlap between what they need and what you want. The answer that fails is one that could be said to any company: “great culture, interesting problems, room to grow”.
A strong answer has three parts, each specific to them:
WHY THIS COMPANY
WHAT THEY DO one specific thing about the product, market or engineering
that you actually looked into ("your move to event-driven billing")
WHY IT FITS YOU a link to your real experience or interest
("I've spent the last year on exactly that kind of migration")
WHAT YOU'D ADD what you would bring to it, concretelyThe homework is the whole answer. Read the engineering blog, the job description line by line, recent release notes, talks their engineers have given. One concrete, accurate detail — a problem they have written about publicly — is worth more than any amount of enthusiasm.
“Why are you leaving?”
This is the question where honesty and diplomacy have to coexist. The rule is simple: talk about what you are moving towards, not what you are running from.
Never criticise your current or past employer, manager or team, even when the criticism is deserved. The interviewer hears it as a preview of how you will talk about them. Instead, name the thing you want that you cannot get where you are — a kind of problem, a scale, a stage of company, a technology, a role — and connect it to this job.
INSTEAD OF SAY
"my manager micromanages" "I want more ownership of decisions end to
end, and this role has that"
"the codebase is a mess" "I'm looking for a team that invests in
engineering quality - your testing culture
is a big part of why I applied"
"the pay is bad" (save compensation for the salary
conversation; see below)
"I'm bored" "I've learned a lot there; I want to work
on ___ , which they don't do"If you were laid off, say so plainly and without embarrassment: “My role was part of a reduction in force in March.” Layoffs are common and not a reflection on you. Then move on to what you want next. Over-explaining is what makes it awkward.
“Where do you see yourself in five years?”
Nobody expects a precise plan. The interviewer wants to know whether your direction is compatible with the job — whether you will be glad to be here in two years or restless in six months. Give a direction, not a title: the kind of problems you want to be good at, the kind of impact you want to have, and why this role is a step that way. “Running your company” is a joke that has stopped being funny; “I don't really plan that far” sounds like you have not thought about it.
The salary question
“What are your salary expectations?” often arrives early, from a recruiter. Three principles:
- Know your number before the call. Research the range for the role, level and location from salary data sites, the posting itself (many jurisdictions now require a range), and people you know. Decide your walk-away figure privately.
- Prefer a range anchored to the market, or ask theirs first. “I'd want to understand the full scope first, but for roles like this I'm seeing ___ to ___. What range is budgeted for this one?” is honest and keeps you from anchoring low.
- Talk total compensation. Base, bonus, equity and benefits together. A lower base with meaningful equity can be the better offer, and vice versa.
The negotiating salary post goes further into the negotiation itself, once there is an offer on the table.
“Do you have any questions for us?”
“No, I think you've covered everything” is one of the most common ways to lose points at the very end of a good interview. Your questions show what you care about, how much you prepared, and whether you are evaluating them as seriously as they are evaluating you. Have five ready and ask two or three.
Good questions are about the actual work and the actual team, and they are tailored to who you are talking to:
TO AN ENGINEER
what does a typical week look like for you? how much is building vs meetings?
how does code get from a laptop to production? how long does it take?
tell me about the last incident: how was it found, and what changed after?
what would you change about the codebase if you had a free month?
TO THE HIRING MANAGER
what would success in this role look like in the first 90 days? first year?
what is the biggest problem the team is facing right now?
how do you give feedback, and how often?
what has made people succeed - or struggle - in this role before?
TO A SENIOR LEADER
where is engineering investing over the next year, and why?
what is the hardest trade-off the company is making right now?
FOR ANY OF THEM
is there anything in my background that gives you pause? (lets you address it)The last one takes nerve and is very effective. It gives you a chance to answer a concern before the debrief, rather than letting it decide the outcome silently.
Avoid questions answered on the first page of their website, and leave questions about vacation, perks and remote policy for the recruiter, not the engineers.
The night before: a checklist
STORIES
[ ] 8 stories, each with a worksheet; facts checked against your records
[ ] each story told out loud once, under ~2 minutes
[ ] every question family has at least one story; the thin ones rehearsed twice
[ ] the failure story ends with what you CHANGED
THIS COMPANY
[ ] one specific thing about their product/engineering you can talk about
[ ] "why this company" and "why leaving" in one sentence each, forward-looking
[ ] your salary range, and your private walk-away number
[ ] 5 questions, tailored to each interviewer you know about
IN THE ROOM
[ ] "I" for your actions, "we" for the team's goals
[ ] situation short; most of the time on the action
[ ] it's fine to pause and think. Ask to clarify an ambiguous question
[ ] if you don't have a story for something, say so and give the closest real oneThat last line deserves to close the track. You will be asked something you have no story for. The honest answer — “I haven't been in exactly that situation; the closest is ___” — followed by a real story told well, scores better than an invented one every time. The interviewer is trying to learn what you are like to work with, and the most useful thing you can show them is someone who tells the truth when it would be easier not to.
Where to go from here
This is the last post in the track. If you are preparing for a loop, the technical half lives next door: the System Design track covers the design round from estimation to full case studies, and its last post, System Design Interview Questions, is the technical counterpart to this one. Start back at building your story bank if you have not written yours yet. It is the single most valuable hour of preparation in this whole track.