Atlassian Coding Interview Questions & Code Design

The coding loop at Atlassian is two separate rounds, and knowing that before you walk in changes how you prepare. One is a data-structures interview that looks like a standard algorithm round. The other, called Code Design, hands you a real feature to build and runs your code against test cases while you work. Both happen over video, since every Atlassian interview is remote under the company's Team Anywhere model. Both also let you work in your own editor, in whatever language you are fastest in, with a quick search for syntax allowed.

Difficulty sits at the medium tier for most candidates, with the occasional hard problem surfacing in a senior data-structures round. Breadth beats depth here. Trees are the loudest family by a clear margin, trailed closely by problems that ask you to implement a data structure to spec. Intervals and scheduling, arrays and strings with hashing, and a graph problem or two fill out the center of mass. Dynamic programming shows up, but usually the simple kind, so it is not where this interview lives. This lesson maps that surface onto four coding lessons, points you at the drills for each, and names the things that make Atlassian its own interview rather than a generic loop.

The Atlassian angle

The Code Design round is the signature of the Atlassian coding loop, and it is unlike a whiteboard design exercise. You get a business-framed prompt with the function signatures already provided. Your job is to write runnable code that passes tests, then defend the internals and extend it as the interviewer piles on follow-ups. The prompt reported most by name is a cloud a Premium question that returns a customer's peak and yearly spend, with provisional estimates queryable on any day. The design lesson works it end to end. Others show up too. One is the full working logic for a snake game. Another is the closest parent group over a set of people in an employee directory, which is lowest common ancestor framed as an org chart. The grade is a complete, tested implementation you can then evolve. Finishing one inside the hour is genuinely hard. Practice building a small modeled solution end to end under a timer, not just sketching classes.

How does the Atlassian coding interview work?

Before the onsite there is a technical phone screen, and its shape depends on which pipeline you are in. Experienced and lateral hires most often meet a live screen run through Karat, a third-party service whose interviewers are trained senior engineers rather than Atlassian staff. New-grad, early-career, and campus candidates more often get a HackerRank online assessment first, the gate the internship and new-grad loop is built around. That is roughly two to three problems in about ninety minutes, skewed toward string parsing, greedy choices, and simple dynamic programming. Do not assume everyone takes the same route. And do not treat any solve-all-the-problems threshold as a hard rule, because there is no published cutoff.

The Atlassian angle

The Karat screen is its own muscle, and it trips up people who only drilled algorithms. It runs roughly sixty minutes, split in two. First come about twenty minutes of five rapid-fire verbal reasoning prompts. Then about thirty minutes of two coding problems, one easy and one medium, that must actually run. The verbal half is not diagramming. It is debug-out-loud and scaling questions. How would you find why a system suddenly runs slow? What would you upgrade first to take a service from x to y users? The verbal section tends to want around three of five to pass, and some pipelines offer a forty-eight-hour retake. Rehearse talking through a slow or overloaded system out loud, because reasoning fluency is graded here as much as the code.

• Environment: Your own editor, code runs. Live rounds run over video in the language you pick, in your own IDE, with searching for syntax allowed. Code is executed against tests, not left on a whiteboard. The judged signal is how you think, so a working, well-reasoned answer beats a silent optimal one.
• Phone screen: Karat or a HackerRank OA. Experienced hires usually get a ~60-min live Karat screen (rapid-fire reasoning plus two runnable problems). New-grad and campus pipelines more often get a ~90-min HackerRank assessment of two to three easy-to-medium problems.
• Data Structures round: ~45 to 60 min, medium DSA. Classic algorithm work at the medium tier, occasionally a hard. Expect to define your own tree or list node, and sometimes to reach for classes and a custom comparator even in a "DSA" round rather than a single function.
• Code Design round: Build, run, defend, extend. A real-world prompt with signatures provided. Write a passing, tested implementation, then evolve it under follow-ups about efficiency, usability, and extension. This is coded low-level design, not a class diagram.

The Atlassian angle

Atlassian says plainly that it grades how you think over how fast you type, but speed still bites at senior levels. The official stance is that clean code matters and missing a line will not cost you the job. So the loudest non-code signal is narrating your approach and stating complexity before you write it, handling edge cases as you go, and treating the round like pair programming. That said, at senior levels, needing interviewer hints and not finishing a tested Code Design solution both count as real negatives, read as "not independent at this level." The reconciliation to carry in: communicate continuously and still drive to a complete, tested answer inside the hour. Talk the whole time, but do not talk instead of finishing.

What coding questions does Atlassian ask?

The chart below splits the recurring coding problems across families, with the several product retellings of a single problem counted once. Atlassian does not publish these numbers, so the ordering is only how often each family recurs, not something you can hold a given loop to. The headline holds regardless. Trees lead. Problems that implement a data structure to spec sit right behind them as a co-headline, and those two families together are where most of your prep hours should go.

The Atlassian angle

Atlassian hands you standard algorithms named for its own products, and that framing is a genuine tell rather than decoration. A tree problem arrives as the closest parent group in an org directory. An aggregation problem becomes a payments a Premium question over Jira-style billing. Scheduling shows up as meeting or cinema-movie overlaps, and rate limiting maps straight onto the API surface that fronts Jira, Confluence, Bitbucket, and the Marketplace apps built on the platform. Ballot and vote-ranking prompts quietly need a class and a custom comparator. Strip the story down to its pattern fast, solve the pattern, then re-attach the domain in your variable and method names. Naming things after the business problem is the kind of clear, extensible code the room is looking for.

How these lessons are organized

Each lesson below takes one part of the map and works its recurring core as runnable problems, with the Atlassian framing and the follow-ups the room adds. The design lesson doubles as the home for the Code Design round, since implementing a data structure to spec and finishing a coded build are the same muscle. Where a lesson rests on a base data-structures idea, the deep walkthrough lives in the free Foundations course so these pages can stay on what is specifically Atlassian. Start with arrays and hashing, the broad warm-up most loops open on.

Common questions