Technical Program Manager (TPM) Interview Questions India 2026: Cross-Team Coordination and Delivery

TPM role clarity:

1. What does a TPM do? A TPM (Technical Program Manager) drives the execution of large, complex technical programs that involve multiple engineering teams, external dependencies, and cross-functional coordination. TPMs: - Own the program plan (scope, timeline, dependencies, milestones) - Track and manage cross-team dependencies (if Team A depends on Team B's API, the TPM tracks this and escalates if it slips) - Maintain the risk register (identify risks, quantify probability and impact, define mitigation plans) - Run program ceremonies (kickoffs, weekly syncs, milestone reviews, post-mortems) - Communicate program status to senior stakeholders (weekly status emails, steering committee presentations) - Drive decisions and resolve blockers (when two teams disagree on the interface contract, the TPM facilitates resolution)

2. TPM vs Product Manager (PM): PM: owns the WHAT (which features to build and why; product strategy; user research; prioritisation). TPM: owns the HOW and WHEN (how will we build this across multiple teams; when will it be done; what are the dependencies). PMs and TPMs work closely together; the PM brings the product direction, the TPM brings the execution structure.

3. TPM vs Engineering Manager (EM): EM: manages a single team of engineers; owns people development, team delivery, and technical direction for that team. TPM: works across multiple teams; does not manage people; influences without authority; coordinates between teams that the TPM does not manage.

4. Where TPM roles exist in India: FAANG India: Google India, Amazon India (L5 TPM), Microsoft India (Senior Program Manager; Microsoft uses the PM title for this role). Large product companies: Flipkart (Senior TPM, Staff TPM), Swiggy, PhonePe. IT services companies: TCS, Infosys (Programme Manager / Delivery Manager roles are similar but more project-management-focused).

TPM core competencies:

1. Breaking down a large program: Given a large program (e.g., 'launch a new B2B payment product in 6 months'), a TPM: 1. Decomposes it into workstreams (engineering tracks, infrastructure, security review, legal review, QA, marketing) 2. Identifies the deliverables for each workstream and the dependencies between them 3. Builds the dependency graph and identifies the critical path (the longest chain of dependent tasks; any delay on the critical path delays the program) 4. Assigns ownership to each deliverable (which team, which individual) 5. Builds the program timeline (waterfall for fixed dependencies; agile sprints within workstreams)

2. Dependency management: The TPM's most critical skill. Types of dependencies: - Technical dependency: Team A cannot start building Feature X until Team B delivers the API Y - Resource dependency: both features need the same DevOps engineer for the deployment setup - External dependency: requires security approval from the security team before production launch

Tracking: the TPM maintains a dependency tracker (spreadsheet or Jira) with: what is needed, who is providing it, who is consuming it, when it is needed, and whether it is on track.

Escalation: when a dependency is at risk of slipping, the TPM escalates early (not the day before the deadline). Escalation path: direct conversation with the owner first; then their EM; then the relevant Director if unresolved.

3. Stakeholder communication: TPM status updates follow a consistent structure: - RAG status (Red/Amber/Green): a single colour communicating overall program health - Key milestones: what was completed this week, what is coming next week - Risks and blockers: active risks with mitigation plans; anything that requires leadership action - Decisions needed: explicit asks to the steering committee (not embedded in long paragraphs)

Tip: senior stakeholders read the RAG status and the 'decisions needed' section first; write those sections first.

TPM risk and crisis management:

1. Risk management: A risk register is a living document that lists all identified risks, their probability, their potential impact, and the mitigation plan: | Risk | Probability | Impact | Mitigation | |------|-------------|--------|------------| | Team B API delayed by 2 weeks | Medium | High | Team A can use mock API in parallel; accelerate Team B with 1 extra engineer | | Security review takes longer than estimated | High | Medium | Schedule security review 2 weeks earlier than currently planned | | Third-party vendor integration fails UAT | Low | High | Build fallback to existing manual process for launch; vendor integration as Phase 2 |

Risk mitigation strategies: avoid (eliminate the risk by changing the plan), mitigate (reduce probability or impact), transfer (outsource to a vendor who owns the risk), accept (if the risk is low enough, acknowledge and monitor).

2. When the program is going to slip: Proactively communicate a slip as soon as you know, not when the deadline passes. The TPM's communication should include: - Why the slip happened (root cause, not blame) - The revised timeline - What the slip costs (business impact; revenue at risk; customer commitments affected) - Options for the stakeholder (option A: hold the scope and slip 3 weeks; option B: reduce scope and hit the original date; option C: add resources and reduce slip to 1 week) - Your recommendation and the reasoning

3. Post-mortem facilitation: After a significant miss or incident, the TPM facilitates a blameless post-mortem: 1. What happened? (factual timeline, not blame) 2. Why did it happen? (root cause analysis: 5 Whys) 3. What did we do well? (preserve what worked) 4. What will we do differently? (action items with owners and due dates) Output: a written post-mortem document shared with the organisation; action items tracked in the TPM's dependency tracker.

TPM interview strategy:

1. TPM interview structure (Google/Amazon/Microsoft India): Typically 5-6 rounds: (1) Program execution (describe a complex program you managed; walk through the dependency management), (2) Stakeholder management (how did you handle a disagreement between two senior engineering leaders?), (3) Technical depth (review a system design or technical architecture; identify risks), (4) Analytical (ambiguous problem; how would you structure the approach?), (5) Leadership (tell me about a time you drove alignment without authority), (6) Amazon: Leadership Principle rounds (Ownership, Deliver Results, Earn Trust, Bias for Action).

2. Common TPM interview questions: - 'Walk me through a program you owned end-to-end. What was the most significant risk and how did you manage it?' - 'Describe a situation where a critical dependency slipped. What did you do?' - 'How do you handle a situation where two engineering teams disagree on an interface design and both are blocking the program?' - 'Tell me about a time you had to deliver bad news (a slip, a scope cut) to senior leadership. How did you frame it?' - 'How would you set up a program to launch a new payments product involving 5 engineering teams, legal, security, and marketing over 6 months?'

3. The technical bar for TPMs: TPM technical assessments verify you can: read and critique a system design document (identify missing error handling, unclear ownership, unrealistic assumptions), understand trade-offs (synchronous vs asynchronous communication, monolith vs microservices), and ask the right technical questions to identify risks. You are not expected to write code, but you should understand why a microservices migration is risky and what questions to ask the engineers.