Why Do You Want to Work Here?

juniormust knowfreq 88%

answer

one specific hook, not three vague ones
prove you actually engaged with it
bridge the hook to your own work
what you want to contribute here
why now, as a pull not a complaint

basics

~20 s

Tests whether you chose this employer deliberately or are mass-applying. Answer with one specific, checkable hook about their work, evidence you engaged with it, the bridge to something you have actually done, and why the move makes sense now.

how to answer

5 beats

the hook, named in one sentence
Open with the single most specific thing that drew you: a technical decision they published, a product you have used, a constraint their scale creates. Do not stack three reasons. One hook you can defend under follow-up is stronger than a list.
the evidence that you actually engaged with it
Prove the hook is real by saying something only someone who looked would know, and offer a small opinion about it. A detail plus a reaction is the difference between research and recitation.
the bridge from that hook to your own work
Connect the hook to a problem you have personally worked on, with one concrete number or outcome. This is what turns interest into fit, and it is the beat most candidates skip entirely.
what you want to contribute here
Say what you would want to work on and what you bring to it, sized to your level. Keep it forward-looking and modest in claim: an area, not a promotion plan.
why now
Close with the timing, phrased as a pull toward this rather than an escape from your current job. One sentence is enough, and it should sound like a decision you made rather than a circumstance that happened to you.

your answer

4 story prompts

pick a story

Write down the one thing you read, used or took apart from this company that you can describe from memory.
Name a problem from your own work that their product, stack or scale touches directly.
Pick your reason for moving now and check that it names a pull, not a complaint.
Draft one sentence on what you would want to own here in your first six months.

draft and rehearse your own answer in a learn session

go deeper

This probes motivation and intent. The interviewer wants to know whether you chose this employer deliberately or are running a volume application process, because deliberate candidates accept offers, ramp faster and stay longer. A strong answer proves you engaged with something specific about the work, connects it to what you have actually done, and explains why the move makes sense now.

at junior level

That is why I read your write-up on content-addressed build caching twice. The part about invalidating on content instead of timestamps was the clean version of something I had been doing by hand. Here that is the product rather than a side quest I have to justify.

The other pull is the shape of the work. Your team ships one system and lives with it for years. I hand things off after a few months and never learn whether they held up, and I want to own something long enough to be wrong about it and fix it.

I am looking now because I have taken what short engagements can teach me, and I would like the next couple of years to go deep on build systems with people who have been at it longer than I have.

I work at a consultancy, so my last eighteen months have been client infrastructure — five of us on a platform pod, moving to a new engagement every couple of months. The part I kept gravitating toward was build tooling. On one engagement the delivery slipped eighteen days, and a real chunk of that was that every container image took 21 minutes to produce, so nobody could iterate. I spent three weeks restructuring the layers and the caching and got that down to 4 minutes 50, and it was the first time I felt like I had changed how a whole team worked instead of closing a ticket. That is why I read your write-up on content-addressed build caching twice. The part about invalidating on content instead of timestamps was the clean version of something I had been doing by hand. Here that is the product rather than a side quest I have to justify. The other pull is the shape of the work. Your team ships one system and lives with it for years. I hand things off after a few months and never learn whether they held up, and I want to own something long enough to be wrong about it and fix it. I am looking now because I have taken what short engagements can teach me, and I would like the next couple of years to go deep on build systems with people who have been at it longer than I have.

why this lands

The hook is falsifiable — a named technical decision, described accurately, with a small opinion attached — and it is bridged to work the speaker actually did, with build-time numbers that make the interest concrete. Generic admiration for the culture, or no reason for the timing, would downlevel this immediately.

at middle level

Two things pull me toward you specifically. The first is that build infrastructure here is something you sell rather than absorb as overhead, and that changes every incentive around it. I have spent years arguing for build time as a line item against billable hours, and I would rather work somewhere that argument is already settled.

The second is how you write about decisions. Your post explaining why you kept a single build graph instead of splitting it per team reads like it was written by people who had to live with the consequences, and it matched what two engineers here told me when I asked them what they would change.

What I would bring is the migration side. I have moved a lot of teams onto tooling they did not ask for, and the hard part is never the tooling. I want to do that once, properly, for one company, instead of a shallower version of it every few months.

I have owned build and CI across my agency's client work for about three years — seven active engagements at a time, each with its own opinions about images. Last year I consolidated eleven repositories onto a shared set of base images and one pipeline; the median image build fell from 12 minutes 10 to 3 minutes 15, and the part I am prouder of is that the pattern survived after I rolled off. Two things pull me toward you specifically. The first is that build infrastructure here is something you sell rather than absorb as overhead, and that changes every incentive around it. I have spent years arguing for build time as a line item against billable hours, and I would rather work somewhere that argument is already settled. The second is how you write about decisions. Your post explaining why you kept a single build graph instead of splitting it per team reads like it was written by people who had to live with the consequences, and it matched what two engineers here told me when I asked them what they would change. What I would bring is the migration side. I have moved a lot of teams onto tooling they did not ask for, and the hard part is never the tooling. I want to do that once, properly, for one company, instead of a shallower version of it every few months.

why this lands

Signal comes from the bridge beat: a specific hook about a published decision, checked against people the speaker actually talked to, and tied to migration work they own with a number that survived their departure. Dropping the contribution beat, or letting the hook stay at the level of admiring the engineering culture, would downlevel it.

for a junior

Your hook is allowed to be learning-shaped: one thing you read, used or took apart, described accurately. Depth you do not have is obvious, so pick a smaller hook and be exact about it rather than performing familiarity with a whole technical strategy.

for a middle

Tie the hook to the problem you already work on daily, and be ready to say what you would contribute in the first months. At this level the interviewer is checking that you compared options on technical grounds and did not just answer the recruiter who called first.

for a senior

Show judgment about the company stage and its constraints: why this problem is worth several years of your life, what you would want to own, and what you accept about the environment. Naming a tradeoff you are knowingly taking reads as maturity, not doubt.

for a principal

Frame it as a bet: where the company sits on its curve, where your leverage would be, and what has to stay true for the bet to pay off. Keep it about the company and its problem space, not a list of the titles and headcount you want.

saying these in an interview costs you the question

Praise that would fit any employer in the industry
Reciting the mission statement back with no personal connection to it
Naming a product or a post you clearly have never opened
Making it entirely about what you get: pay, brand, remote, visa
Badmouthing your current employer instead of naming a pull toward this one
No reason for the timing, so the move sounds accidental

What else did you look at before you applied here?
Answer honestly and briefly. Describe the shape of what you considered and the criterion that filtered it, without naming other employers or turning it into leverage. One sentence of comparison is enough, then return to what is specific about this place.
What worries you about joining us?
Have one real answer. Pick a genuine, non-fatal concern you can state calmly, say what evidence would resolve it, and ask them for that evidence. Claiming no concerns at all reads as either flattery or a candidate who has not thought about the decision.
If we made you an offer today, what would make you say no?
Name a condition, not a person and not a number. Say what would have to be true of the work, the scope or the way decisions are made for the answer to be no, and keep the tone matter-of-fact. This is a fit probe, not a negotiation opening.

One answer, different entry points

This prompt has more wording variants than almost anything else in a loop:

why do you want to work here,
what interests you about us,
why did you apply,
what do you know about what we do,
why us out of everyone hiring.

Treat them as one answer with different entry points.

The recruiter screen version is short and warm;
the hiring-manager version wants technical specificity;
the executive or founder version tends to want to hear your read on the company itself.

Prepare one ninety-second answer and learn to cut it to thirty seconds.

Genericity, not rudeness

The failure mode is almost never rudeness. It is genericity. Two answers illustrate the gap.

Weak: I have heard great things about the culture here, the mission really resonates with me, and I think it would be an amazing place to grow. Nothing in that is false, and nothing in it is about this company. Swap the employer and the sentence still parses, which is exactly the test the interviewer is running in their head.
Strong: I read your write-up on content-addressed build caching and it described the problem I had been solving by hand for two years; this is the only place I have looked at where that is the product rather than overhead.

The second answer is falsifiable, which is what makes it credible.

Four kinds of evidence

There are four kinds of evidence you can build a hook from, roughly in descending order of strength.

First, direct use: you have run their product, read their code, filed an issue, built on their API.
Second, technical publication: an engineering post, a talk, an open-sourced tool, a paper, where you can name the specific decision and say why it interested you.
Third, people: conversations with current or former employees, including the ones you have had in this very process, quoted concretely rather than as they seem great.
Fourth, market position: what the company is betting on, why the stage or the constraint is interesting.

Mission language is the weakest evidence and should never carry the answer alone, though it can close it.

One hook, well-supported, beats three thin ones

Interviewers read a list of reasons as hedging. Pick the hook you can survive a follow-up on, because there is almost always a follow-up: what did you think of it, what would you have done differently, what did you disagree with. If you cannot hold a two-minute conversation about a hook, it is not your hook.

How the bar shifts

The bar shifts with level in a predictable way.

Early-career answers are allowed to be about learning and about a specific thing you found interesting; nobody expects a strategic read.
Mid-level answers should connect the hook to work you have done, because you now have work to connect it to, and should hint at what you would contribute.
Senior answers are expected to show that you understand what is hard about the company situation, not only what is attractive about it, and to name what you would own.
Principal answers are read as a judgment call about the company itself, so they should carry a thesis and the conditions under which it holds.

Two mechanics are worth rehearsing

First, the why-now clause. Motivation is a vector, and interviewers listen for whether you are running toward something or away from something. Both can be honest, but lead with the pull.
Second, the close. End on a forward-looking sentence about what you want to do here rather than trailing off after your admiration, and if you are given the opening, hand the interviewer a question that follows from your hook. That turns a set piece into a conversation, which is the outcome you actually want.

## One answer, different entry points This prompt has more wording variants than almost anything else in a loop: - why do you want to work here, - what interests you about us, - why did you apply, - what do you know about what we do, - why us out of everyone hiring. Treat them as one answer with different entry points. - The **recruiter screen** version is short and warm; - the **hiring-manager** version wants technical specificity; - the **executive or founder** version tends to want to hear your read on the company itself. Prepare one ninety-second answer and learn to cut it to thirty seconds. ## Genericity, not rudeness The failure mode is almost never rudeness. It is **genericity**. Two answers illustrate the gap. - **Weak**: I have heard great things about the culture here, the mission really resonates with me, and I think it would be an amazing place to grow. Nothing in that is false, and nothing in it is about this company. Swap the employer and the sentence still parses, which is exactly the test the interviewer is running in their head. - **Strong**: I read your write-up on content-addressed build caching and it described the problem I had been solving by hand for two years; this is the only place I have looked at where that is the product rather than overhead. The second answer is **falsifiable**, which is what makes it credible. ## Four kinds of evidence There are four kinds of evidence you can build a hook from, roughly in descending order of strength. 1. First, **direct use**: you have run their product, read their code, filed an issue, built on their API. 2. Second, **technical publication**: an engineering post, a talk, an open-sourced tool, a paper, where you can name the specific decision and say why it interested you. 3. Third, **people**: conversations with current or former employees, including the ones you have had in this very process, quoted concretely rather than as they seem great. 4. Fourth, **market position**: what the company is betting on, why the stage or the constraint is interesting. Mission language is the weakest evidence and should never carry the answer alone, though it can close it. ## One hook, well-supported, beats three thin ones Interviewers read a list of reasons as hedging. Pick the hook you can survive a follow-up on, because there is almost always a follow-up: what did you think of it, what would you have done differently, what did you disagree with. If you cannot hold a two-minute conversation about a hook, it is not your hook. ## How the bar shifts The bar shifts with level in a predictable way. - **Early-career** answers are allowed to be about learning and about a specific thing you found interesting; nobody expects a strategic read. - **Mid-level** answers should connect the hook to work you have done, because you now have work to connect it to, and should hint at what you would contribute. - **Senior** answers are expected to show that you understand what is hard about the company situation, not only what is attractive about it, and to name what you would own. - **Principal** answers are read as a judgment call about the company itself, so they should carry a thesis and the conditions under which it holds. ## Two mechanics are worth rehearsing 1. First, **the why-now clause**. Motivation is a vector, and interviewers listen for whether you are running toward something or away from something. Both can be honest, but lead with the pull. 2. Second, **the close**. End on a forward-looking sentence about what you want to do here rather than trailing off after your admiration, and if you are given the opening, hand the interviewer a question that follows from your hook. That turns a set piece into a conversation, which is the outcome you actually want.

Why Do You Want to Work Here?

explore

questions