HackTheRounds Interview Experiences

Atlassian Backend Software Engineer Interview Experience (2026) - System Design, Offer

A six week Atlassian backend loop covering BFS, resume architecture, a Jira system design exercise, multitenancy, and behavioral interviews.

By HackTheRounds Team · 2026-05-23

Background

I interviewed for a backend software engineer position in Atlassian's Sydney organization after three years at a North American internet company. The process lasted about six weeks and included an HR conversation, a technical phone interview, and two virtual onsite rounds. I received an offer.

The interviews combined coding with architecture and behavioral judgment. The design exercise was especially relevant to Atlassian's product domain: a simplified Jira service with large-scale issue traffic and tenant isolation.

Round 1: Recruiter and Values Conversation

The first call lasted about 30 minutes. We discussed my background, why I wanted Atlassian, which products I knew, and how the company's working style fit my goals.

I prepared concrete product observations instead of a generic statement about culture. For example, a collaboration product has to balance flexible workflows with predictable permissions, search, and notifications. That gave the conversation a bridge from motivation to technical interests.

Round 2: Coding and Resume Architecture

The 60-minute phone round allocated roughly 35 minutes to a breadth-first-search variation. I began with a straightforward traversal, stated the graph representation and visited invariant, then improved the solution as constraints were introduced. Follow-ups asked about space usage and what would change if the input became one hundred times larger.

For scale, I separated algorithmic complexity from memory representation. A theoretically optimal traversal can still fail if adjacency data, queue entries, or object overhead dominate. Depending on the graph, options include compact IDs, bidirectional search when both endpoints are known, external storage, or partitioned traversal. Each optimization depends on the access pattern; “use distributed processing” is not a complete design.

The remaining discussion examined a system from my resume. I was asked why I selected its database, how multitenancy worked, and how I monitored the service. I explained decisions from workload and failure modes: access patterns, transaction boundaries, tenant growth, recovery objectives, and the metrics that would reveal saturation or correctness problems.

Round 3: Design a Simplified Jira

The primary onsite exercise was to design issue creation, updates, deletion, assignment, status transitions, comments, and attachments. The scale assumptions included roughly one million daily active users, about ten operations per user per day, and a historical corpus approaching one billion issues.

I started with entities and APIs. An issue had a stable ID, tenant and project ownership, assignee, status, version, timestamps, and permissions. Comments and attachments were separate resources so they could scale and retain independent metadata. Update APIs needed idempotency and optimistic concurrency controls to prevent silent overwrites.

Status was not just a string. I modeled transitions as a state machine governed by the project's workflow and authorization rules. That made invalid transitions explicit and allowed audit history to preserve who changed what and when.

For notifications, the write path committed the business change and an outbox record together. A publisher then delivered events to Kafka, where consumers could produce email, in-product notifications, analytics, or search updates. This avoided making a user request wait on every downstream system and reduced the risk of losing an event between a database commit and message publication.

Search used Elasticsearch as a derived index, not the source of truth. Event-driven updates could make search temporarily stale, so I described reconciliation, replay, and how the UI should behave immediately after a write.

Tenant isolation prompted comparison among shared tables with tenant keys, schema-per-tenant, and database-per-tenant. Shared tables are operationally efficient but require rigorous authorization and indexing. Dedicated databases offer stronger isolation but increase cost and fleet-management complexity. A mature platform might use a shared default with dedicated placement for unusually large or regulated tenants.

Round 4: Behavioral Interview

The final round asked about a disagreement, a proactive improvement, a wrong decision, and delivering under a deadline. I used examples with a clear decision point, the evidence available at the time, my individual contribution, and what changed afterward. For the mistake story, I focused on detecting and correcting the error rather than disguising it as a strength.

Failure Modes I Discussed

A Jira-like design needs explicit behavior when dependencies fail. If notification consumers lag, issue writes should continue while backlog age triggers an alert. If Elasticsearch is unavailable, direct issue retrieval remains available and search can degrade visibly rather than returning silent false negatives. Attachment uploads need size and type limits, malware scanning, object-store lifecycle rules, and authorization on both upload and download. Tenant IDs must be derived from authenticated context instead of trusted from a request body. These operational details helped connect the diagram to a service that could actually be run.

Result

Reference checks began shortly after the onsite, and I received a verbal offer about a week later. The complete process took roughly six weeks.

Preparation Takeaways

  1. Practice BFS follow-ups that change memory and scale constraints.
  2. Be ready to defend database and tenancy decisions from actual access patterns.
  3. Treat workflow transitions as domain rules, not arbitrary field updates.
  4. Know the transactional outbox pattern and the limits of asynchronous indexing.
  5. Compare tenant-isolation models using security, cost, scale, and operations.
  6. Prepare behavioral stories about disagreement, initiative, mistakes, and deadlines.
  7. Keep APIs, data ownership, consistency, and failure recovery visible throughout system design.