Technical program manager domain knowledge interview questions

As asked

From a program management perspective, what are the fundamental differences between running a waterfall-style program versus an agile one, and what does a TPM's job look like differently in each?

Sample answer outline

Waterfall: sequential phases, heavy upfront planning, phase gates, change is expensive. Agile: iterative, adaptive planning, continuous delivery, change is expected. For a TPM, waterfall demands strong planning and change control at the front; agile demands continuous re-prioritization and stakeholder alignment throughout. Many large programs use hybrid: agile execution within waterfall milestone commitments.

Expect these follow-ups

• When does a hybrid approach create more problems than it solves?
• How do you apply agile principles to hardware-dependent programs with long lead times?

As asked

Explain the RACI model, how you use it in practice, and when you have seen it create more confusion than clarity.

Sample answer outline

RACI: Responsible (does the work), Accountable (owns the outcome), Consulted (input needed), Informed (kept in the loop). It helps most at program kick-off to prevent ownership ambiguity. It hurts when too many people are 'Consulted,' creating decision paralysis, or when it is treated as a static document that nobody updates. The candidate should mention the difference between Responsible and Accountable being the key insight most teams miss.

Expect these follow-ups

• What is the single most common RACI mistake you have seen?
• Is there a situation where a RACI is more harmful than helpful?

As asked

How does a microservices architecture change the complexity of program planning compared to a monolithic architecture, and what specific program management problems does it create?

Sample answer outline

Microservices increase the number of teams and inter-team dependencies, amplify integration risk, create contract and API versioning management needs, and complicate end-to-end testing coordination. A TPM in a microservices environment spends much more time managing cross-team dependencies and integration schedules compared to a monolith. The candidate should demonstrate they understand the architectural tradeoffs, not just the coordination overhead.

Expect these follow-ups

• What is the most common program failure mode in a microservices environment?
• How do you handle integration testing across 12 microservices owned by 12 teams?

As asked

Explain the difference between an SLA, an SLO, and an SLI, and tell me how understanding these affects your program planning for a reliability initiative.

Sample answer outline

SLI: the actual measured metric (e.g., request latency). SLO: the internal target for that metric (e.g., p99 latency under 200ms). SLA: the external contract with customers that includes consequences for violation. For a TPM, understanding these matters because reliability work must be sequenced to bring SLIs in line with SLOs before any SLA commitment is made, and because engineering team capacity allocation depends on current error budget burn rates.

Expect these follow-ups

• How do you explain the difference between an SLO and an SLA to a non-technical executive?
• How should a TPM use error budget burn rate in their weekly status report?

As asked

Explain what continuous integration and continuous delivery mean from first principles, and tell me specifically why the health of a team's CI/CD pipeline should matter to you as a TPM.

Sample answer outline

CI: frequent merges to a shared branch with automated test runs to catch integration issues early. CD: automated deployment pipeline so validated code reaches production quickly. For a TPM, a slow or broken CI/CD pipeline is a program risk because it compresses iteration time, increases the cost of late bug discovery, and makes deployment milestones less reliable. A team with a 2-hour pipeline cannot course-correct as fast as one with a 10-minute pipeline.

Expect these follow-ups

• How do you assess whether a team's CI/CD setup is healthy enough for a program you are about to run?
• What is the most common CI/CD problem that creates program-level risk?

As asked

How do feature flags change the way you plan and execute a program launch, and what new risks do they introduce that you need to manage?

Sample answer outline

Feature flags enable dark launches, gradual rollouts, and instant rollback without a redeploy. For a TPM this means launch risk is lower, you can decouple code deployment from feature activation, and you can do controlled rollouts to percentages of users. New risks include flag accumulation (technical debt), misconfiguration causing unexpected exposure, and the need to track and clean up flags post-launch. The candidate should show they understand how feature flags interact with launch readiness reviews.

Expect these follow-ups

• What happens when feature flags are used as a substitute for proper testing?
• How do you track flag states across multiple services in a program?

As asked

Explain how production incident severity levels are typically defined, and tell me how an ongoing high-severity incident affecting a team on your program should change your behavior as a TPM.

Sample answer outline

Severity levels typically run from SEV1 (complete outage or data loss) to SEV4 (cosmetic or minor). A SEV1 or SEV2 will pull engineering capacity away from program work, potentially for days. As a TPM, this means immediately assessing critical-path risk, notifying the sponsor, and beginning contingency planning. The TPM should not pressure the team during an active incident but should be ready to replan the moment the incident is resolved.

Expect these follow-ups

• How do you balance keeping the program moving with not disturbing a team during an active incident?
• What information do you need from the on-call team during an incident to make good program decisions?

As asked

What are the practical differences between a team running Kanban versus Scrum, and how does each affect how you manage their contribution to your program?

Sample answer outline

Scrum: fixed sprints, committed sprint goals, cadenced retrospectives. Kanban: continuous flow, WIP limits, no fixed iterations. For a TPM, Scrum teams are easier to roll up into milestone forecasts because sprint velocity is measurable. Kanban teams require a different tracking approach, often cycle time and throughput metrics. The candidate should mention that the team's process should be respected rather than forced to change to fit the program.

Expect these follow-ups

• Have you ever had to convert data from a Kanban board into a program-level forecast?
• Is there a team process that you think genuinely does not work for program visibility?

As asked

How do you build a capacity model for a software engineering team that is contributing to your program while also running their own product work and handling on-call?

Sample answer outline

Strong candidates describe starting with total available person-weeks, then subtracting overhead: on-call duty, recurring ceremonies, PTO, hiring interviews, and any concurrent product work. The remaining capacity is the program-available bandwidth, and even that gets a buffer (typically 80% of available is the realistic planning number, not 100%). They should mention verifying this model with the team lead, not assuming their calculation is accurate.

Expect these follow-ups

• What is a reasonable planning efficiency factor for an experienced engineering team?
• How do you adjust the model when on-call burden is unpredictable?

As asked

Walk me through the PMBOK knowledge areas and tell me which ones are most relevant to your day-to-day work in a technology company, and which ones you think are overemphasized in traditional PM training.

Sample answer outline

PMBOK 6th edition defined 10 knowledge areas: integration, scope, schedule, cost, quality, resource, communications, risk, procurement, and stakeholder management. PMBOK 7th edition (2021) replaced this model with 12 principles and 8 performance domains, so candidates referencing 'knowledge areas' are drawing on the 6th edition framework, which is still widely taught and tested in PMP prep. In a tech company, scope, risk, stakeholder, and communications management are most practically relevant day to day. Procurement management is often overemphasized in traditional PM training but is less central in product companies without significant vendor relationships. The candidate should show genuine familiarity rather than just listing the areas.

Expect these follow-ups

• Do you hold a PMP and do you think it is valuable for a TPM in a tech company?
• What PM discipline is most undervalued in the tech industry?

As asked

Explain the Critical Path Method and PERT. When would you use each, and how do they help you make better program decisions?

Sample answer outline

CPM: deterministic, uses single-point estimates, best when durations are well understood. PERT: probabilistic, uses optimistic, pessimistic, and most-likely estimates, best when there is high uncertainty in duration. Both identify the critical path. In practice, most TPMs use PERT thinking even if they do not formally apply the formula, because engineering estimates carry inherent uncertainty. The candidate should show they know when each is practically applicable.

Expect these follow-ups

• How do you handle tasks where even the range of duration is unknown?
• Have you ever used formal PERT calculations in a real program, or just the CPM approach?

As asked

Explain earned value management. Have you used it in practice, and do you think it is actually useful for managing software development programs?

Sample answer outline

EVM: a set of metrics comparing planned value, earned value, and actual cost to produce schedule and cost performance indices. Strong candidates explain the core metrics, acknowledge that it is rarely applied formally in software development due to the difficulty of defining measurable value at task level, but note that the underlying concepts (are we getting value proportional to the work invested) are relevant. A credible answer neither dismisses EVM entirely nor pretends it is universally applied.

Expect these follow-ups

• What metric do you use instead of EVM to assess program financial efficiency?
• In what type of program does EVM actually work well?