How to Answer: Why Do You Want This Role? (Interview Examples)
Recruiters write 'why do you want this role?' into every screen because it filters out the mass-appliers in under a minute. A flattery-heavy answer confirms you did not do the research. A specific one confirms you did.
Practice this out loud. Get scored in 30 seconds.
Voice mock interview with AI scoring — built because ChatGPT can chat, but can't pressure-test you or grade you.
Try the demo →Why this matters
This question tests whether you understand what the job actually requires on a day-to-day basis, not just what the company does at a headline level. Hiring managers have seen hundreds of candidates say 'I love your mission' or 'I want to grow with a high-impact company.' That kind of answer is indistinguishable from every other candidate and tells the interviewer nothing about whether you are the right person for this specific role. The candidates who advance are the ones who cite something specific from the job description, tie it to a concrete thing they have actually done, and make a clear logical argument for why those two facts together make them a strong fit. Your answer to this question also signals your motivation to stay: candidates who articulate a specific reason for wanting the role are statistically more likely to stay engaged once hired.
What to think about
- Your job description mentions rebuilding the onboarding flow for enterprise clients. I spent the past 18 months doing exactly that at my current company, cutting time-to-value from 45 days to 17. That is the specific problem I am most energized by, and your product is at the stage where getting it right compounds over years.
- I want this role because it sits at the intersection of technical depth and customer communication, which is exactly where I have been building my skills. I have been the person who translates engineering trade-offs into business language on my current team, and I am looking for a role where that is the core job, not a side task.
- The fact that this team is moving from a services model to a product model is the main reason I applied. I made that transition once before and understand both sides deeply. I want to be in the room where that architectural shift happens, not just executing on a roadmap that is already decided.
- Your platform serves mid-market operations teams, which is the exact buyer I know best after four years of selling into that segment. I understand their objections, their budget cycles, and what it takes to get a champion to push a deal through procurement. That knowledge is not easy to replicate and it maps directly to what you need.
- I want this role because your company is three to five years ahead of where most competitors are on the infrastructure side. Working here means I will be solving problems that others have not hit yet, which is the kind of learning curve I need at this stage of my career.
The framework
Use the 2x2 specificity framework. Identify two specific aspects of this particular role that genuinely interest you — pull them directly from the job description or your research, not from the company homepage. Then pair each one with something you have actually done that demonstrates you understand what that aspect requires. The result is four data points: two role specifics, two personal proof points. Write them out before the interview so you can deliver them conversationally. The answer should run 60 to 90 seconds. Every sentence should pass the test: 'Could I say this exact sentence about a different company?' If yes, cut it or make it more specific.
Common mistakes
- Opening with flattery: 'I have always admired your company' or 'Your mission really resonates with me.' These are throat-clearing phrases that contain zero signal. Skip them and open with a specific.
- Copying the job description back at the interviewer. Saying 'I want this role because you need someone with strong analytical skills and I have those' is a paraphrase of the JD, not an answer. You need to connect the requirement to a concrete example from your own experience.
- Citing vague growth motivations: 'I am looking to grow and take on more responsibility.' Every candidate wants this. It does not differentiate you and it does not tell the interviewer anything about whether this specific role is the right context for that growth.
- Talking only about what you want to get, never about what you want to contribute. The interviewer is trying to hire someone who will solve a problem for them. Your answer should make that connection explicit.
- Mentioning compensation, stability, or location as a primary motivation. Even if these are real reasons, they signal that you are optimizing for yourself rather than for fit with the role.
Bad answer vs strong answer (scored)
Weak answer
I have always admired this company and I think the culture is a great fit for me. I am really excited about the opportunity to grow here and I believe my skills in communication and problem-solving would be a great contribution to the team. I am looking for a place where I can make an impact.
What's wrong
- Every sentence is generic and could apply to any company in any industry. There is not a single detail pulled from the job description, the company's product, or the candidate's actual experience.
- The answer is entirely self-focused on growth and fit without articulating what specific problem the candidate would solve for the team.
- Phrases like 'great culture fit' and 'make an impact' are filler. They signal that the candidate has not done substantive research on what the role actually requires.
Stronger answer
Two things specifically drew me to this role. First, your job description calls out rebuilding the client reporting infrastructure, and that is a problem I have hands-on experience with. At my current company I led a similar project from scoping through rollout, and we cut the time finance teams spent on monthly closes from three days to four hours. I know the stakeholder management challenges, the technical constraints, and the pitfalls that are not obvious until you are inside the problem. Second, your team is at a scale where decisions I make will affect the core product, not just a feature on the edge. That direct impact is what I am looking for at this point in my career, and it is specific to where your company is right now.
Related practice
Quick answers
What if I genuinely do not know much about the role yet?
Do not improvise. Before the interview, re-read the job description carefully, look up recent news about the company, and if possible find anyone who works there to ask about day-to-day realities. If you are in an early screening call and have limited information, it is entirely acceptable to ask the recruiter one or two clarifying questions about the scope of the role before giving your answer. Specificity earned through research always outperforms generic enthusiasm.
Is it okay to mention compensation as a reason I want the role?
Not in this question. Even if pay is a genuine motivator, leading with it signals that you are optimizing for yourself rather than for fit with the team's needs. Save compensation conversations for when the interviewer raises them or for the offer stage. In this question, focus entirely on the work itself and the specific problems you would be solving.
How specific is too specific? Can I come across as over-prepared?
There is no such thing as too specific in this context. Interviewers cannot distinguish between 'over-prepared' and 'genuinely interested' — both look identical from the outside, and both are positive signals. What reads as awkward is reading from notes or citing details so obscure that the interviewer cannot verify them. Stick to details that are in the public job description or on the company website, and deliver them conversationally.
I keep getting rejected after the first screen — could this question be why?
It often is. First-screen rejections frequently come from generic answers to questions like this one. Odin puts you through a live mock interview and scores your answer on specificity, structure, relevance, and delivery. Most candidates discover in their first session that their answer sounds far more generic out loud than it did when written. Getting that feedback before the real screen — not after — is the difference between knowing your answer and knowing it holds up when someone is actually listening.