Atlassian's interview process is a classic multi-gate design: you advance to the next stage only after clearing a gate, so the pace is steady, but it evaluates overall ability thoroughly. The most Atlassian-flavored—and easiest to be caught off guard by—is the Code Design Interview: OOD-leaning coding rather than algorithm problems. This post breaks down the whole process and this round's high-frequency problem families.
Atlassian Interview Process (Multi-Gate)
| Gate | Content | Duration | Trait |
|---|---|---|---|
| Gate 1 | Technical screen | — | Short coding + light system design; validates basics, rarely gates out |
| Gate 2 | Full technical loop | 2h | Code Design (1h) + Data Structure (1h, standard LeetCode medium) |
| Gate 3 | System Design | 1h | Requirements, architecture, scalability, trade-offs; heavier for senior |
| Gate 4 | Soft skill | ~1.75h | Values Interview (45min) + Management Interview (1h), BQ-leaning |
After clearing all gates comes a hiring committee review, where the committee weighs all interviewer feedback for the result.
What the Code Design Interview Is Like
This round requires implementing code in a local IDE with screen share throughout. The interviewer gives only a problem description and function signature—no starter code or test framework—so you build from scratch. It feels more like OOD-leaning coding, and the evaluation centers on:
- functional correctness;
- clarity of code structure;
- ease of extension;
- good abstraction and separation of responsibilities;
- naming, class decomposition, and thought process (observed live).
Snake Game: the Highest-Frequency Classic
Among all code-design problems, the most frequent—nearly universally known—is the Snake Game. Its core features revolve around three points:
- Key turning: up/down/left/right change direction, avoiding illegal turns (e.g. left straight to right).
- Auto-growth: the snake grows when it eats food.
- Collision detection: the game ends correctly when the head hits its own body.
Boundary conditions (walls / wrap-around / fixed board size) usually need you to proactively confirm with the interviewer. Here's a clear, extensible implementation skeleton:
from collections import deque
class SnakeGame:
def __init__(self, width, height, food):
self.w, self.h = width, height
self.food = deque(food) # preset queue of food positions
self.snake = deque([(0, 0)]) # snake body, head at the right end
self.body = {(0, 0)} # occupied-cell set, O(1) collision check
self.dirs = {"U": (-1, 0), "D": (1, 0), "L": (0, -1), "R": (0, 1)}
self.opposite = {"U": "D", "D": "U", "L": "R", "R": "L"}
self.cur = "R"
def move(self, direction):
# ignore an illegal (direct-reverse) turn, keep the current direction
if direction != self.opposite[self.cur]:
self.cur = direction
hr, hc = self.snake[-1]
dr, dc = self.dirs[self.cur]
nr, nc = hr + dr, hc + dc
if not (0 <= nr < self.h and 0 <= nc < self.w):
return -1 # hit a wall, game over
ate = self.food and self.food[0] == [nr, nc]
if ate:
self.food.popleft() # ate food, snake grows (no tail pop)
else:
tail = self.snake.popleft() # no food, remove the tail first
self.body.discard(tail)
if (nr, nc) in self.body: # hit own body
return -1
self.snake.append((nr, nc))
self.body.add((nr, nc))
return len(self.snake) - 1 # current score
Design points: use a deque for the body and a set for O(1) collision checks; remove the tail before the collision check to avoid falsely flagging the cell the tail just left. The round usually ends with actually running it to prove correctness—with limited time a GUI is nearly impossible, so a terminal textual UI with character printing is the safest choice.
Three High-Frequency Code Design Families Beyond Snake
They look very different on the surface but all test engineering-modeling ability.
1) Business-modeling design
Implement a simplified but well-bounded business system: task management, comment system, approval flow, RBAC. The point isn't finishing every feature but how you split domain objects up front—can you cleanly separate entity / service / repository responsibilities, or do you cram logic into one giant class. Interviewers often ask "What if we want to support X later?", testing whether your public API leaves room to extend.
2) State-machine / flow-driven design
Elevators, meeting-room booking, queueing systems, event-driven workflows. The focus is whether you can identify the system's states and their transitions: which operations are allowed in each state, how illegal transitions are handled, whether state changes are managed centrally or scattered. A common trap is controlling flow with piles of if-else—functionally correct but penalized in design; abstracting state + event + transition is what reads as senior.
3) Tool / library design
rate limiter, cache, in-memory store, rule engine. These deliberately downplay algorithmic complexity and emphasize API design and internal structure: can you cleanly separate the external interface from internal implementation, do you expose internals too early, do you consider testing / maintainability / replaceability. These easily turn into "runs but hard to change" code.
Prep Suggestions
| Focus | Practice |
|---|---|
| Snake game | Drill until it runs in a terminal + proactively confirm boundaries |
| Business modeling | Split domain objects first; separate entity/service/repository |
| State machine | Abstract "state + event + transition", avoid if-else piles |
| Library design | Separate interface from implementation; consider testing & replaceability |
FAQ
How many gates does the Atlassian interview have?
Four gates: technical screen, full technical loop (Code Design + Data Structure), System Design, and Soft Skill (Values + Management). You advance only after clearing each, with a final hiring-committee evaluation.
How does Atlassian's Code Design differ from a normal algorithm problem?
Code Design is OOD-leaning coding in a local IDE with screen share throughout, built from scratch given only the problem and a function signature. It scores code structure, abstraction, responsibility separation, and extensibility rather than an optimal algorithm.
How complete should the Snake Game be?
Implement key turning (with illegal-turn handling), auto-growth on eating food, and wall / self collision detection, and proactively confirm boundaries like walls and board size. It usually ends by actually running a terminal textual UI to prove correctness.
What's the efficient way to prep Atlassian Code Design?
Master the Snake Game, then cover the business-modeling / state-machine / library-design families, training "model first, code second." If you want timed mocks of these families, OOD-abstraction drills, or live VO support / VO proxy pairing, share the job description so we can predict the problem set and plan practice.
Preparing for the Atlassian Backend interview?
Atlassian tests engineering-modeling ability, clear abstraction, and extensible design—not algorithm tricks. oavoservice offers full all-gate Atlassian coaching: timed Snake-game / business-modeling / state-machine mocks, Code Design OOD drills, and System Design and Values story polishing, plus live VO support / VO proxy pairing. Coaches include former big-tech senior engineers familiar with Atlassian's "build from scratch + probe extensibility" scoring style.
Add WeChat Coding0201 to get Atlassian problems and mocks.
Contact
- WeChat: Coding0201
- Email: [email protected]
- Telegram: @OAVOProxy