Project manager interview: passing the derailed-project case study

· 8 min read

"Your project is three weeks late and the client is losing patience. What do you do?" This scenario comes up in almost every project manager interview, and most candidates answer with intentions — "I communicate, I reprioritise" — instead of a method.

How do you structure a case study answer?

In four steps, always the same: what you need to know before acting, the options you put on the table, the one you pick and why, and how you check it works. That skeleton fits in two minutes and stops you drifting into an endless story.

Which mistake disqualifies you in one sentence?

"I ask the team to make an effort." That answer says your first lever is pressure on people already behind, and it worries people immediately — especially since it fixes nothing. A credible project manager touches scope or schedule first, because those are the only variables they genuinely control.

Should you talk methodology?

As little as possible, and never first. Answering "we are agile, so…" substitutes a framework for a decision. Methods get mentioned in passing, to explain how a team runs; they do not replace the trade-off being asked of you. We develop this in project manager interview.

How do you handle the team conflict question?

It is the most frequent variant: "two people on your team have stopped speaking". Nobody expects professional mediation, but they do expect a simple reflex — see each separately first, look for the real disagreement behind the visible tension, and bring the discussion back to the work rather than the people. Say when you escalate too: knowing it is not always yours to settle is a sign of maturity.

Should you tell the client bad news, and when?

Early, and with an option. A delay announced three weeks ahead with two scenarios is a managed problem; the same delay announced the day before is professional negligence. This question often separates two good candidates: the one who guards information and the one who shares it early enough for it to remain actionable.

You do not judge a project manager on the projects that go well. You judge them on what they do the day it derails.

Prepare two or three real projects to tell, including one that went badly — the STAR method helps structure them without drifting, and our article on why hire you covers the question that almost always follows.