Why This Company, Questions to Ask and the Interview-Day Routine

"So, why do you want to work with us?"

It sounds like a warm-up question. It is often an evaluation. The interviewer is checking whether you know what the company does, whether you chose it or applied everywhere, and whether you will stay engaged. Many candidates answer with a sentence that could be said about any company: "You're a leading company with a great culture, and I'm passionate about technology." It tells the interviewer that you did not look.

You did look; that was the last two articles. This one makes sure it shows, and gets you through the interview day calmly.

• A structure for a specific, honest "why this company" answer.
• How to build it from research with AI, and keep it in your own words.
• How to prepare questions for your interviewers.
• A one-page brief and a routine for the day before and the day itself.
• What to do in the two hours after the interview.

A strong answer has three parts:

1. Something specific about their work. A product decision, an engineering problem they wrote about, a domain they serve, or something you noticed using the product. Specific enough that it could not be said about a competitor.
2. A connection to you. Something you built, studied or experienced that relates to it. Honest, even if small.
3. What you want to learn or do there. Concrete: the kind of problems, the stack, the domain.

About 60 to 90 seconds spoken, which is roughly 150 to 200 words.

Put together:

What drew me to [company] is the payouts work. Your post on retrying failed payoutsexplained how you avoid paying a merchant twice when a bank times out, and that'sexactly the problem I ran into in my own project: a payment service where tworetries could arrive at the same moment. I solved it with idempotency keys and aunique constraint, and I'd like to learn how that works when the volume is realand the banks are many. I also tried your payment links in test mode, and theflow was simple enough that I could imagine a small seller using it without help,which is the kind of product I'd like to work on.

That answer could only be given about one company, by one candidate. It is also completely true, which matters because the interviewer may follow up on any part.

Use your cited research notes (article 27), not the assistant's general knowledge of the company:

Below are my research notes about [company], with sources, and my background.Help me build a "why this company" answer.1. Suggest three specific things from MY NOTES that I could name (cite the note),   and for each, an honest connection to my background, or "weak connection".2. Draft a 150 to 200-word spoken answer using the strongest one.   Structure: their specific work, my connection, what I want to learn.3. Do not use: "passionate", "great culture", "innovative", "leading",   "dream company". Do not add any fact not in my notes.My notes: [paste]My background: [paste]

Then put the draft away and say the answer out loud from memory three or four times, in your own words. The goal is to know the three points, not to recite a paragraph. A memorised script sounds memorised.

• "Why this role?" The same structure, focused on the role's work (for example, platform tools, data pipelines, testing).
• "Why should we hire you?" Two pieces of evidence that match the role's main needs, plus how you learn.
• "Where else are you interviewing?" Honest and brief: "A few product companies in [domain]; this role is high on my list because…" You do not need to name companies.
• For services companies and large employers: specifics still help. Mention a practice area, a client domain, their training programme or a technology they publicly invest in, and why it matters to you.

Most interviews end with "Do you have any questions for us?" "No, thank you" wastes a chance. Prepare about six questions, then use the two or three that fit what you discussed.

Good questions cannot be answered from the website, and show you are thinking about doing the job well:

• About their work: "Your post on [topic] described [decision]. How has that held up since?"
• About the team: "What does a new engineer on this team usually work on in their first few months?"
• About growth: "What separates someone who does well in their first year here from someone who struggles?"
• About practices: "How does code review work on your team? How long does a change usually take to reach production?"
• About the product: "When I tried [feature], I noticed [observation]. I was curious how the team decided on that."
• About the interviewer: "What's been the most interesting problem you've worked on here?"

Avoid, in technical rounds: salary, leave and benefits (those belong with HR, later), and questions answered on the homepage.

From my research notes on [company] (below), suggest 8 questions I could askinterviewers at the end of a fresher interview. Each must refer to somethingspecific in my notes, cannot be answered from the company's homepage, and isphrased with curiosity. Mix: their engineering work, the team's practices,how new engineers grow. Avoid salary and benefits.[paste notes]

Pick six and rewrite them in your words.

Condense everything into one page you will read on the morning of the interview. It is a memory aid, not a study document.

COMPANY BRIEF: [Company], [role], [date and time], [round and format]1. What they do, in one plain sentence:2. The team or area (if known):3. Three specific things I know (with source):   -   -   -4. Likely technical topics (from JD and reports):5. My "why this company" in three points:6. My two best stories for this company's values (article 36):7. Six questions to ask (use two or three):8. Logistics: link, interviewer names, recruiter's phone, editor or tool, language

• Read the brief and your "why this company" points. Say the answer aloud once.
• Review, do not learn. Light practice on likely topics is fine; new topics are not.
• Prepare the set-up: for a video interview, test the link, camera, microphone and the coding or drawing tool; for an in-person interview, the route, travel time, ID, a printed resume and a pen.
• Choose clothes that are neat and comfortable. For most tech interviews, a clean shirt or top is enough unless told otherwise.
• Sleep at a normal time.

• A short warm-up (20 to 30 minutes): one easy problem, or explain your project aloud once.
• Read the brief.
• Ten minutes before a video call: join or open the link, close other apps and notifications, have water, a notebook and pen, your resume open and the job description handy. Sit somewhere quiet with light on your face.
• If something goes wrong (the link fails, the internet drops), message the recruiter immediately with your phone number. Interviewers know technology fails; silence is worse than a brief note.

While it is fresh, write down:

• each question or problem, as well as you remember it;
• your approach and where you got stuck;
• moments that went well and moments that felt weak;
• anything the interviewer seemed to care about.

These notes are the raw material for diagnosing rejections later (article 43), and they help with the next round. Keep them private; do not post interview questions publicly where the company's terms forbid it.

A brief thank-you email or LinkedIn message to the recruiter, or to interviewers if you have their contact details, is courteous. It will not rescue a weak interview, and its absence will rarely hurt you; but a specific one leaves a good impression.

Hi [Name], thank you for the conversation today about [role]. I enjoyed discussing[specific topic], and afterwards I realised I could have [one specific improvement,e.g. used a heap to avoid re-sorting]. Thanks again for your time.[Name]

Keep it under 80 words, specific and free of pressure ("hoping for a positive response" adds nothing). Let an assistant check the tone if you like, but write it yourself.

• A "why us" answer that fits any company.
• A memorised paragraph delivered word for word.
• Claims about the company you cannot source.
• "No questions."
• Learning new topics the night before instead of reviewing.
• Not writing anything down afterwards, so lessons are lost.

What draws me to [company] is the work on live delivery tracking. Your engineeringtalk on handling location updates from thousands of riders explained why you movedfrom polling to pushing updates, and I hit a small version of that problem in myorder-tracking project, where I used server-sent events and had to handlereconnections. I'd like to work on that kind of real-time problem at real scale,and learn how your team tests systems where events arrive out of order.

• Next: What Technical Rounds Look Like and How to Solve Out Loud prepares you for the rounds themselves.
• For common HR questions and answers, see Common HR Interview Questions and How to Answer Them (With Examples).
• For interview practice with AI, see Interview Preparation and Mock Interviews with AI.