Why Do You Want to Join Us? The Question Most Candidates Waste
"Why do you want to join us?"
Most candidates have the same answer. They've skimmed the company's LinkedIn page, so they mention the mission, the growth trajectory, or the cutting-edge technology. "I've always admired this company's work in AI." "Your culture of innovation really appeals to me." "This is a great opportunity to grow." The interviewer nods politely and marks down: generic.
This question shows up in almost every round — sometimes in the first HR screening, sometimes near the end of a technical interview, sometimes twice from two different people. And most candidates treat it as a formality to get past rather than an opportunity to pull ahead.
It is not a formality.
What the question is actually testing
Interviewers are not quizzing you on company trivia. They are trying to resolve two specific concerns.
Will you leave in eight months?
Hiring is expensive — the cost of recruiting, onboarding, and losing a new hire in the first year is typically three to six months of that person's salary. A candidate with a vague or generic "why" is more likely to accept any better offer that arrives, because they didn't really choose this company — they chose a job. Someone with a specific, considered reason for wanting this role at this company is demonstrably more likely to stay. The question is, at its core, a retention filter dressed up as small talk.
Have you actually thought about what you'll be doing?
Candidates who understand the work — not just the brand name on their resume — ramp faster, ask sharper questions on the job, and fit teams better from day one. A specific "why" signals that you've engaged with the actual problem, not just the offer letter.
When an interviewer hears "I love your mission to democratise finance," they learn nothing useful. When they hear "I've been reading your engineering blog and the way your team handles eventual consistency in the payment ledger is exactly the class of problem I want to work on," they learn something real. One is flattery. The other is evidence.
Why most answers fail
Three failure modes, and they're predictable.
The generic compliment. "I've always admired this company for its innovation and culture." True of every company the candidate applied to. Says nothing about why this company specifically.
The résumé echo. "This role aligns perfectly with my skills in data analysis and machine learning." You've just described your qualifications, not your reasons. The interviewer already read your résumé.
The opportunity grab. "This is a great opportunity to learn and grow." True of any offer. It signals you care about what the company can give you, not about the problem you want to work on.
All three fail for the same reason: they are not anchored in anything specific. The test is simple: if your answer works with any other company's name substituted in, it doesn't work at all.
The three-part structure that works
A strong answer has three elements, in this order:
1. Something specific you've noticed about their work. From their product, their engineering blog, their recent announcement, their team's published research, or a real interaction with what they've built.
2. Why that specific thing connects to work you've actually done or are genuinely curious about. Not generic enthusiasm — a concrete thread from your own experience.
3. What you want to build, solve, or understand by being here, stated concretely. Forward-looking and specific, not "learn and grow."
The answer takes 60–90 seconds. It does not need to include the words "culture", "growth", or "innovation" at all.
Worked examples by role
The structure is universal. What goes inside each part changes with the role.
SDE / Software engineering
If you're applying to a product company, read their engineering blog before the interview. Almost every serious product company in India — Flipkart, Meesho, Zepto, Razorpay, Juspay, PhonePe — publishes posts about specific scale problems they've solved. Find one that connects to something you've actually worked on.
"I've been reading Juspay's engineering posts about their Euler orchestration layer — specifically how they handle payment retries across multiple PSPs when one gateway is degraded. At college I built a similar retry-with-backoff system for a small payment integration project, and I hit the same race condition they described. I solved it differently — using an idempotency key at the database level — and I'm genuinely curious whether that approach would have held under their traffic. That's the class of reliability problem I want to spend the next few years on, and from what I can see, this team is working on it at real scale."
One specific blog post. A direct connection to the candidate's own work. A concrete technical question they're carrying into the interview. And a clear statement of what they want to build — not what they want to receive.
Data / Analytics
Data candidates often default to "you work with large datasets and I love data." Stronger is connecting to a specific business decision you've seen the company make publicly, or a specific analytical question about their domain you genuinely want to answer.
"I've been following Meesho's public commentary on how they approach demand forecasting for tier-2 and tier-3 markets — the logistics complexity is completely different from what metro-first companies face, because supply and demand both behave differently. My internship project was about regional demand variability for a CPG brand, and the hardest part was that urban models just broke in smaller towns. I want to work on that problem at real scale. From what I can see, your team is actually close to it, and I don't think I'd find a more useful version of this problem anywhere else."
The candidate has done work adjacent to the company's hard problem. The answer connects their experience to an actual challenge the company faces — not their mission statement.
APM / Product
PM candidates need to show they've used the product, thought about it critically, and have a genuine opinion — not just that they admire the brand.
"I've been a heavy Zepto user for about a year. What I find interesting is how your checkout funnel has to balance the urgency framing of 10-minute delivery with a subscription model that works on habitual, lower-urgency behaviour. Those two UX goals are in tension — urgency and habit-building pull in different directions — and I don't think most quick-commerce products have resolved it cleanly yet. I spent three months working on conversion funnels for a college project and I'm still thinking about that tension. I'd want to work on that problem here, with real traffic behind it."
Strong PM answers contain a genuine opinion about the product — including something that could be better or an open question — without sounding like a complaint. Interviewers respect candidates who've engaged critically with the product, not just admiringly.
Consulting
For consulting, the "why" should connect to a specific practice area, industry vertical, or an engagement type the firm is known for — not generic language about intellectual challenge and steep learning curves.
"I've been focused on operations and supply chain cases in my competition work — reached the national finals of XLRI CaseComp last year on an inventory optimisation problem for a mid-size FMCG client. I know BCG has built out a significant operations and manufacturing practice in India, and several of the cases I've read about in your published reports are on problems I've tried to model myself. I want to work on supply chain problems in manufacturing — not because it's interesting in the abstract, but because I've realised in competition work that it's where my analytical instincts are actually sharpest."
The last line is doing a lot of work: "where my analytical instincts are actually sharpest." That is specific self-knowledge, not flattery. It signals that the candidate has done enough work to know where they are good — not just that they want to be good everywhere.
Before/after: the same candidate, two answers
Before:
"I want to join Razorpay because it's one of India's leading fintech companies and you are growing very fast. The work culture here is excellent and there are many learning opportunities. I have skills in backend development that I believe will be a great fit for your team."
This answer would score in the bottom third of any interviewer's stack. Nothing in it required the candidate to know anything about Razorpay specifically. "India's leading fintech", "growing very fast", "work culture is excellent" — replace "Razorpay" with "Paytm" or "CRED" or "PhonePe" and the answer still makes sense. That is the test: if your answer works for any company, it works for none.
After:
"I've been digging into how Razorpay handles webhook reliability — specifically the retry logic when merchant endpoints are down for an extended period. I built a small webhook delivery system for a hackathon project and the hardest part was deciding when to give up and when to retry without overwhelming a recovering server. I'd genuinely like to understand how you handle that at tens of millions of events a day. That's the class of infrastructure problem I want to build expertise in, and I don't think I can get closer to it faster anywhere else in India right now."
Same candidate. The second answer is specific, shows real research, connects their own project to the company's actual technical problem, and ends with a forward-looking statement that isn't "I want to grow." It's: I want to solve this specific thing, and I've thought about why here is the right place to do it.
Why the strong version works:
- Specific enough that it only applies to Razorpay — not interchangeable.
- Anchored in the candidate's own work — credible, not researched-for-the-interview enthusiasm.
- Company-first framing — focused on a problem they want to solve, not a benefit they want to receive.
- Concrete endpoint — "understand how you handle that at scale" is a real question, not a soft claim about growth.
Common mistakes — and how to fix each
Mistake 1: Complimenting the brand, not the work
"Google is an amazing company and I've always wanted to work here." Generic. "Google's approach to ML model compression in on-device inference is something I've been following closely because I hit a similar memory constraint in a mobile project" is specific. Find something about what the team actually does, not the company's reputation or market position. Brand admiration is easy to fake; technical curiosity is hard to fake and immediately distinguishable.
Mistake 2: Leading with what you'll get
"This role will help me develop my product thinking" is candidate-first. "I want to work on improving retention in the first-30-day cohort, which from what I've read is the hardest problem in your space" is company-first. The company wants to know what problem you'll help them solve. Flip the frame: state what you want to contribute before you mention what you want to learn.
Mistake 3: Stopping at the About Us page
Every candidate who did ten minutes of research knows the company's founding story, tagline, and most recent funding round. That information is on page one of every search result, and every candidate in the pool has it. Go one layer deeper: read the engineering blog, use the product and form a real opinion, look at recent LinkedIn posts from the team, check if the interviewer has written or published anything. Specificity requires research that most candidates don't do because they're preparing ten companies simultaneously and cutting corners on each.
Mistake 4: Sounding rehearsed rather than genuine
You need to prepare this answer — but prepared answers can sound hollow if you've rehearsed enthusiasm for something you don't actually care about. The fix is to find something you are genuinely curious about, not something that sounds impressive. If you find their engineering blog post actually interesting, the answer will sound genuine because it is. If you're performing interest you don't have, a good interviewer will notice. Pick a company you actually looked into, not one you plan to fake enthusiasm for.
What to do before your next interview
Day 1. Open the company's engineering blog, product blog, or recent public announcements and read one piece of content that connects to the role you're applying for. Write down, in one sentence, the most specific thing you found interesting — not the most impressive thing, the most interesting one.
Day 2. Find the thread between that thing and something you've actually done or a problem you've actually thought about. Write a second sentence that makes that connection explicit. If you can't find a thread, you need to look at different content — or consider whether this role is actually a fit.
Day 3. Write your complete answer in 100–120 words, exactly as you'd say it. Read it aloud and time it — it should land in about 60 seconds. Remove anything that could apply to a different company with a name change. What remains is your answer.
Three days, twenty minutes each. Most candidates spend zero. The candidates who do this preparation are immediately distinguishable in the room — not because they sound smarter, but because they sound like someone who actually chose this company, not someone who is trying to get through the question and move on.
If you are preparing for placements and want structured practice on "why us" alongside other behavioral questions, CareerClutch's practice rounds score this question on specificity, relevance, and whether the framing is company-first or candidate-first — so you can hear exactly where your answer sounds generic before the real interview.