Google Technical Program Manager (Entry Level) Interview Preparation Guide

Approach: build a directed dependency graph where nodes are teams or services and edges are dependencies. Compute metrics: 1) In-degree/Out-degree to find heavily depended-on services and bottlenecks. 2) Betweenness centrality to find nodes critical for many paths (potential single points of failure). 3) PageRank or eigenvector centrality to surface influential nodes. 4) Connected components and reachability to detect cascading failure paths. 5) Single Point of Failure (SPOF) detection: nodes with high dependency concentration and low redundancy. Use metrics to prioritize: high-impact + high-centrality = top priority for mitigation (add redundancy, cross-training, decouple via APIs). Implementation snippet: ```python

compute centrality with networkx

import networkx as nx
G = nx.DiGraph()

add nodes/edges

in_deg = dict(G.in_degree())
betw = nx.betweenness_centrality(G)

prioritize nodes by combined score

scores = {n: in_deg[n]*0.5 + betw[n]*0.5 for n in G.nodes()}

Decision framework: structured cost-risk-value lattice using these dimensions:

1. Quantify impacts: estimate expected loss (EL) if accepting risk = probability * impact (financial, legal, reputational). Estimate cost and schedule delay of preventive control.
2. Compare expected value: Preventive ROI = EL avoided - cost_of_prevention. If ROI positive and within risk appetite, favor prevention.
3. Consider timing & optionality: if preventive control causes significant launch delay with market opportunity cost, factor lost revenue into decision.
4. Evaluate controllability and detection: if risk can be reliably detected and contained quickly with contingency, acceptance with strong contingency may be valid.
5. Non-financial constraints: regulatory or safety-critical risks may mandate prevention regardless of cost.

Process:

• Build short decision memo with EL, prevention cost, contingency plan (cost, detection time, rollback options), and recommended decision.
• Review with Risk Board; TPM recommends based on data and escalation thresholds.

Final rule: choose prevention when EL > cost + acceptable opportunity cost OR when residual risk breaches compliance thresholds; otherwise accept with tested contingency and monitoring.

When historical data is limited, combine expert judgment with proxies and conservative assumptions. Approaches: 1) Expert elicitation: structured interviews with engineers, ops, and security to estimate frequency and severity; use probability buckets. 2) Proxy metrics: use similar systems’ incident rates, third-party benchmarks, or industry incident databases. 3) Leading indicators: code churn, deployment frequency, test coverage, complexity metrics (e.g., cyclomatic complexity) as predictors for probability. 4) Scenario-based modeling: define plausible failure scenarios, estimate likelihood qualitatively, and run sensitivity analysis. 5) Use Bayesian priors: start with conservative prior distributions and update as data accrues. Impact estimation: map to business metrics (data exposure cost, remediation effort, customer churn) and prepare bounded estimates (best/likely/worst). Capture uncertainty by presenting ranges and expected value, and prioritize mitigations that reduce both likelihood and impact. Document assumptions and plan data collection to refine the model over time.

TPM steps and timeline to integrate privacy mitigations for new user data collection:

Weeks 0–1: Requirements & Privacy Impact

• Collect data dictionary, use cases. Run Data Protection Impact Assessment (DPIA) with Privacy/Legal. Owner: TPM coordinates; Privacy lead signs off.

Weeks 1–3: Design mitigations

• Data minimization: remove unnecessary fields; define pseudonymization strategy. Owner: Product + Engineering.
• Encryption: define in-transit and at-rest keys, KMS integration, key rotation policy. Owner: Security/Platform.
• Retention: set retention windows, auto-delete workflows and retention flags. Owner: Data Engineering.

Weeks 3–6: Implementation & Controls

• Implement field-level encryption/pseudonymization in ingestion pipeline; add access controls and logging. Engineering implements; TPM tracks tickets.
• Add retention jobs, policy enforcement and test suites.

Weeks 6–8: Validation & Compliance

• Privacy performs review, Security runs penetration/crypto review, Compliance verifies DPIA. TPM coordinates evidence collection for audits.

Ongoing: Monitoring & Ops

• Metrics: number of sensitive fields stored, access attempts, retention job success, encryption audit logs. TPM sets alerts and monthly privacy health check.

Rationale: orchestrates cross-functional owners, produces audit evidence, and builds privacy into delivery rather than retrofitting.

Risk register structure/key fields: 1) ID; 2) Title; 3) Description; 4) Category (technical/operational/security/regulatory/financial); 5) Probability (low/med/high or %); 6) Impact (low/med/high or $/days); 7) Expected Loss; 8) Owner; 9) Mitigation actions; 10) Contingency plan/trigger; 11) Status; 12) Target dates; 13) Last updated. Example entry for security vulnerability: - ID: R-2026-001 - Title: Vulnerable dependency (libXYZ) with CVE - Description: Transitive dependency libXYZ has CVE-2026-XXXX allowing RCE in parsing path - Category: Security - Probability: Medium (30%) - Impact: High (possible customer data exposure, remediation 2 weeks) - Expected Loss: $150k - Owner: Security Lead (Jane Doe) - Mitigation: patch dependency, run regression tests, apply WAF rule - Contingency/Trigger: exploit detected in wild or failed patching → rollback and hotfix pipeline - Status: In progress - Target: Patch deployed by 2026-03-10.

Negotiation: acknowledge stakeholder goal, articulate technical debt risk clearly (using impact, probability, and examples), and propose alternatives (scope reduction, temporary mitigations, prototype). Use cost-of-delay and risk-adjusted delivery estimates to show trade-offs. If stakeholder insists, require a formal Risk Acceptance: 1) Document decision in risk register with owner, rationale, measurable acceptance criteria, and a sunset date for acceptance. 2) Define compensating controls (monitoring, feature flags, increased testing) and explicit remediation plan with milestones and budget. 3) Assign accountability: name an owner responsible for remediation and a sponsor who approved acceptance. 4) Add triggers: if defect rate or incident threshold exceeded, auto-block future releases until mitigations delivered. 5) Communicate: record in steering committee minutes and notify QA/security teams. This preserves speed while ensuring visibility, traceability, and clear accountability if the risk materializes.

Rubric: score Probability (1–5) and Impact (1–5); risk score = Probability × Impact (1–25). Probability levels: 1 (Rare, <1%/year), 2 (Unlikely, 1–5%), 3 (Possible, 5–20%), 4 (Likely, 20–60%), 5 (Almost Certain, >60%). Impact levels (applies across technical, financial, regulatory): 1 (Negligible: no service impact, <$10k), 2 (Minor: small degradation, $10–100k), 3 (Moderate: customer experience affected, $100k–$1M), 4 (Major: sustained outages or material financial loss, $1M–$10M or regulatory notice), 5 (Critical: breach, legal action, multiyear reputational/regulatory harm, >$10M). Define thresholds: 1–6 Green (accept), 7–12 Yellow (monitor/mitigate), 13–25 Red (action required). Align with risk appetite by mapping acceptable maximum scores per domain (e.g., regulatory risks: appetite low -> any score ≥7 triggers legal review). Use qualitative descriptors and examples so stakeholders consistently score risks; include periodic calibration sessions and require documented owner and mitigation for Yellow/Red.

Three techniques: 1) Dependency mapping workshops — bring squads together to draw end-to-end flow diagrams and annotate inputs/outputs; effective because visual maps reveal hidden handoffs and implicit assumptions. 2) Contract/interface inventory — require teams to list APIs, schemas, SLAs, and owners; effective because explicit contracts force teams to surface dependencies and versioning constraints. 3) Integration readiness checklist and spike demos — short cross-team integration spikes with acceptance criteria surface failures early; effective because doing an actual integration exposes timing, auth, and data mismatches before mainline work continues.

Approach: quantify uncertainty per high-risk feature, convert to schedule reserve (time) and contingency budget (cost).

Inputs & assumptions:

• Three high-risk features: estimate base-case durations and optimistic/pessimistic (PERT: (O+4M+P)/6)
• Probability of risk realization (p1,p2,p3) from subject-matter experts
• Cost impact if risk occurs (additional dev hours, testing, rework)

Calculations:

• Use PERT to compute expected duration and variance per feature. Sum means to get baseline schedule.
• Schedule reserve = sum of (p_i * (P_i - M_i)) or use sqrt(sum(variance)) * confidence factor for program-level reserve (e.g., 90% CI).
• Contingency budget = sum(p_i * expected cost_if_realized) + overhead (10–15%) for integration unknowns.

Updating reserves:

• Recompute monthly or at key milestones as uncertainties resolve: reduce reserve when risks are retired or when mitigations prove effective; transfer unused reserve back to program.
• Maintain an audit trail of reserve drawdowns with approvals (TPM approves <=X, PMO/executive for larger draws).

Communication: publish reserve burn-down and remaining contingency in weekly program reports.

Goal: integrate forensic steps without blocking remediation or operational continuity.

High-level steps and ownership:

1. Detection & Triage (SOC / Ops lead): confirm scope, implement containment short-term (isolate endpoints, stop exfil channels) — immediate.
2. Preserve Evidence (Forensics team lead): take snapshots, collect logs, preserve chain-of-custody — within 12–24 hours of containment.
3. Parallel Remediation (Engineering owners): continue remediation on segregated systems or copies to restore services — ongoing, directed by TPM to avoid contamination.
4. Forensic Analysis (Forensics & Security): deep root-cause analysis on preserved artifacts; produce indicators of compromise (IOCs) — 3–7 days depending scope.
5. Rebuild & Validate (Engineering + QA): rebuild systems using clean images; apply fixes; validate against IOCs — iterative.
6. Post-Incident Reporting (TPM + Security): summarized findings, timeline, and recommended controls.

Coordination rules to avoid disruption:

• Read-only copies: Forensics uses preserved snapshots; remediation uses fresh environments to test fixes.
• Change freeze for affected systems until preservation complete; exceptions approved by Incident Commander.
• Daily standups with clear agenda: evidence status, remediation progress, blockers.

Outcome: preserves legal/forensic integrity while enabling remediation in parallel, with clear owners and minimal service disruption.