A good answer could only be said to this company: one specific thing they do, one piece of your experience that fits it, and one thing you want to get better at that this job offers. If a line would work for any employer, replace it.
What the question is really checking
Amazon explains its own version of the question plainly in an interview-tips article built from its recruiters' and hiring managers' advice. One Amazon leader quoted there notes that many candidates talk about being excited to work for a large, innovative company, and says: “What I really want to know is why Amazon fits into your specific career path.” The same article says interviewers want to hear what you would contribute and what you want to learn. That is a useful frame for any employer, because it turns a flattery question into a fit question.
Three signals sit underneath. Specificity shows you did the homework and are choosing this company, not spraying applications. Fit connects something they need to something you have already done. Direction shows the job moves you toward a goal, which makes it likelier you will stay and engage. An answer that names the company's mission in their own words but contains nothing about you hits none of the three.
Research sources that produce specific sentences
Time-box the research to about 45 minutes and aim to leave with three facts you can say out loud: what the team builds and for whom, one technical or business constraint they are working against, and one choice they made that you have an opinion about. The job description is the best starting point; Amazon's recruiters suggest preparing stories against its requirements, and the same mapping feeds this answer.
For public companies, the annual Form 10-K is underused by engineers. Investor.gov describes it as a comprehensive overview of the business and points readers to the business description and to Risk Factors, which list significant risks generally in order of importance. Two pages there often explain why a team you are interviewing with exists, and they give you vocabulary the hiring manager already uses. Read them with one question in mind: which of these products or risks does this role touch? Private companies publish less, so lean harder on the product, the docs and the recruiter call.
- Engineering blog and conference talks: one recent post, the problem, the constraint and the decision.
- The product and its docs: sign up, read the API reference and changelog, note one thing done well.
- The job description: match each requirement to a story from your work.
- Open-source repositories, public postmortems or status pages, if the company has them.
- Form 10-K for public companies: the business description and Risk Factors.
- Values or principles pages, such as Amazon's Leadership Principles: pick one that matches a real story of yours.
- The recruiter call: ask what the team's biggest problem is this year.
A three-part formula: what they do, what you've done, where you're going
Build the answer from three parts in this order. First, one specific thing they do, in your own words, ideally something the interviewer's team owns. Second, a piece of your experience that matches it, with one concrete result. Third, the capability you want to grow and why this role offers it. Three to five sentences, 45 to 60 seconds. Stop there and let the interviewer pull on whichever thread interests them.
Order matters. Starting with them signals that you did the research; ending with your growth signals direction without making the answer about perks. Keep company praise to one clause. Interviewers already know their company's strengths, so an accurate observation about a trade-off they made says more than an adjective such as innovative or world-class. If you have a genuine question about that trade-off, end with it; it turns a monologue into a conversation.
1. What they do: "You're moving <system> to <approach> for <users>."
2. What I've done: "I did <similar work> and it led to <result>."
3. Where I'm going: "I want to get better at <skill>; this role <offers it because ...>."Sample answers for three kinds of companies
Big tech platform team: “Your team runs the storage layer that the rest of the company builds on, and the talk your tech lead gave on migrating metadata to a new consistency model is the clearest write-up of that trade-off I've read. I spent the last two years on a smaller version of that problem: I led our move from a single Postgres primary to a sharded setup, and cut p99 write latency by a third. I want to work on the same class of problem at a scale where the failure modes are rarer and harder, and this team is one of the few places that has them.”
Early-stage startup: “You're about thirty people building a developer CLI, and I've used it for a year; its plugin API is why I built our internal deploy tool on top of it. At my current job I'm the engineer who ends up owning whatever is unowned, from CI to billing webhooks, and I like that. I want a role where breadth is the job description rather than a side effect, and where I can talk to the users of what I ship every week.”
Fintech or another regulated company: “You process card payments for marketplaces, so correctness and auditability matter as much as speed. I spent last year rebuilding our refunds flow with idempotency keys and a reconciliation job, and I learned how much design changes when every state transition must be explainable to an auditor. I'd like to deepen that, including working inside a PCI DSS scope, which my current company avoids by outsourcing card handling.” PCI DSS is the payment card industry's baseline of technical and operational requirements for protecting account data. The companies, talks and results in all three samples are invented; replace every detail with facts from your own research and work.
When the honest reason is pay, or you need a job
Wanting more money or needing a job after a layoff are normal reasons, and you do not have to pretend otherwise. You also do not have to lead with them, because this question asks why this company among the ones that would also pay you. Find the true secondary reasons: the stack, the domain, the scale, the team's practices, remote setup or stability. Answer with those, honestly, and keep compensation for the conversation designed for it, usually with the recruiter.
If you were laid off, one neutral sentence is enough: “My team was cut in the March reduction, so I'm choosing carefully where to go next, and this role stands out because…” Then continue with the formula. Never invent passion you cannot back up with a single specific detail; a follow-up question will expose it. Honest and specific beats enthusiastic and generic.
Mistakes and the generic lines to replace
The common mistakes are predictable: reciting the About page, flattery without evidence, talking only about what you will get (brand, perks, title), criticizing your current employer, running past two minutes, and reusing one answer for every company. The quickest fix is the table below. Read your draft aloud and, for every sentence, ask whether a competitor's name could be swapped in without changing anything. If it could, rewrite it with a fact from your research.
| Generic line | Specific replacement |
|---|---|
| “You're an innovative industry leader.” | “Your post on sharding search matches work I did last year.” |
| “I love your product.” | “I've used your CLI daily; its plugin API is why I built on it.” |
| “You have a great culture.” | “Your public postmortems show the review process I want.” |
| “I want to grow.” | “I want to own on-call for a high-volume service; this role does.” |
| “It's a great opportunity.” | “The role mixes backend and data work, my next direction.” |
Practice: draft, cut, and adapt for each round
Draft the answer for each company separately, then cut it to under a minute. Before the final round, update it with something you learned from earlier interviewers, such as a problem the team mentioned; that is the most specific material you will ever have. Keep a short note per company with your three facts so you can refresh them right before the call.
This answer usually follows “Tell me about yourself,” so the two should hand off cleanly: the opener explains your path, and this answer explains why the path leads here. The guides below cover that opener, where to find engineering blogs worth reading, and how to prepare the rest of the behavioral loop.
Quick answers
Frequently asked questions
How long should the answer be?
About 45 to 60 seconds, or three to five sentences. That is long enough for one fact about them, one piece of evidence about you and one growth goal, and short enough to leave room for the interviewer's follow-up questions.
Is it okay to say I'm interested in the salary?
It is fine to care about pay, but it does not answer why this company in particular. Give work-related reasons here and discuss compensation with the recruiter at the stage meant for it, where being direct about your expectations is normal and expected.
What if I can't find much about the company?
Small or stealth companies often publish little. Anchor on what the recruiter and job description told you about the team and the problem, use the product if you can, and ask a sharp question back. Being honest about what you could not find beats guessing.
Should my answer change between the recruiter screen and the final round?
Keep the core, but deepen it. In the screen, focus on role fit and why you applied. In later rounds, add what you learned from earlier interviewers, such as a problem the team described, because it shows you listened and are still choosing them.
Source notes
References and review policy
Information checked on November 7, 2026. Section links identify sources for factual claims and technical explanations. Interpretations, practice scenarios and preparation recommendations are RecallDeck’s editorial work.
From reading to recall
Practice the full interview loop.
RecallDeck schedules the concepts you miss and keeps coding, design, and behavioral fundamentals available when the interviewer changes direction.