Tell me about a time you unblocked yourself by writing code in a repo your team didn't own.
answer
- the block, and why waiting lost
- you asked before you opened the pull request
- written to their conventions and tests
- who reviewed it, how long it took
- who owns that code today
basics
~20 sTests whether you can clear a blocker by doing the work yourself without trampling another team's ownership. Answer with the ask you made before writing anything, the patch built to their standards, and who maintains it now.
how to answer
5 beats- what you were blocked on, and why waiting lostSet it up in two sentences: what you could not do, who owned the code, and what the wait would have cost. Keep setup to roughly fifteen to twenty percent of your airtime; the interviewer needs only enough to see that writing the code yourself was proportionate.
- the conversation you had before writing anythingSay who you asked, what you asked for, and what constraint came back. This beat is the difference between a contribution and an intrusion, so never skip it — even a comment on an issue counts, and the constraint they gave you usually made the change smaller.
- how you built it to their standardsThe bulk of the answer sits here and in the next beat, around sixty percent together. Be concrete about conforming: their patterns, their test style, their changelog, their flag or opt-in requirements, and the nicer design you abandoned because it did not look like their code.
- getting it reviewed and mergedName the mechanics — who reviewed it, how long it took, how you followed up without nagging, what you changed on their feedback. If it stalled, say how you nudged and where. This is where interviewers hear whether you can operate inside someone else's process.
- what it unblocked, and who owns it nowClose with the effect on your own delivery, with a number, and then the maintenance answer: who reviews it, who is on the hook, whether it is still there. Result and this reflection are about a quarter of your airtime, and the ownership sentence is what separates a contribution from a drive-by.
your answer
5 story prompts- Pick a change you personally wrote in a repo your team did not own.
- Note who you asked first and what constraint they handed back.
- Have the review timeline ready: who reviewed it and how long it took to land.
- Name what you gave up from your preferred design to make it mergeable.
- Be ready to say who maintains that code today, even if the answer is nobody.
draft and rehearse your own answer in a learn session
go deeper
This prompt probes ownership past your own team's boundary. Interviewers want to know whether you can move a blocker by doing the work yourself while respecting another team's standards, review process and long-term maintenance, rather than forking around them or hiding a local hack. It also tests influence: landing a change in a repo where you hold no authority.
We were trying to work out why people were dropping out of a multi-step onboarding form, and we couldn't see it. The shared form package that renders our fields emitted nothing when a field failed validation, so our instrumentation only ever knew about successful submits. There was an open issue about it in the public repo with a couple of upvotes and nobody assigned. I didn't want to monkey-patch it locally where it would quietly rot, so I commented on the issue with the exact event shape I wanted and asked whether they would take a pull request. A maintainer said yes, with one constraint: no new dependency, and the event had to be opt-in so nobody else's behaviour changed. That constraint made the change small — a shade under eighty lines, plus tests written in the style they already used and a changelog entry. It sat for nine days. I nudged once in their weekly triage thread rather than pinging anyone directly, and it merged. Once we picked up that release, we could finally see that a single postal-code field was throwing roughly two-thirds of our validation errors, and fixing that field is what moved our numbers. What I took from it: asking for the shape of the patch before writing it turned a maybe into a merge, and the whole cost of asking was one comment.
Strong because the permission conversation comes before any code, the maintainer's constraint visibly shrinks the change, and the story ends in the candidate's own measurable outcome rather than at merged. Losing the tests, the changelog line or the nudge-in-public detail would drop this to a drive-by contribution.
My team's checkout surface was blocked on server-side rendering support in the shared component package. Without it, first paint carried a visible layout shift on the highest-traffic route we owned, and the team maintaining that package had it slotted for the following half. Their maintainer was plainly underwater, so I offered labour rather than pressure. I asked their lead for a scoped agreement rather than a favour. We would implement the render path behind a flag inside their repo; we would take the pager for anything that broke in it for one release cycle; in exchange we wanted review turnaround inside three days and one of my engineers added as a reviewer on that directory. She agreed and wrote it into the repo's ownership file, which mattered more than the handshake did. It took two of my engineers about five weeks. The thing I insisted on internally was that we build it their way — we threw out a cleaner abstraction because it didn't match the pattern the rest of the package used, and that is why it was still theirs and still maintained long after we moved on. Layout shift on that route went from a quarter of a second of movement to effectively none. My engineer stayed on as a reviewer there, which turned out to be worth more than the patch.
The senior markers are trading real labour and on-call for review capacity, putting the arrangement somewhere durable rather than in a chat, and deliberately discarding a better design so the code stays maintainable by its owners. Without the maintenance answer this would read as a large unowned contribution.
A small, well-scoped fix is a perfectly strong story at this level. What the interviewer wants is that you asked first, read the contribution guide, matched the surrounding style, and took the review comments without defensiveness. Show curiosity about their code rather than criticism of it.
Aim for a feature-sized contribution you scoped deliberately to what their maintainers would accept, then the thing you shipped on top of it. Say what you cut from your ideal design to make it mergeable — that trade is the mid-level signal.
The interesting decision is patch versus temporary fork versus wait, priced. Say what you chose and why, and answer the maintenance question out loud: who reviews this next time, who gets paged, what happens when the owning team wants to change it. Offering your team's labour or on-call as part of the deal reads strongly.
One merged patch is an anecdote; the mechanism is the story. Talk about making contribution the normal path — ownership files, review rotations, contribution guides other teams can actually follow, and the norm that a blocked team may bring a patch rather than a ticket.
saying these in an interview costs you the question
- Landing the change without telling the owning team first
- Forking permanently to avoid their review, with no exit plan
- Explaining that you went in because their codebase was a mess
- No mention of tests, conventions, or how the change got reviewed
- Leaving code you wrote inside someone else's repo with no owner named
- A result that stops at merged, with no effect on your own delivery
- How did the owning team react when they saw your pull request?Be honest, including if the first reaction was wary. The reassuring answer names what you did to lower the threat: asking on the issue first, keeping the change small, matching their patterns, offering to carry the tests. If it landed badly, say what you would open the conversation with next time.
- Who maintains that code today?Answer directly, even if the answer is uncomfortable. Best is that it went back to them and survived because it looked like their code. Acceptable is a named shared arrangement. Weak is not knowing, or discovering it was reverted after you left it. Interviewers ask this specifically to find drive-by contributions.
- What would you have done if they had rejected the change?Show you had a costed fallback rather than a grudge: a narrower version, a local adapter with a removal date, a scoped shim, or accepting the wait and reprioritising. Also worth saying what would have made you accept their no — their reasons for rejecting are often good ones you could not see from outside.