How to answer “Why do you want to work here?” and other application questions

“Why do you want to work here?” is the question most people answer worst, because it feels like a formality. It is not. On a form with a hundred applicants, it is one of the few places a reviewer can tell who read the posting and who pasted the same paragraph into forty tabs. A specific answer does not need to be long; it needs to be impossible to send to any other company.

What the reviewer is checking

Whoever reads your answer is looking for three things, usually in under a minute:

• Did you read the posting? Do you mention the actual product, team or problem, or only the company’s name?
• Is there evidence? A claim like “I am passionate about developer tools” is free. “I maintain a CLI with 2,000 weekly installs” is not.
• Can you write? Short, plain and correct beats long and impressive. Many roles involve writing design docs, tickets and messages to customers.

A structure that works for almost any company

Three to five sentences, in this order:

1. One specific thing about them. The product you used, a technical decision from their engineering blog, the market they serve, a line from the posting itself.
2. One specific thing about you that connects to it. A project, a job, a problem you solved that looks like theirs.
3. What you would do there. Tie it to a responsibility listed in the posting.

Here is the difference, for a made-up payments company hiring a backend engineer:

Generic: “I have always admired your company’s innovative culture and I am excited by the opportunity to grow my skills on a talented team.”

Specific: “Your posting says the team is moving reconciliation off nightly batch jobs. At my current job I moved our invoice ledger from a cron job to an event stream, and cut the time to spot a mismatch from a day to a few minutes. I would like to do that work again, at your volume.”

The second one is shorter, names a real responsibility from the posting and backs it with a result. It also gives the interviewer something to ask about.

The other questions that keep coming back

“Tell us about yourself”

Not your life story. Give the version of your career that leads to this role: what you do now, the one or two results you are proudest of, and why this job is the next step. Leave out anything the reviewer can read on your resume unless you are adding context to it.

“Describe a hard technical problem you solved”

Use a simple arc: the situation in one sentence, why it was hard, what you tried that did not work, what did, and the measurable result. The failed attempt is what makes it believable. Pick a problem from the same area as the role: a frontend posting deserves a rendering or state bug, not a database migration.

“Why are you leaving your current role?”

Point forward, not back. “I want to work on a product with external users” or “I want a smaller team where I own more of the stack” is honest and safe. Criticising a current employer on a form you cannot take back rarely helps.

“What are you looking for in your next role?”

Name two or three things this role actually offers, judging by the posting. If the answer you would give honestly does not match the job, that is useful information too.

“Anything else you would like us to know?”

Optional, but a good place for one thing the form gave you no room for: a relevant side project, a link to something you built, or context for a gap. One or two sentences, or leave it blank.

Respect the format

• Word limits are a test. If the box says 150 words, 120 is fine and 300 is a signal that you skip instructions.
• Do not paste your cover letter. Answer the question that was asked. A cover letter answers a different one.
• Mirror the posting’s words where they are true. If the posting says “Kubernetes” and you have run Kubernetes, say Kubernetes, not “container orchestration”. Keyword screens and tired humans both reward it. The ATS match score post explains why.

Reuse answers without sounding copy-pasted

You will see the same ten questions on most applications, so it makes sense to write a strong base answer once and adapt it. The trick is to keep the reusable part (your evidence) apart from the specific part (why this company).

The Lazee extension is built around that split:

• Saved Q&A keeps your best answers, searchable from any application form, with one click to insert. You can manage the library at lazee.dev/profile/saved-questions.
• AI Fill drafts an answer to the open question in the first person, from your real profile. With the job description attached, it ties your experience to what the posting asks for. A one-line instruction (“mention the ledger migration, under 100 words”) steers it before it writes.
• Specific Question Guidance, a box on your profile, tells it what to emphasise in every answer, such as a career change you want to frame or results you always want mentioned.

AI Fill costs 2 credits per answer, or 8 with the job description, and 0 with your own API key or a local model. The free plan includes 200 credits every 30 days.