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?
This is a fill-in question, and the page treats it that way. There is no model story here because a borrowed one collapses on the second follow-up, which is always some version of and what happened to it. What can be taught is the shape: how you shrink a production failure into something a stranger can run in ten seconds, what a report has to contain before anyone reads it, and how a patch actually reaches a release. It is also worth knowing which honest positions score, because several do, including never having filed one. This page gives you a speakable structure with your own material dropped into it, and the specific claim that ends the conversation badly.
What the interviewer is scoring
Score points for a self-contained reproduction, a hypothesis grounded in the documentation or the source, and knowing the report-review-commitfest loop, not for name-dropping.
In short: 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.
The scaffold for your own answer
- The full 90-second answer, written first person, the way you would actually say it
- How I reason through it: the mechanism, the decision points, and where the claim stops
- A fill-in scaffold for your own story: the beats, the timing, and the follow-ups it invites. We do not write the incident for you.
- Worked responses to the 3 follow-up probes listed above, plus the traps that lose the point
Card required. Cancel before day 7 and you are not charged.
How to reason through it
- Describe how you isolate an unidentified issue: shrink to a minimal reproduction and diff behavior against the documentation or the source.
- Show the reporting path: a reproducible test case rather than a prose description.
- Mention the patch loop: a fix WITH a regression test, posted to a commitfest, iterated under review.
- Be exact about what you personally did; the follow-up is always about the outcome.
What I would verify
- Confirm the reproduction still fails with the application removed; most do not, and that is a useful result.
- State the version and build, because behaviour differences across releases are the usual explanation.
- Compare observed behaviour against what the documentation promises, and quote the specific sentence.
- Check whether it has already been reported before claiming novelty.
Follow-ups they push on
- What happened to the patch in the end?
- How do you know it was not already reported?
- You have never done this. Is that a problem?
The probes are open. Pro carries the spoken scaffold, the beats, and the follow-up handling, including a worked response to each of these.
Concepts tested
Learn it, run it, then say it
Three steps, in order. Nothing here is a detour.
1 · Learn the mechanism
Understand it before you try to say it.
2 · Practise it for real
Run it once so the answer describes something you have seen.
3 · Rehearse the next question
Keep going while the mechanism is fresh.
Questions that go with this one
- staff · ProStart with the highest-severity issue you've personally owned, the one that pushed your limits.The other question where your own history is the answer and the structure is the coaching.
- senior · ProWhen you propose a new observability signal, how do you justify it, why that metric, and what does it cost to collect?Also about making a case from evidence rather than from authority.