Interview prep
Practise the questions the way the interviewer scores them
These are questions I was actually asked across real senior PostgreSQL hiring loops — one at a cloud Postgres platform, one at a data platform — plus a small core set anyone at this level should be able to answer. Each one shows what the interviewer is really listening for and a reasoning checklist for free; the worked answer and the lab transcript behind it are Pro.
No fabrication. Every technical answer that cites a number was reproduced on a real PostgreSQL 18 lab, and the exact transcript ships with the Pro answer so you can check it. The behavioural prompts — your worst incident, driving a bug upstream, justifying a new signal — coach you on structure only. They do not invent a story for you, because an interviewer catches a borrowed one in the very next follow-up.
2 free in full · 9 Pro · filter by company or search below.
Showing 11 of 11
seniorCore PostgreSQLFreeOpen questionCollapseExplain REPEATABLE READ vs SERIALIZABLE in PostgreSQL and when you would choose each.
A strong answer explains snapshot behavior, anomaly protection, retry cost, and the operational burden of high-contention workloads.
Explain REPEATABLE READ vs SERIALIZABLE in PostgreSQL and when you would choose each.
A strong answer explains snapshot behavior, anomaly protection, retry cost, and the operational burden of high-contention workloads.
What the interviewer is scoring
They listen for whether you tie the isolation level to a business invariant instead of reciting definitions, and whether you admit SERIALIZABLE still needs retries.
Reasoning checklist
- Define what anomalies each level prevents.
- Explain that SERIALIZABLE still requires retries.
- Discuss workload tradeoffs instead of claiming one level is always better.
Concepts tested
How a strong answer sounds
Start from the business invariant, then explain that REPEATABLE READ gives a stable snapshot for the transaction, while SERIALIZABLE adds stronger anomaly prevention by aborting risky execution patterns. Emphasize that both may require retries under contention, but SERIALIZABLE raises the frequency and the need for careful transaction design. Choose SERIALIZABLE when correctness rules are stricter than throughput pressure; otherwise prefer the lowest level that still protects the invariant.
Understand the mechanism
midCore PostgreSQLFreeOpen questionCollapseHow does VACUUM relate to MVCC, and what happens if it falls behind?
A strong answer connects dead tuples, storage bloat, xid horizon pressure, and degraded read performance.
How does VACUUM relate to MVCC, and what happens if it falls behind?
A strong answer connects dead tuples, storage bloat, xid horizon pressure, and degraded read performance.
What the interviewer is scoring
They score whether you reach past 'it frees disk space' to bloat, the xid horizon, and autovacuum backlog symptoms.
Reasoning checklist
- Tie VACUUM directly to reclaiming dead row versions created by MVCC.
- Mention bloat and wraparound risk, not just disk usage.
- Discuss operational symptoms such as slower scans and autovacuum backlog.
Concepts tested
How a strong answer sounds
Explain that MVCC keeps multiple row versions so readers do not block writers, and VACUUM is the process that cleans up versions no active transaction can still see. If it falls behind, dead tuples accumulate, tables and indexes bloat, scans touch more pages, and eventually transaction ID wraparound protection becomes a serious availability risk. A strong operational answer also mentions autovacuum tuning, long-running transactions, and visibility map effects.
Understand the mechanism
staffCloud Postgres platformPro answerOpen questionCollapseYou've got a 50 TB table. Walk me through what ANALYZE actually does at that size — does it read every page?
The interviewer is checking that you know ANALYZE reads a bounded sample of blocks, not the whole relation — and that the sample size is fixed by default_statistics_target, not by how big the table is.
You've got a 50 TB table. Walk me through what ANALYZE actually does at that size — does it read every page?
The interviewer is checking that you know ANALYZE reads a bounded sample of blocks, not the whole relation — and that the sample size is fixed by default_statistics_target, not by how big the table is.
What the interviewer is scoring
They score whether 'it samples, it does not full-scan' is your first sentence, whether you can name the 300 × default_statistics_target rule, and whether you understand the cost is roughly flat as the table grows.
Reasoning checklist
- Lead with the headline: ANALYZE reads a bounded sample of blocks, not the whole table.
- Name the rule — the sample targets 300 × default_statistics_target rows (30,000 at the default of 100).
- Explain the two stages: a random sample of blocks, then a reservoir sample of rows inside them.
- State the consequence: analyze cost is roughly flat as the table grows — 50 TB still samples ~30,000 rows.
- Give the lever: raise STATISTICS on a skewed column for a bigger sample, at the cost of a slower analyze and a larger pg_statistic.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “You've got a 50 TB table. Walk me through what ANALYZE actually does at that size — does it read every page?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
seniorCloud Postgres platformPro answerOpen questionCollapseTake me from that sample to a query plan — what does ANALYZE compute, and how does the planner use it?
They want the chain from raw sample rows to per-column statistics in pg_statistic, and then how the planner turns a WHERE clause into a row estimate.
Take me from that sample to a query plan — what does ANALYZE compute, and how does the planner use it?
They want the chain from raw sample rows to per-column statistics in pg_statistic, and then how the planner turns a WHERE clause into a row estimate.
What the interviewer is scoring
Score points for naming the actual stats — n_distinct, MCV/frequencies, histogram bounds, correlation — and for connecting them to a selectivity multiplied by reltuples.
Reasoning checklist
- List what ANALYZE computes per column: null fraction, average width, n_distinct, most-common values and their frequencies, a histogram, and physical correlation.
- Say where it lands: pg_statistic, surfaced readably through the pg_stats view.
- Explain the planner's move: predicate → selectivity → selectivity × reltuples = estimated rows.
- Note that a wrong n_distinct or a missing MCV is what makes estimates — and plans — go bad.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “Take me from that sample to a query plan — what does ANALYZE compute, and how does the planner use it?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
staffCloud Postgres platformPro answerOpen questionCollapseGive me a multixact scenario and take it deep — when does one get created, and how does it bite you in production?
They want to hear that a multixact appears when several transactions lock the SAME row in a way a single xid can't represent, that it lives in its own 32-bit space with its own wraparound, and the real failure modes.
Give me a multixact scenario and take it deep — when does one get created, and how does it bite you in production?
They want to hear that a multixact appears when several transactions lock the SAME row in a way a single xid can't represent, that it lives in its own 32-bit space with its own wraparound, and the real failure modes.
What the interviewer is scoring
Score points for FK KEY-SHARE locks as the sneaky source, for pg_multixact having its own freeze/wraparound, and for naming member-space exhaustion — not just reciting 'FOR SHARE'.
Reasoning checklist
- Define the trigger: more than one locker on one row (multiple FOR SHARE / FOR KEY SHARE, or a mix with an update).
- Explain the mechanism: the row's xmax becomes a multixact id pointing at a members list.
- Stress the twist: multixacts have their OWN 32-bit space, wraparound, and freezing, backed by the pg_multixact SLRUs.
- Name the sneaky source: foreign-key checks take FOR KEY SHARE on the parent row.
- Name the failure modes: SLRU contention on hot rows, member-space exhaustion halting writes, surprise anti-wraparound multixact vacuums.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “Give me a multixact scenario and take it deep — when does one get created, and how does it bite you in production?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
seniorCloud Postgres platformPro answerOpen questionCollapseWhen we find a bug we send the patch upstream to pgsql-hackers. Have you worked that way — finding something nobody had flagged and driving it to a fix?
They want evidence you can isolate a novel issue to a minimal, defensible reproduction and that you understand how upstream PostgreSQL actually accepts a fix.
When we find a bug we send the patch upstream to pgsql-hackers. Have you worked that way — finding something nobody had flagged and driving it to a fix?
They want evidence you can isolate a novel issue to a minimal, defensible reproduction and that you understand how upstream PostgreSQL actually accepts a fix.
What the interviewer is scoring
Score points for a self-contained repro, a hypothesis grounded in the source or the manual, and knowing the -hackers / commitfest / regression-test loop — not for name-dropping.
Reasoning checklist
- Describe how you isolate an 'unidentified' issue: shrink to a minimal repro harness and diff behaviour against the docs or the source.
- Show the reporting path: pgsql-bugs or -hackers with a reproducible test case, not a prose description.
- Mention the patch loop: a fix WITH a regression test, posted to a commitfest, iterated under review.
- Bring one concrete example you can actually walk through end to end.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “When we find a bug we send the patch upstream to pgsql-hackers. Have you worked that way — finding something nobody had flagged and driving it to a fix?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
seniorData platformPro answerOpen questionCollapsen_live_tup and n_dead_tup are estimates. If I need the real number of tuples in a table, what do you reach for?
They're checking that you know the stats-view counters and pg_class.reltuples are estimates, and that the exact physical truth (plus dead-tuple and free-space breakdown) comes from the pgstattuple extension.
n_live_tup and n_dead_tup are estimates. If I need the real number of tuples in a table, what do you reach for?
They're checking that you know the stats-view counters and pg_class.reltuples are estimates, and that the exact physical truth (plus dead-tuple and free-space breakdown) comes from the pgstattuple extension.
What the interviewer is scoring
Score points for naming pgstattuple for the exact scan, pgstattuple_approx for the cheap estimate, and for knowing the cost trade of a full heap scan.
Reasoning checklist
- Say plainly that reltuples and n_live_tup/n_dead_tup are estimates maintained by ANALYZE and autovacuum.
- Reach for the pgstattuple extension for the exact tuple_count, dead_tuple_count, and free space.
- Offer pgstattuple_approx when a full scan is too expensive — it leans on the visibility map.
- Note that count(*) gives live rows but no dead/free breakdown, and still costs a scan.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “n_live_tup and n_dead_tup are estimates. If I need the real number of tuples in a table, what do you reach for?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
staffData platformPro answerOpen questionCollapseExplain transaction ID wraparound the way the committer sees it — how does Postgres keep a row from four billion transactions ago still visible?
They want the mechanism: 32-bit xids compared modulo 2^31, the commit log recording commit status, and freezing as the thing that lets old xids be recycled safely.
Explain transaction ID wraparound the way the committer sees it — how does Postgres keep a row from four billion transactions ago still visible?
They want the mechanism: 32-bit xids compared modulo 2^31, the commit log recording commit status, and freezing as the thing that lets old xids be recycled safely.
What the interviewer is scoring
Score points for modulo-2^31 visibility, the clog/commit-log role, and relfrozenxid/datfrozenxid + age() as what you actually monitor — plus the anti-wraparound autovacuum and its failsafe.
Reasoning checklist
- State the constraint: xids are 32-bit and visibility is judged modulo 2^31 (half past, half future).
- Bring in the commit log (pg_xact/clog): it records whether each xid committed.
- Explain freezing: marking a tuple unconditionally visible so its inserting xid can be recycled.
- Name what you monitor: relfrozenxid / datfrozenxid and age() — the oldest unfrozen xid.
- Cover the safety net: anti-wraparound autovacuum before autovacuum_freeze_max_age, and the failsafe near the limit.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “Explain transaction ID wraparound the way the committer sees it — how does Postgres keep a row from four billion transactions ago still visible?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
midData platformPro answerOpen questionCollapseYou want to measure a table's access pattern cleanly after a change. How do you reset just that table's statistics without wiping the cluster?
They're probing whether you know the per-table counter reset exists and, more importantly, that it resets ACTIVITY counters — not the planner's column statistics.
You want to measure a table's access pattern cleanly after a change. How do you reset just that table's statistics without wiping the cluster?
They're probing whether you know the per-table counter reset exists and, more importantly, that it resets ACTIVITY counters — not the planner's column statistics.
What the interviewer is scoring
Score points for pg_stat_reset_single_table_counters, for distinguishing it from pg_stat_reset() and pg_stat_statements_reset(), and for knowing column stats in pg_statistic are refreshed by ANALYZE, never 'reset'.
Reasoning checklist
- Reach for pg_stat_reset_single_table_counters(regclass) — it zeroes just that table's counters.
- Contrast it: pg_stat_reset() nukes the whole database's counters; pg_stat_statements_reset() is a separate per-query subsystem.
- Draw the key line: this resets activity counters (seq_scan, idx_scan, n_tup_*), not planner column statistics.
- Note that column stats in pg_statistic are refreshed by ANALYZE, not by a stats reset.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “You want to measure a table's access pattern cleanly after a change. How do you reset just that table's statistics without wiping the cluster?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
seniorData platformPro answerOpen questionCollapseWhen you propose a new observability signal, how do you justify it — why that metric, and what does it cost to collect?
Every signal has to earn its keep: it must map to a decision, and its collection cost and false-positive rate have to be smaller than the pain it prevents.
When you propose a new observability signal, how do you justify it — why that metric, and what does it cost to collect?
Every signal has to earn its keep: it must map to a decision, and its collection cost and false-positive rate have to be smaller than the pain it prevents.
What the interviewer is scoring
They're listening for the decision the metric drives, the collection overhead and cardinality, and the alternative you rejected — not a dashboard wish-list.
Reasoning checklist
- Start from the decision or action the signal enables — if nothing changes when it moves, don't collect it.
- State the collection cost: overhead, cardinality, retention, and who pays it.
- Address false positives — a noisy signal that gets muted is worse than none.
- Name the alternative you rejected and why this one wins.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “When you propose a new observability signal, how do you justify it — why that metric, and what does it cost to collect?” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank
staffData platformPro answerOpen questionCollapseStart with the highest-severity issue you've personally owned — the one that pushed your limits.
This is a signal probe, not a trivia question — they want scale, ownership, and a decision made under pressure. Structure beats storytelling.
Start with the highest-severity issue you've personally owned — the one that pushed your limits.
This is a signal probe, not a trivia question — they want scale, ownership, and a decision made under pressure. Structure beats storytelling.
What the interviewer is scoring
They score: did YOU own it (not 'the team'), what was the blast radius, what did you rule out, and what guardrail did you leave so it can't recur.
Reasoning checklist
- Open with scale and stakes in one line (rows, TB, QPS, who was paged).
- State the signal you saw, then the two or three hypotheses you ruled out — show the diagnosis, not just the fix.
- Name the actual fix and why it was safe to apply under load.
- Close with the guardrail: the alert, runbook, or config that means it never pages anyone again.
- Anchor every number to something you could defend if the panel pushes.
Concepts tested
The worked answer, backed by the lab
The question and what the interviewer is scoring are free. Pro unlocks the worked answer to “Start with the highest-severity issue you've personally owned — the one that pushed your limits.” and the real PostgreSQL 18 transcripts that prove every number in it.
What Pro unlocks here
- The full worked answer — how a strong candidate actually says it out loud
- The real PostgreSQL 18 transcripts that back every number in the answer
- The lever and the trade-off an interviewer probes for after your first sentence
- Written from real senior hiring loops, not a generic question bank