Skip to main content

Interview questions

Technical program manager interview questions

TPMs drive complex cross-team programmes to a deadline. They map dependencies, surface and unblock risks, run programme rituals, and translate between engineering, product, and executive stakeholders. The role is judged on outcomes shipped, not artefacts produced.

Seniorities
midseniorstaffprincipaldirector

Most reported

Top technical program manager interview questions

6 questions

Sorted by reported frequency. Click any question for the sample outline, follow-ups, and reference implementation.

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?
programme-managementdependencieslaunch

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?
recoveryscopeexecution

As asked

Walk me through exactly how you build a dependency map for a large, multi-team initiative. What information do you gather first, where do you store it, and how do you keep it accurate over the course of a six-month program?

Sample answer outline

Strong answers identify dependencies across teams early via structured interviews and kick-off workshops, capture them in a shared tool (Jira, Asana, or a dependency register spreadsheet), assign owners to each dependency, and schedule a cadence for review. The candidate should mention blocking vs. non-blocking dependencies, how they visualize the critical path, and how they escalate when a dependency slips.

Expect these follow-ups

  • What do you do when a team says their dependency is 'being worked on' but there is no visible progress?
  • How do you handle circular dependencies between two teams?
dependency-managementplanningcross-teamcritical-pathprogram-execution

As asked

Describe your process for maintaining a risk register on an actively running program. How do you identify new risks, score them, and decide which ones actually get escalated to leadership versus which ones you handle yourself?

Sample answer outline

A strong answer covers a structured intake process (retrospectives, stakeholder interviews, technical review meetings), a consistent scoring rubric combining probability and impact, a clear threshold for escalation versus self-management, and a regular review cadence. The candidate should distinguish between risks and issues and show they close out risks that no longer apply.

Expect these follow-ups

  • Give me an example of a risk you chose not to escalate and it turned into a real problem. What did you learn?
  • How do you get engineers to actually report risks rather than hiding them?
risk-managementescalationplanningstakeholder-communication

As asked

How do you identify the critical path in a complex program, and what tactics do you use to protect it when individual milestones start to slip?

Sample answer outline

Candidates should describe using network diagrams or Gantt-style dependency chains to identify the longest path, quantifying float on non-critical tasks, and proactively staffing or unblocking critical-path items. Strong answers mention re-calculating the critical path after each significant change and communicating the impact of slippage in terms of end-date risk rather than individual task delays.

Expect these follow-ups

  • How do you convince an engineering manager to put their best people on a critical-path task they consider boring?
  • When do you compress the schedule and when do you reduce scope instead?
critical-pathschedulingprogram-planningrisk-mitigation

As asked

You are running a program that involves eight engineering teams, two product managers, a design team, and a VP sponsor. Design the status reporting structure: what reports do you produce, at what cadence, for which audiences, and what information goes in each?

Sample answer outline

Strong answers distinguish between a weekly operational update for the working teams (detailed, task-level), a biweekly executive summary for the VP (milestone status, top three risks, decisions needed), and an ad-hoc escalation format for urgent issues. The candidate should describe RAG status, mention what they cut to keep reports readable, and show they tailor content to each audience's decision-making needs.

Expect these follow-ups

  • What do you do when stakeholders stop reading your status updates?
  • How honest are you about yellow or red statuses in a politically sensitive org?
status-reportingstakeholder-communicationprogram-managementexecutive-communication

Also known as

TPM - programme manager - delivery manager