Design a Pipeline From Bug Tickets to Generated Pull Requests
Design a system that watches a bug tracker, and for each eligible bug ticket produces a pull request fixed by an AI coding agent. A fix takes about thirty minutes of agent time; the repository is large; several hundred tickets may arrive in a day.
Cover how tickets enter the system, the state a ticket moves through, how work is scheduled and bounded, how retries work when the agent step or the Git step fails, and how the system avoids opening two pull requests for one ticket.
Hints
Hint 1
A poller or webhook writes a ticket row; a queue feeds workers; an explicit state machine — NEW, QUEUED, FIXING, PR_OPEN, FAILED — is what makes retries and monitoring sane.
Hint 2
One idempotency key per ticket covers both the agent run and the pull request: a worker checks the state before each expensive step and the branch name derives from the ticket id.
Hint 3
Thirty-minute jobs need a long visibility timeout with heartbeats; the retry policy for the AI step (expensive, non-deterministic) differs from the Git step (cheap, deterministic).
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.