Project manager interviews focus on estimation, risk, and the uncomfortable conversations — with the team and with the client. Below are the most common questions with model answers. Middle: deeper understanding, optimization, and real-world situations.
Story points express relative size and complexity rather than hours, which avoids the false precision of time estimates and accounts for different people working at different speeds. Planning poker has everyone estimate simultaneously so nobody anchors on the loudest voice, and the discussion after a disagreement is where the real value is. Points become forecasting-capable only after several sprints establish a velocity.
Raise it as early as you know, not when it becomes undeniable — the cost of a surprise is far higher than the cost of bad news. Come with options rather than just the problem: reduced scope, phased delivery, added capacity with its ramp-up cost, or a moved date, each with consequences spelled out. Then let the person who owns the trade-off decide.
Risks are identified with the team, logged with probability and impact, assigned an owner, and given a mitigation and a trigger that says when to act. A concrete example is a dependency on a third-party API: mitigation is building against a mock behind an interface, and the trigger is no sandbox access by a set date. A risk log nobody reviews weekly is documentation, not management.
Velocity is the points a team completes per sprint, useful as a forecasting range across several sprints rather than a single number. A burndown chart shows remaining work against time and mainly reveals shape: a flat line early followed by a cliff means work is not being integrated until the end. Both are diagnostic tools for the team — using velocity as a performance target reliably corrupts the estimates.
Deal with it early and in private first, separating the position each person holds from the underlying need. Most technical conflict is really about unstated priorities — one person optimising for delivery date, another for maintainability — and naming that trade-off makes it a decision rather than a personality clash. If it does not resolve, escalate to whoever owns the trade-off rather than letting it fester.
Do not fight the changes — make their cost visible. A change control process where each request gets an impact estimate on scope, timeline, and budget turns an argument into an informed choice, and clients usually self-limit once trade-offs are explicit. Frequent change also often signals that discovery was insufficient, so shorter feedback loops and demos may address the cause rather than the symptom.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Project Manager interview →