The Questions You'll Almost Certainly Be Asked for Your Role

Last week we went through how to turn a job description into a list of likely interview questions. That gets you the questions specific to the posting. But there's a second set that turns up no matter what the posting says, because interviewers for your kind of role have asked them a hundred times and they work. Those are the ones this post is about.

The good news is that the list is short. The less good news is that because everyone knows these questions are coming, a flat answer stands out far more than it would for a question you couldn't have predicted.

The five that come up in every interview

Role doesn't matter for these. Expect all of them.

• "Tell me about yourself." Not an invitation to read your resume back. Three parts: what you do now, the one or two things from your past that matter for this role, and why you're sitting here. Under two minutes.
• "Why this role?" or "Why us?" They're checking you read the posting and looked at the company. Name something specific: a product, a problem they're solving, a thing in the description you want to do more of.
• "Why are you leaving?" or "What are you looking for?" Keep it forward-facing. What you want more of, not what you're escaping.
• "Tell me about a time something went wrong." Every interviewer has a version of this. They want the decision you made under pressure and what you changed afterwards, not a story where nothing was your fault.
• "What questions do you have for us?" We covered this last week: ask about the posting, not the perks.

The ones your role guarantees

Beyond those five, each role has its own standard set. These are the ones that show up almost every time.

Software engineers

• Walk me through a system you built or significantly changed. Why those choices?
• Tell me about a bug that was hard to find. How did you find it?
• How do you decide what to test, and what not to?
• Describe a disagreement in a code review and how it ended.

Product and project managers

• How do you decide what to build next when everything is a priority?
• Tell me about a feature or project that failed. What did you learn?
• How do you handle a stakeholder who wants something you think is wrong?
• How do you know a launch was successful?

Data and analytics

• Walk me through an analysis that changed a decision.
• Tell me about a time the data was wrong or incomplete. What did you do?
• How do you explain a technical result to someone non-technical?

Marketing and sales

• Tell me about a campaign or deal you're proud of. What were the numbers?
• Describe a quarter where you missed target. What happened?
• How do you work out which channel or account to prioritise?

Operations, finance and support

• Tell me about a process you improved. How did you measure it?
• Describe a time you had to deliver bad news or push back on a request.
• How do you handle a backlog you can't clear?

If your role isn't listed, the pattern still holds: one question about the work you're proudest of, one about something that went wrong, one about how you make decisions, and one about working with people who don't report to you.

Why "easy" questions catch people out

None of these are hard to understand. They catch people because the answers are generic by default. "Tell me about a project you're proud of" gets a description of the project. The interviewer didn't ask about the project. They asked about you: what you decided, what you'd do differently, and what the result was.

The fix is the same one we used for resume bullets that prove impact: lead with what changed, then explain how you did it. A project description is a starting point. A result with your decision behind it is an answer.

Build the answers from stories you already have

You don't need a new story for every question. Most people have five or six solid ones that between them cover almost everything in the lists above. A project that went well. One that didn't. A disagreement. A time you had to learn something fast. A decision you made with incomplete information.

Write each one down in four or five lines: the situation, what you decided, what happened, and what you'd change. Then go down the question list for your role and tag each question with the story that answers it. If one story is doing all the work, find another; interviewers notice when every answer leads back to the same project.

If you tailored your resume for this posting, the bullets you kept are a good guide to which stories matter most here.

It's the follow-up that decides it

The first answer to a standard question is the easy part. You saw it coming and you had a story ready. The second question is where it's decided: "Why that approach and not the other one?", "What would you do differently?", "Who else was involved, and what did they do?"

You can't script follow-ups, but you can prepare for the kind. For every story, know the trade-off you made, the alternative you rejected, and the part that was your call rather than the team's. If you can answer those three, most follow-ups are already covered.

Practise against your own resume and this posting

Reading a list is not the same as answering out loud with someone waiting. The ResumeLens mock interview takes your resume and the job posting and runs a session built from both: the questions an interviewer for this role would ask, the ones specific to this description, and follow-ups that respond to what you actually said. After each answer you get a score, what worked and one thing to fix, and at the end a readiness report with the single most useful thing to work on before the real one.

Start a mock interview with your own resume and the posting you're preparing for. It works in any language, there's a free tier and no card is needed.