Project Manager Interview Guide
A structured interview guide for Project Manager roles covering planning and delivery, risk management, stakeholder communication, influencing without authority and adapting methods to context — with follow-up probes to dig into evidence and a practical scorecard.
Published 2026-08-26 · Reviewed 2026-08-26
Hiring a Project Manager is hiring the person who determines whether your important initiatives actually happen. A good PM keeps complex work on track without micromanaging the people doing it. A weak one creates status reports instead of delivery. This guide gives you a structured framework: evidence to look for, questions to ask with follow-up probes, and a practical scorecard.
These indicators are prompts for structured evaluation, not model answers. Candidates may demonstrate competence through different examples or approaches. An unfamiliar answer is not automatically a weak answer — use follow-up questions before reaching a conclusion. "Not enough evidence" is a valid scorecard outcome. The final decision remains with the human hiring team.
Who this guide is for
For hiring managers and team leads interviewing a Project Manager candidate — whether backfilling a delivery role, adding the first dedicated PM to a growing team, or hiring a senior PM to coordinate a portfolio of initiatives.
Role overview
A Project Manager owns the delivery of defined initiatives. They are responsible for planning, scheduling, risk management, stakeholder communication, budget tracking and keeping the team unblocked. The role requires organisational thinking, the ability to influence without authority, communication skills to manage expectations and the judgement to know when to escalate versus when to solve. The role ranges from traditional waterfall project management to agile delivery leadership depending on the context.
How the role varies
A PM in a software company often works in an agile or hybrid mode and sits close to product and engineering; one in construction, engineering or government tends to follow more traditional waterfall disciplines with heavier governance. At a startup the PM may be the only one and wear several hats; at a scale-up they coordinate across squads; at a large enterprise they may manage a programme of interdependent projects. Seniority shifts the emphasis too — an IC PM focuses on a single project’s delivery, while a programme or portfolio lead is judged on dependencies, sequencing and stakeholder alignment across many workstreams.
Written and maintained by Kippler. Published — not individually expert-reviewed.
What the interviewer should assess
A Project Manager interview should test four areas: delivery and planning, risk and issue management, stakeholder communication, and team leadership without authority. Each matters — an organised planner who cannot manage stakeholders is as risky as a great communicator who cannot track dependencies.
Role-specific competencies
Planning and delivery
Can they build a plan that is realistic, not optimistic? Do they track dependencies, not just tasks?
Risk and issue management
Do they identify risks before they become issues? Can they manage issues without panicking or hiding them?
Stakeholder communication
Can they manage expectations honestly? Do they communicate bad news early rather than hoping it resolves?
Influencing without authority
Can they hold team members accountable when they are not their manager? Do they unblock the team rather than escalate every problem?
Adaptability and ambiguity
Can they manage a project where the scope is not fully defined? Do they adapt the approach to the context rather than applying one methodology to every situation?
Commercial and budget management
Do they track budget and understand the commercial implications of decisions? Can they make trade-offs between scope, time and cost?
Recommended interview structure
A 60-minute interview is a useful starting point for this role. Project roles benefit from a practical exercise, so consider a 30-minute take-home or live scenario followed by a 45-minute discussion of their approach. Structure a single interview in three parts: a brief career discussion (5 minutes), a delivery and risk scenario (30 minutes), and a stakeholder communication scenario (20 minutes). Reserve the final 5 minutes for the candidate’s questions. Use a realistic project scenario with conflicting priorities.
Adapt this guide to your role
Adapt the questions to the methodology and the type of projects the role involves. A project manager in a construction or engineering context tends to need different skills from one in a software company, where agile or hybrid delivery is more common. Consider the company stage: at a startup the PM may be the only one and handle several workstreams at once; at a scale-up they coordinate across squads and dependencies multiply; at a large enterprise they may run a programme governed by formal stage gates. Think about whether the role is B2B or B2C, whether delivery is internal or client-facing, and whether the PM is an individual contributor owning a single project or a programme lead coordinating many. And unless the specific role mandates a single framework, do not require one — a PM who can flex between agile, waterfall and hybrid approaches is usually more useful than one who is fluent in only one.
Interview questions
Ask the same core questions to every candidate for this role. Use the follow-up probes to clarify vague answers and gather more evidence before scoring.
1. You are managing a project where the scope keeps changing because the sponsor keeps adding requirements. How do you handle this?
What this is assessing: Scope management and stakeholder communication. Whether they can push back constructively. Whether they understand the trade-off triangle.
Follow-up probes
- What would you put in writing after that conversation, and to whom?
- Can you describe a time a sponsor would not prioritise — how did you resolve it?
- At what point would you escalate, and to whom?
Evidence that may indicate strength
- Documents the impact of each change on timeline and budget
- Has a change-control process, not a yes-or-no response
- Helps the sponsor prioritise rather than just refusing
- Communicates the trade-offs clearly and lets the sponsor decide
Points that may require further probing
- Says yes to everything to keep the sponsor happy
- Says no to everything to protect the plan
- Does not quantify the impact of changes
- Escalates without trying to manage it first
2. Tell me about a project that was going off track. How did you know, and what did you do?
What this is assessing: Risk awareness and delivery judgement. Whether they spot problems early. Whether they act rather than hope.
Follow-up probes
- What was the earliest signal that something was wrong?
- Looking back, is there anything you would have done sooner?
- How did stakeholders react when you raised it, and how did you handle that?
Evidence that may indicate strength
- Identified the problem early through tracking or instinct
- Diagnosed the root cause before acting
- Took specific action to get back on track
- Communicated the risk to stakeholders honestly
Points that may require further probing
- Did not realise the project was off track until it was too late
- Hoped the team would catch up
- Did not communicate the problem to stakeholders
- Cannot describe what they did to recover
3. A key team member is not delivering their part of the project. They do not report to you. What do you do?
What this is assessing: Influencing without authority. Whether they can handle a difficult situation directly. Whether they escalate appropriately.
Follow-up probes
- What would you say in that first conversation?
- How do you decide what counts as "genuine" before you escalate?
- Can you describe a time escalating paid off, and a time it did not?
Evidence that may indicate strength
- Talks to the person directly before escalating
- Tries to understand why they are not delivering
- Offers help or adjusts the plan if the issue is genuine
- Escalates to their manager only if the direct approach is not working
Points that may require further probing
- Escalates immediately to the person’s manager
- Does nothing and hopes it resolves
- Removes the person from the project without talking to them
- Takes over the work themselves
4. How do you build a project plan that is realistic rather than optimistic?
What this is assessing: Planning judgement. Whether they understand estimation. Whether they build in contingency appropriately.
Follow-up probes
- How do you challenge an estimate that feels too optimistic without demoralising the team?
- What do you do when the team has no prior data to base an estimate on?
- Can you describe a plan that turned out to be wrong — what did you adjust?
Evidence that may indicate strength
- Involves the people doing the work in estimation
- Builds in contingency based on risk, not a fixed percentage
- Identifies dependencies and critical path
- Plans milestones, not just a start and end date
Points that may require further probing
- Estimates based on their own assumptions without consulting the team
- Adds a standard contingency without analysing specific risks
- Does not identify dependencies
- Produces a plan that looks good but has no basis
5. Describe a time you had to deliver bad news to a senior stakeholder about a project. How did you handle it?
What this is assessing: Communication courage. Whether they deliver bad news early. Whether they bring a plan, not just a problem.
Follow-up probes
- How far in advance did you raise it, and would you do it sooner now?
- What options did you bring, and how did you decide between them?
- How did the stakeholder react, and what did you do with that reaction?
Evidence that may indicate strength
- Communicated early, not when it was too late to act
- Was clear about the issue and the impact
- Brought options and a recommendation
- Followed up with action, not just communication
Points that may require further probing
- Delayed the conversation hoping the situation would improve
- Softened the news to the point of being misleading
- Brought the problem without options
- Did not follow up after the conversation
6. How do you decide whether to use agile, waterfall or a hybrid approach for a project?
What this is assessing: Methodology judgement. Whether they apply an approach that fits the context. Whether they are dogmatic about one method.
Follow-up probes
- Can you describe a project where you changed approach mid-flight, and why?
- What would make you choose waterfall over agile, specifically?
- How do you explain a methodology choice to a stakeholder who has a strong preference?
Evidence that may indicate strength
- Considers the project characteristics: clarity of scope, rate of change, stakeholder needs
- Is not dogmatic about one methodology
- Understands the trade-offs of each approach
- Adapts the method to the team and the context
Points that may require further probing
- Defaults to agile because it is modern
- Defaults to waterfall because it is structured
- Cannot explain the trade-offs
- Is dogmatic about one methodology
7. Tell me about a commitment your project missed. What happened, and what did you learn from it?
What this is assessing: Whether they can reflect honestly on missed commitments. Whether they take responsibility rather than blaming the team. Whether they translate a miss into a concrete change.
Follow-up probes
- What would you do differently if you ran that project again tomorrow?
- How did you communicate the miss to the stakeholder, and when?
- Is there a pattern across the commitments you have missed — what is it?
Evidence that may indicate strength
- Owns their part in the miss rather than blaming the team or the sponsor
- Can pinpoint what they would do differently, specifically
- Connects the lesson to a change in how they plan or communicate
- Distinguishes between misses caused by estimation, scope or dependency issues
Points that may require further probing
- Frames the miss as entirely external or someone else’s fault
- Cannot describe a specific change they made afterwards
- Treats the miss as a one-off rather than looking for a pattern
- Is unable to say what they would do differently
Practical scorecard
Score each competency separately and record concise evidence supporting your score. Do not allow one impressive answer to inflate unrelated competencies.
Scoring scale
| Competency | Score |
|---|---|
| Planning and delivery Can they build realistic plans? Do they track dependencies? | |
| Risk and issue management Do they identify risks early? Can they manage issues calmly? | |
| Stakeholder communication Can they manage expectations? Do they deliver bad news early? | |
| Influencing without authority Can they hold people accountable? Do they unblock rather than escalate? | |
| Adaptability and ambiguity Can they manage undefined scope? Do they adapt the approach to context rather than imposing one method? | |
| Commercial and budget management Do they track budget? Can they make scope-time-cost trade-offs? | |
| Learning from missed commitments Do they own their part in a miss and translate it into a specific change? Can they spot patterns across commitments? |
How to use this scorecard
- Score each competency separately.
- Record concise evidence supporting the score.
- Do not allow one impressive answer to inflate unrelated competencies.
- Do not average away a material role-critical concern.
- Discuss scores only after each interviewer has recorded their independent judgement.
- Use the scorecard to support — not replace — the final human decision.
How to run the debrief
Collect independent scores before any discussion, so that a confident early opinion does not anchor the group. Focus the debrief on specific delivery evidence — a project that recovered, a commitment that slipped and how it was handled — rather than general impressions of composure. Pay attention to how candidates talk about missed commitments: honest, specific reflection is usually more informative than a clean track record. Watch for candidates who are dogmatic about a single methodology, since that tends to signal trouble in roles where the context varies. Agree on the areas a later stage should probe and whether a practical exercise would add evidence.
Fairness and reasonable adjustments
Ask the same core questions of every candidate for this role. Use follow-up questions to clarify evidence rather than to catch candidates out. Make reasonable adjustments to format and timing where needed — for example, extra time, alternative formats, or breaks. Score evidence against the role requirements, not against your impression of the candidate's personality or communication style. Keep notes factual and job-relevant. Separate "not enough evidence" from "candidate lacks the skill" — the first may warrant a focused follow-up, the second is a scoring decision. The final hiring decision remains with the human hiring team.
Candidate experience: Explain the interview format at the beginning. Leave time for the candidate to ask questions. Avoid misleading candidates about the role or the team. Tell them what happens next and the expected timeline. Follow the agreed timing as closely as practical. Avoid repeatedly asking for information already covered in earlier stages.
Questions candidates may ask
Strong candidates will ask questions that reveal their priorities and how they think about the role. Be prepared to answer honestly — misleading a candidate about the role or the team risks a bad hire who leaves quickly.
- What does the portfolio of projects look like, and how are they prioritised?
- How does the PM function relate to product and engineering today?
- What tends to cause projects to slip here, and how is that usually handled?
- How much autonomy does this role have over methodology and tooling?
- What does success look like for this role in the first six months?
Frequently asked questions
What certifications should I look for?
PRINCE2, PMP and Agile certifications are common. They demonstrate methodology knowledge but not delivery judgement. Use the interview to test how they apply their knowledge in real situations. A certified PM who has never delivered a struggling project is often less valuable than an uncertified one who has. Unless the role mandates a specific certification, treat them as a helpful signal rather than a requirement.
Should I include a project planning exercise?
A discussion about how they would approach a realistic project scenario is more informative than producing a Gantt chart. Ask them to talk through their planning process, what they would want to know and how they would handle a specific challenge. This tests thinking, not software skills. A short written exercise can add evidence if you have time to review it properly.
How do I assess whether they can influence without authority?
The non-reporting-team-member question above is a direct test. If they escalate immediately, they will likely struggle in matrix organisations. A strong candidate tries to resolve it directly first and only escalates when genuinely necessary. Follow up by asking what they would actually say in that first conversation.
Do I need a PM who is certified in a specific framework?
Only if the specific role mandates it — for example, a regulated or contract-driven environment that requires PRINCE2, or a client that specifies a method. In most cases a PM who can flex between agile, waterfall and hybrid approaches and choose based on the context is more useful than one fluent in a single framework. Use the methodology question to check for dogmatism rather than fluency in any one method.
Upload the candidate's CV and, when available, the job description. Kippler creates a structured assessment and interview plan tailored to that person and role.
Try 1 Candidate Free