This is the Principal-level systems thinking question. The interviewer wants structure, prioritization, and depth — not a random list of commands.

Incident triage methodology

Phase 1 — Quantify: what's actually slow? Which query/table/operation? Since when?

Phase 2 — Immediate relief: kill blocking queries, kill long-running idle transactions

Phase 3 — Identify hottest queries: pg_stat_statements ORDER BY total_exec_time DESC

Phase 4 — Explain the worst query: EXPLAIN (ANALYZE, BUFFERS) — look for seq scans, bad estimates

Phase 5 — Check system resources: CPU, I/O wait, memory pressure, connection count

Phase 6 — Check for lock contention: pg_stat_activity WHERE wait_event_type = 'Lock'

Phase 7 — Check for bloat: n_dead_tup, last_autovacuum — is VACUUM behind?

Phase 8 — Implement fix: index, query rewrite, or VACUUM

Phase 9 — Verify and document: before/after metrics, root cause, prevention

Common root causes by symptom: sudden slowdown with high I/O wait → autovacuum running or index bloat. Sudden slowdown after deploy → plan regression (stale stats after schema change, run ANALYZE). Gradual slowdown over weeks → data growth past index threshold, table bloat. Spike-and-recover pattern → lock contention from long transactions. Steady increase in query time → N+1 queries introduced in new code or missing index on growing table.

Principal-level deliverable: After any performance incident, write a postmortem with: the query/queries involved, the root cause (index missing, stats stale, connection exhaustion), timeline, the fix applied, and what will prevent recurrence (alert added, index created, VACUUM frequency tuned). This turns a reactive incident into a proactive improvement — that is the Principal Platform Engineer's job.