How do you manage a project that is behind schedule?

My first step is to understand exactly why the project is behind. Is it a planning problem, a resource problem, a dependency that slipped, or a scope issue that was not anticipated? The root cause determines the response. Once I know the cause, I reassess the critical path and identify which activities are truly blocking delivery versus which can be parallelised or descoped without compromising the outcome. I then have an honest conversation with stakeholders as early as possible: surprises at the deadline are far more damaging than early warnings. The options I present are usually some combination of extending the timeline, reducing scope, adding resource, or accepting a phased delivery. I document whatever trade-off is agreed and update the project plan so the team is aligned on the new path forward.

How do you handle scope creep?

Prevention is better than cure. I establish a clear scope document at the start of every project that describes what is in and what is explicitly out, signed off by key stakeholders. When new requests come in, I use a change request process that requires the requestor to document the ask, the business justification, and the estimated impact on timeline and budget. This process creates a natural pause that filters out low-value additions. For requests that do pass that filter, I present the impact transparently to the project sponsor and let them make the call: additional scope must be paired with additional time, resource, or a reduction elsewhere. I never silently absorb scope changes, because that erodes delivery confidence and sets a precedent that the project boundary is not real.

How do you keep stakeholders aligned when they have conflicting priorities?

I start by making sure I understand each stakeholder's underlying goal, not just their stated position. Often conflicting priorities are a symptom of different success metrics, and once those are visible, alignment becomes much easier to facilitate. I bring conflicting stakeholders together in a structured conversation rather than trying to negotiate separately, because bilateral conversations create inconsistency. I use data and project constraints to frame decisions objectively: instead of "whose priority wins", the question becomes "given our timeline and resources, which sequencing best serves the project goal". I document agreements in writing immediately after each discussion, and I follow up if anything drifts from what was agreed. Stakeholder alignment is not a one-time event: it needs regular maintenance.

Tell me about a project that failed or went significantly off track. What happened?

I led a software implementation project that ran four months over schedule. The core problem was that we had underestimated the complexity of migrating legacy data and had not identified the migration workstream as critical path until week six. By that point we had already committed to a go-live date. In the post-mortem I identified three root causes: insufficient discovery before planning, no dedicated resource for the migration workstream, and a risk register that was maintained but not actively reviewed. As a result, I now build a structured discovery phase into every project before baseline scheduling, treat data migration as a first-class workstream by default, and hold a weekly risk review as a standing agenda item. The failure was costly, but the process changes have prevented similar issues on every project since.

Describe a time you had to deliver difficult news to a stakeholder.

Halfway through a product launch project, our primary external vendor informed us they could not deliver a key integration by the original date. This would have pushed our go-live back by six weeks. Rather than waiting for the next steering committee, I requested an urgent 30-minute meeting with the project sponsor the same day. I came prepared with three options: delay the launch by six weeks, launch without the integration and add it in a phase two, or find an alternative vendor. I presented the data on each option including cost and risk, without pre-selecting one. The sponsor chose option two: a phased launch. Stakeholders appreciated the transparency and the structured options. Delivering bad news early with clear options is almost always better received than delivering it late with no alternatives.

Give an example of how you motivated a team through a difficult period.

During a long infrastructure migration project, the team hit a demoralising period around the halfway mark: the end was not yet visible, the work was unglamorous, and two team members had left the organisation. I did three things. First, I broke the remaining work into two-week milestones and started celebrating each one visibly, not with grand gestures but with specific acknowledgement of what the team had done. Second, I ran individual one-to-ones to understand what each person found motivating and what was draining them, and adjusted task allocation where I could. Third, I created a visible progress tracker on our team page that showed how far we had come, not just how far we had to go. By the final quarter the team's energy had noticeably recovered and we delivered on time.

What project management methodologies are you familiar with, and when do you use each?

I am experienced with both Waterfall and Agile, and in practice most projects I have led use a hybrid approach. I use Waterfall-style planning when the scope is well-defined upfront, dependencies are mostly sequential, and the cost of late changes is high: large infrastructure projects or regulatory deliverables typically fit this pattern. I use Agile or Scrum when requirements are likely to evolve, the team is co-located or well-synchronised, and rapid iteration is more valuable than predictability. In hybrid projects I use Agile for the delivery workstreams and Waterfall for the governance layer: fixed milestones and budget reviews, with iterative execution in between. The methodology should serve the project, not the other way round: I am wary of teams that apply Agile to everything as a default, because not all work benefits from it.

How do you build and maintain a project plan?

I build the plan collaboratively with the delivery team, not in isolation. The people doing the work are best placed to estimate effort, and involving them early creates ownership. I start with the deliverables and work backwards: what needs to be true for this deliverable to be done? I identify all dependencies, assign owners to each task, and establish the critical path explicitly. I use a RACI to make accountability clear for every workstream. Once baselined, I update the plan weekly at minimum and flag any change to the critical path as a risk immediately. I treat the plan as a communication tool as much as a scheduling tool: a good project plan should let any stakeholder understand at a glance where the project stands, what is coming next, and what the risks are.

How do you manage risks on a project?

I maintain a live risk register from the first week of every project. Each risk has an owner, a probability and impact rating, a trigger event, and a mitigation action. Crucially, I review the register in every project status meeting rather than just updating it: a risk register that is maintained but not discussed is not being managed. I also distinguish between risks (uncertain events that might happen) and issues (problems that have already happened), because they need different responses. For high-probability, high-impact risks I build mitigation into the project plan directly rather than treating it as a contingency. I encourage the team to raise risks without judgement: a culture where problems surface early is far easier to manage than one where people wait until a risk becomes a crisis.

Project Manager

Project Manager interviews test your ability to plan, coordinate, and deliver under pressure. Interviewers want evidence of structured thinking, stakeholder management skills, and real examples of how you have handled scope changes, missed deadlines, and difficult team dynamics. This guide covers the questions asked most often and the answers that show you can deliver reliably in any environment.

For general interview preparation tips, read our guide to common interview questions.

Common Project Manager Interview Questions

Behavioral Interview Questions for Project Manager Roles

Technical Questions for Project Manager Candidates

What Hiring Managers Look for in Project Manager Interviews

What hiring managers really look for in Project Manager candidates:

Proactive communication. PMs who flag problems early are worth far more than those who deliver bad news at the last minute.
Structured approach to risk. A risk register that is actively used, not just maintained, is a strong signal of PM maturity.
Stakeholder management in practice. Give specific examples of navigating difficult stakeholder dynamics, not generic statements about communication.
Methodology flexibility. Experience with both Agile and Waterfall, and the judgement to know when to use each, is more valuable than deep expertise in one.
Delivery track record. Be ready to quantify: projects delivered on time, budget saved, scope managed. Numbers make the difference.

Questions to Ask Your Interviewer

→What does a typical project look like here in terms of size, duration, and team structure?
→How is project success defined and measured in this organisation?
→What project management tools and processes does the team currently use?
→How does the organisation handle competing priorities across projects?
→What are the biggest delivery challenges the team is facing right now?

Practice These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free during beta. No commitment.

Related Roles

Digital Marketing Manager

Sales and Marketing9 questions