Atlassian engineering interviews: what Atlassian says, plus a system-design drill
Atlassian
What the employer says
Atlassian’s engineering interview handbook describes coding in data-structures and code-design parts. Its systems design stage explores practical constraints such as reliability and cost, and follow-ups can change constraints to explore learning agility. Manager and values conversations are described as separate parts of the process.
Source: Atlassian: interviewing for engineering, checked 7 November 2026. Your own invitation takes precedence.
Try it: an original exercise
Original design exercise: delivery notifications
A small service sends customers an email after a confirmed purchase. Compare a direct send in the checkout request with a queued design. Neither is universally best.
Fewer components to operate. But a slow or failing email provider can delay checkout if email is part of the synchronous request. Decide whether confirmation requires successful email delivery.
For queued delivery, explain retention, retry backoff, a dead-letter path and a deduplication key per purchase. For direct delivery, explain what the customer sees if the provider fails and how you prevent an email retry from creating another purchase. Keep payment success separate from email delivery.
Notes stay in this open page only. Refresh clears them.
Explain the decision
- Ask for traffic, delivery-delay tolerance and failure expectations.
- Describe the simplest design that meets those constraints.
- Name what you gain, what you operate, and how you would notice failure.
Scope and sources
The exercise on this page is original Prepti practice. It is not an actual employer question, a simulation of a proprietary assessment, an official marking rubric or a predictive score. Your role, location and invitation take precedence over any general guide.
All employer guides: prep by company.
Outage arithmetic: a queue is not a recovery plan by itself
Original follow-up: notifications arrive at 30 per second. The provider is unavailable for 20 minutes. Assume every notification must be retained, arrival rate is constant and no work is completed during the outage. After recovery the worker can complete 60 notifications per second while new traffic continues.
Reveal the backlog and drain time
The outage creates 30 × 1,200 = 36,000 queued notifications. Recovery capacity exceeds ongoing arrivals by 30 per second, so clearing that backlog takes another 1,200 seconds, or 20 minutes. If capacity is only 30 per second, the backlog never shrinks under these assumptions.
Real delivery latency also depends on ordering, retries, failures and load variation. Rate-limit the worker to the provider’s actual capacity, define retention and monitor oldest-message age. An empty dead-letter queue does not prove every notification was delivered.
Now consider a lost acknowledgement after the provider sends the message. Retrying can send a duplicate unless the destination supports an effective idempotency contract. An internal “sent” flag alone cannot guarantee exactly-once external delivery across that failure. Explain the acceptable user outcome and how you would detect or bound duplicates.
Plan cross-team gates and technical dependencies
Original Prepti practice extension, added November 11, 2026. Fictional inputs, not employer questions or scoring rules.
Compare other tech-employer preparation
Each employer has its own process. Use your actual vacancy and invitation to choose what to practice.