Short answer
Interviews for these roles test how you think and communicate under pressure, not how many framework definitions you've memorised. Expect a mix of common behavioural questions, role-specific scenarios, and, for enterprise jobs, scaled-Agile situations. The winning move is the same every time: answer with a real story, structured with the STAR method, that shows your judgement and your result. This page gives you the questions and how to handle each.
Key takeaways
- Most questions are scenarios in disguise: they want to see how you'd act, not what you'd recite.
- Structure every story with STAR and spend most of it on the action you took.
- Lead with real delivery: a blocker you cleared, a conflict you defused, a release you steadied.
- For Scrum Master roles they test influence; for IT PM roles they test ownership. Blended roles test both.
The format
How the interview is structured
It varies by company, but most processes for these roles run through the same four stages. Knowing which stage you're in tells you what kind of answer to give.
- Recruiter screen. A quick fit and logistics call. Have a tight two-minute summary of who you are and why this role.
- Behavioural round. "Tell me about a time you..." questions. This is where STAR stories win or lose it.
- Scenario or role-play. A live problem: a resistant team, a slipping deadline, a difficult stakeholder. They want to see your thinking, out loud.
- Panel or final. Often with the people you'd work with. Culture, collaboration, and the questions you ask carry real weight here.
The method
Answer scenarios with STAR
Almost every behavioural and scenario question is best answered with the same four-part structure. It keeps you focused and shows the interviewer your judgement instead of a vague happy ending.
S
Situation. One or two lines of context. No life story.
T
Task. What you were responsible for in it.
A
Action. What you specifically did. The bulk of the answer.
R
Result. The outcome, with a number if you have one.
The most common mistake is spending too long on the situation and rushing the action. Flip that. The interviewer is hiring your actions, so that is where the detail belongs.
Question types
The five kinds of questions, and what each one wants
Almost every interview question is one of five kinds, and each one wants a different shape of answer. Spot the kind first, and you'll know how to respond before you've even started talking. The three big families overlap more than people realise.
The three families overlap. A knowledge question often invites your opinion; a scenario is best answered with a real situation. Follow-ups dig straight into the overlaps.
KnowledgeWhat you know
"What are the Scrum events?"
How to answer: be accurate and concise, then add one line of practical colour so it lands as more than a textbook definition.
OpinionYour view
"Is velocity a useful metric?"
How to answer: take a clear position and give your reasoning, then acknowledge the trade-off. Sitting on the fence reads as having no view at all.
Situational (past)A real time it happened
"Tell me about a conflict you resolved."
How to answer: use STAR with a true story, and spend most of the answer on the action you took, not the setup.
Scenario (hypothetical)How you think
"What would you do if a deadline slipped?"
How to answer: talk through your approach out loud, then anchor it to a real time you handled something similar. Method plus evidence.
Follow-up / probeDepth and honesty
"Why did you do that? What would you change?"
How to answer: stay specific, show honest reflection, and never get defensive. This is where shallow answers come apart.
One shortcut is worth knowing. The behavioural ("tell me about a time") and scenario ("what would you do") versions of a question are really the same question pointed at the past or the future, so a single well-built story usually answers both.
Prepare three to five strong stories and you can answer most behavioural and scenario questions from the same small set.
Free: the Interview Answer Scoresheet
A printable worksheet to break any question into its parts, plan your answer with STAR, and score it out of 25. One sheet per question, with a question-type cheat sheet on the back.
Common questions
Questions you'll almost always get
These come up in nearly every process, for both roles. Tap any to see how to handle it.
Tell me about yourself.+
What they're testing: whether you can frame your story to the role. How to answer: give a 90-second arc, present-to-past-to-future. What you do now, one or two relevant wins, and why this role is the logical next step. Tie it to delivery, not your hobbies.
Why this role, or why agile delivery?+
What they're testing: genuine motivation versus "I needed a job." How to answer: connect it to something real, the part of the work you actually like (helping a team ship, untangling a messy project), and show you understand what the role involves day to day. Specifics beat enthusiasm.
Walk me through a project you delivered.+
What they're testing: whether you've actually done the work. How to answer: pick one project and use STAR. Name your role clearly, the obstacle you hit, what you did about it, and the result. This is your strongest moment, so have a polished story ready before you walk in.
Tell me about a conflict you resolved.+
What they're testing: how you handle friction without authority. How to answer: pick a real conflict you influenced through listening and facilitation, not by pulling rank. Spend the answer on the steps you took to understand both sides and find a path forward, then close with the outcome.
A deadline is slipping. What do you do?+
What they're testing: whether you manage bad news like an adult. How to answer: surface it early, never at the deadline. Show how you spotted the risk, the options you put to stakeholders (cut scope, move the date, add help), and how you helped them choose. They're not testing whether your projects never slip; they're testing whether you hide it.
Scrum Master
Scrum Master questions
These probe whether you lead through influence and actually improve a team, rather than just running ceremonies.
What does a Scrum Master actually do?+
What they're testing: depth beyond the textbook. How to answer: describe the real work, facilitating useful events, removing impediments, coaching the team and product owner, and protecting focus, and make clear you lead through influence, not authority. Mention a concrete impediment you removed to ground it.
How do you handle a team that resists Scrum?+
What they're testing: influence and empathy over rule-enforcement. How to answer: get curious about what they're actually resisting, usually one ceremony that feels like overhead, not Scrum itself. Tie a practice to a problem they care about, let a small win build trust, and adapt. Interviewers want a coach, not an enforcer.
The daily scrum has become a status meeting. How do you fix it?+
What they're testing: whether you understand the purpose, not just the format. How to answer: refocus it on the team's plan for the day and surfacing blockers, not reporting to you. Try changing the prompt, moving status to the board, and stepping back so the team runs it. The fix is purpose, not policing.
A product owner keeps changing priorities mid-sprint. What do you do?+
What they're testing: how you protect the team while respecting the business. How to answer: protect the sprint goal, make the cost of mid-sprint change visible, and coach the product owner to use the backlog and the next sprint. If something is truly urgent, facilitate a deliberate trade-off rather than quietly absorbing the churn.
How do you know if a team is actually improving?+
What they're testing: whether you think in outcomes, not vanity metrics. How to answer: look at flow and predictability over time (cycle time, how reliably they meet a goal), the health of the retrospective and whether actions actually change anything, and real outcomes for users. Be clear that velocity is a planning tool, not a scoreboard.
IT Project Manager
IT Project Manager questions
These test ownership: scope, schedule, budget, risk and stakeholders, often under pressure.
How do you manage scope creep?+
What they're testing: whether you control change without blocking it. How to answer: keep a clear baseline, run each new request through a simple change-control step that names the impact on scope, schedule and budget, and let the sponsor decide the trade-off. The goal is to make the cost visible, not to say no.
A project is behind schedule and over budget. What now?+
What they're testing: composure and structured recovery. How to answer: get the real status first, then put clear options in front of the sponsor against the triple constraint, cut or defer scope, move the date, or add resources, with the trade-offs of each. Recover deliberately and communicate early; don't promise a miracle.
Everything is "urgent." How do you prioritise?+
What they're testing: judgement and the spine to make a call. How to answer: prioritise against value and risk, not volume. Make the trade-offs explicit, get the decision-maker to confirm what comes first, and protect the team from thrash. Saying "we can do these two now, the third moves" is leadership, not avoidance.
How do you handle a difficult stakeholder?+
What they're testing: stakeholder management and emotional control. How to answer: understand what's driving them, often fear about an outcome, and meet it with clarity: regular, honest updates and a clear ask. Bring a real example where you turned a sceptic around by managing expectations rather than winning an argument.
Waterfall or agile: when would you use each?+
What they're testing: whether you're dogmatic or pragmatic. How to answer: match the method to the work. Waterfall suits fixed, well-understood scope with hard compliance or sequencing; agile suits evolving requirements and fast feedback; many real projects run a hybrid. Show you choose by context, not ideology.
Scaled Agile
Enterprise and scaled-Agile questions
For roles at large enterprises running SAFe, expect questions about working across many teams. Even a working familiarity here sets you apart.
What happens at PI Planning?+
What they're testing: whether you've operated at scale. How to answer: describe it plainly: the teams on an Agile Release Train come together to plan the next increment, align on objectives, surface cross-team dependencies, and commit to a shared plan. Mention the dependency board and the confidence vote if you've seen them.
How do you manage dependencies across teams?+
What they're testing: coordination beyond one team. How to answer: make dependencies visible early (at planning and on a shared board), agree owners and dates, and follow up relentlessly in the syncs. The job is to clear the path between teams before a dependency becomes a missed commitment.
How do you coordinate a release across multiple teams?+
What they're testing: delivery ownership at scale. How to answer: align on a clear release plan and definition of done, track readiness across teams, manage the risks and dependencies into the date, and keep stakeholders informed. Calm, visible coordination beats heroics, and that's what they want to hear.
Turn it around
Questions to ask them
The questions you ask are part of the evaluation, and they're your chance to read the role. Good ones signal you think like a practitioner.
What does success look like in the first 90 days?
Shows you think about impact, and tells you if expectations are realistic.
How mature is the team's agile practice today?
Tells you whether you're coaching beginners or fine-tuning experts.
Where does this role sit between facilitation and delivery?
Surfaces how blended the job really is, which shapes how you'd prepare.
What's the hardest part of delivery here right now?
Gets you an honest read on the real challenges, and a chance to show value.
FAQ
Frequently asked questions
What questions are asked in a Scrum Master interview?+
Expect a mix: common behavioural questions, Scrum-specific scenarios (a team resisting Scrum, a daily scrum that became a status meeting, a product owner changing priorities mid-sprint), and increasingly delivery and stakeholder questions. The best answers are real stories structured with STAR, not framework definitions.
How should I prepare?+
Prepare three to five real delivery stories you can tell in STAR form, since most questions are just different doors into the same stories. Read the actual job posting and a few like it, learn the company's delivery setup, and practise saying your answers out loud, not just in your head.
Do they ask technical questions?+
Rarely deep technical questions, but they expect you to be comfortable around technical teams and to understand delivery. For enterprise roles, a working grasp of scaled Agile (Agile Release Trains, PI Planning) matters more than coding knowledge.
What if I don't have direct experience yet?+
Use the experience you can build. A volunteer project, an internal initiative or a structured side build gives you real stories to tell. Interviewers care that you've actually run something with real people and stakes, not that it carried a particular job title.
How long are these interviews?+
Most processes run three to four rounds over a couple of weeks: a recruiter screen, a behavioural round, a scenario or role-play, and a panel or final. Each conversation is usually 45 to 60 minutes.