Technical program manager interview questions

As asked

You are running a launch that depends on 5 engineering teams shipping coordinated changes by a fixed date. Walk me through how you set this up.

Sample answer outline

Start with the dependency map: who depends on what, in what order. Convert it into a critical path with explicit handoff dates and owners. Stand up the right rituals: weekly programme review for cross-team status, daily standup only when the launch is hot. Build a single source of truth (a status doc, not slides) that every team updates. Identify the top three risks early and the mitigation for each. Pre-mortem: assume the launch slipped, what was the cause, mitigate it now. The TPM's job is to make the bad news travel fast and the decisions get made before the slip is irreversible.

Expect these follow-ups

• What if one team is consistently late on their commitments?
• How do you balance reporting overhead against actual progress?
• How do you handle a director who only wants to hear green status?

As asked

Tell me about a programme that was heading for a slip and you turned it around. What was happening and what did you do?

Sample answer outline

Pick a real story. Walk through: the symptoms you spotted (which feature was actually behind, which team was overloaded, which dependency was decaying), the diagnosis (often a missed assumption or hidden work), the corrective action (rescope, reallocate, escalate, replan), and the outcome. The strong answer notes that 'saving' a programme often means cutting scope honestly, not heroics. Show that you got buy-in from the affected stakeholders, not just decreed the change.

Expect these follow-ups

• What scope did you cut and how did you negotiate it?
• Could you have spotted this two weeks earlier?
• What changed in your programme process after?

As asked

Walk me through how you track and manage risks on a programme. What does your risk register look like and how is it actually used?

Sample answer outline

Risks are not the same as issues; a risk is what could happen, an issue is what has happened. The register has columns: description, owner, likelihood, impact, mitigation, target close date. Top risks get reviewed weekly in the programme review with the owner accountable for progress on the mitigation. Stale risks get re-evaluated or closed. The trap is a 50-row risk register no one reads: keep it short and have a real conversation about the top five. The strong TPM uses the risk register to drive decisions, not as a CYA artifact.

Expect these follow-ups

• How do you score impact in a way that does not collapse to 'high'?
• What is the difference between a risk and a dependency?
• How do you raise a risk to an executive who keeps saying it is fine?

As asked

Team A says they are blocked on Team B's API change. Team B says they are blocked on Team A's clarified requirements. Both have escalated to you. What do you do?

Sample answer outline

Get the three of you in a room (literal or video) within 24 hours. Establish facts, not accusations: what does each team actually need from the other, in concrete terms, by when. Surface the underlying tension, which is usually misaligned priorities or different interpretations of the same brief. Pick a path: scope down to unblock, or escalate to the joint leadership for a prioritisation call. The TPM's job is not to mediate forever, it is to force a decision and document it. Follow up in writing so nobody re-litigates next week.

Expect these follow-ups

• What if the leaders of the two teams disagree?
• How do you stop the same teams getting stuck on each other repeatedly?
• When is the right answer 'this should not be two teams'?

As asked

Your org has 80 engineers across 8 teams and no real planning process. Design the quarterly planning cycle.

Sample answer outline

Pre-planning (2 weeks before): each team drafts proposed projects with rough sizing and impact estimates. Cross-team dependency mapping happens here. Planning week: leadership reviews the proposed slate against company priorities, makes tradeoff decisions, and assigns goals. Post-planning: teams commit to a small set of goals (3 to 5 per team) with clear owners. Cadence during the quarter: monthly progress reviews and a mid-quarter checkpoint to rebaseline. Closeout: did we ship what we said, what did we cut, what did we learn. Keep the process light enough that engineers spend less than 10 percent of their time on it.

Expect these follow-ups

• How do you handle a CEO who keeps adding priorities mid-quarter?
• What is the right number of goals per team?
• When does OKRs help and when does it just add overhead?

As asked

How do you write status reports that executives actually read and act on? What is your template?

Sample answer outline

Short, scannable, honest. Top: a one-line summary plus a colour (green, yellow, red) that reflects reality, not optimism. Then: what shipped this period, what is on track, what is at risk and why, what decisions you need from the reader. Avoid 'we had a meeting' as content. Avoid the temptation to bury bad news. Length: one screen. Cadence: weekly for active programmes, biweekly for steady-state. The test of a good status report is whether an executive who reads only the top line could correctly answer 'is this programme on track'.

Expect these follow-ups

• How do you handle pressure to report green when the programme is yellow?
• What is the difference between a status report and a dashboard?
• When does written status replace meetings?