project manager interview questions

What is the difference between Scrum and Kanban? When do you use each?

Scrum works in fixed sprints with committed scope, defined roles, and ceremonies — it suits product work where a cadence of planning and review adds value. Kanban is continuous flow with work-in-progress limits and no sprints, which suits support, maintenance, and anything where priorities change daily. The deciding question is whether you can hold scope stable for two weeks; if you cannot, Scrum ceremonies become theatre.

How do you estimate? What are story points and planning poker?

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.

What do you do when a project is going to miss its deadline?

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.

How do you manage risk? Give an example.

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.

What are velocity and a burndown chart? How do you use them?

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.

How do you resolve conflicts within a team?

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.

What do you do when a client constantly changes requirements?

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.

How do you communicate bad news to a client?

Early, directly, with the impact quantified and options attached. Lead with the situation and what it means for them rather than a build-up of context, take responsibility without over-apologising, and be specific about what you will do and by when. The relationship damage comes almost entirely from late disclosure, not from the problem itself.