Top 15 Atlassian Coding Interview Problems, Ranked by Pattern

You solved 200 LeetCode problems and you're ready. Confident, even. Then Atlassian's interviewer says "now do it, but employees can belong to multiple departments" and the tree you just solved turns into a graph you've never seen. That's the Atlassian interview.

Atlassian hires for the company, not a team. Pass the loop, then get matched. That means the DSA round has a recognizable shape across all roles, and candidates report the same problems surfacing repeatedly. This guide covers the 15 problems that appear most often, what each one teaches, and three things about Atlassian's bar that differ from a standard FAANG loop.

What the Atlassian Interview Actually Looks Like

The technical loop has three distinct components: a Karat screen (one coding problem plus rapid-fire system design mini-scenarios), a DSA round (two problems, 45 minutes, full solution expected on the first), and a Coding Design round (implement a working rate limiter, snake game, or similar system in production-quality code). This list covers the DSA round and Karat screen.

Difficulty skews 65% medium, 25% hard, 10% easy. The problems reward clean code over tricks. Interviewers also ask a scale-up question mid-session, adding a constraint after you solve the original problem and watching how you adapt. More on that later.

Trees: Post-Order Thinking and Range Propagation

1. Find Leaves of Binary Tree (LC 366, Medium)

Remove all leaves repeatedly and group nodes by removal round. The naive instinct is BFS by layer, but that solves the wrong problem. Each node's "round" equals its height from the bottom, not its depth from the root. Compute this with post-order DFS, returning height from each node. Atlassian uses this to filter candidates who default to top-down thinking without questioning the framing. Think before you type.

2. Maximum Average Subtree (LC 1120, Medium)

Find the subtree with the highest average node value. The DFS needs to return both sum and count at each node so the parent can compute the average without a second pass. One DFS with a tuple return beats two traversals. A clean test of whether you know what to aggregate during recursion before you start coding.

3. Validate Binary Search Tree (LC 98, Medium)

The parent-only check is wrong. Any candidate who writes node.val > node.left.val will be asked to explain it, and that conversation ends badly. The correct solution propagates valid (min, max) bounds top-down. Passing bounds through recursive calls is the thing being scored, not recognizing that BST validation is needed. This appears in both the Karat screen and the DSA round.

4. Lowest Common Ancestor in a Company Hierarchy (LC 236 + custom, Medium-Hard)

Standard LC 236 tree LCA appears first. Then the scale-up: employees can belong to multiple departments, turning the tree into a directed graph. Tree LCA no longer works.

The multi-parent graph extension requires BFS from both nodes simultaneously with visited sets. This is the most Atlassian-specific problem on the list. Candidates who practiced only the tree version consistently miss it, and they miss it at exactly the moment they feel most confident.

Every Atlassian scale-up question, every time.

Graphs: Real-World Constraints, Not Competitive Tricks

5. Number of Islands (LC 200, Medium)

The canonical BFS/DFS grid traversal. At Atlassian, this is typically the first problem in the DSA round, meant to confirm fluency rather than stress-test limits. Nail the visited-set mechanics, keep the code readable, and explain edge cases before writing. The interviewer is watching whether you talk through the traversal or just type. Spoiler: silent typing does not go well here.

6. Graph Valid Tree (LC 261, Medium)

Given n nodes and edges, decide if they form a valid tree. A tree requires exactly n-1 edges and no cycles. Union-Find and DFS cycle detection both work. The Union-Find solution is preferred at Atlassian because it is easier to extend and clearly separates the two checks (edge count and connectivity). Clean code that reads well matters here.

Linked Lists and Data Structures: O(1) Under Constraints

7. Reverse Linked List in K-Groups (LC 25, Hard)

Reverse every k consecutive nodes in-place. Track the previous segment's tail and connect it to the newly reversed segment. Get the pointer mechanics wrong once and the problem becomes unfixable without starting over. This shows up in senior Atlassian DSA rounds. Practice until the reversal loop is automatic, not something you reconstruct under pressure at minute 30 while an interviewer watches.

8. LRU Cache (LC 146, Medium)

O(1) get and put on a capacity-bounded cache. Requires a doubly linked list for O(1) removal plus a hashmap for O(1) lookup. Sentinel nodes at both ends of the linked list eliminate the edge-case code that otherwise eats minutes. Atlassian uses this to preview whether you write code someone else can maintain, which is the standard for the separate Coding Design round.

9. All O'one Data Structure (LC 432, Hard)

Insert, delete, getMaxKey, getMinKey, all in O(1). The solution uses a doubly linked list ordered by count plus two hashmaps: one from key to its list node, one from count to the set of keys at that count. This is a P50 and above problem at Atlassian. Senior role candidates should know it cold; P40 candidates can treat it as a stretch goal.

10. Time-Based Key-Value Store (LC 981, Medium)

Store key-value pairs with timestamps. Queries return the value with the largest timestamp at or below the query time. Binary search over a sorted list of (timestamp, value) pairs is the full solution. This appears in both the DSA and Coding Design rounds. Candidates who only practiced it as a pure DSA problem stumble when the follow-up asks about persistence and expiry.

Strings and Tries: Readability Over Cleverness

11. Longest Palindromic Substring (LC 5, Medium)

Atlassian interviewers specifically favor expand-around-center over the DP table approach. Both are O(n^2), but expand-around-center is more readable. Writing the expand-around-center version cleanly matters here, not just knowing it exists. Manacher's O(n) solution exists but adds code complexity most interviewers do not want to see at Atlassian. Save Manacher's for the one conversation where they explicitly ask you to optimize.

12. Trie Prefix Matching (LC 14 / custom, Easy-Medium)

Appears as both the LeetCode longest common prefix problem and as a custom variant framed around "search by tag prefix" in Confluence or Jira. Know both the trie construction and the linear scan approaches so you can discuss trade-offs when asked. The product framing changes what the interviewer cares about in the follow-up.

The Real-World Flavored Problems

These three have no standard LeetCode numbers. They are confirmed from Glassdoor and LeetCode Discuss reports and map directly to Atlassian's products. Practicing the abstract version only is how candidates walk out confused.

13. Rate Limiter (Custom, Medium)

Implement a RateLimiter class where each customer can make at most X requests per Y seconds. The isAllowed(customerId) method returns whether the current request is within limit. The sliding window queue approach is expected. The scale-up is adding per-resource strategies (different limits per endpoint). This is also the canonical Coding Design round opening problem at Atlassian.

14. File Dashboard / Top K Collections by Size (Custom, Medium)

Given a list of [FileName, FileSize, [Collections]] entries, output total size per collection and the top N collections by size. One file contributes its size to every collection it belongs to. The multi-collection-per-file constraint is the real test. Candidates who treat it as a simple grouping miss it. Combine hashmap aggregation with a min-heap for the top-K piece.

15. Merge Intervals (LC 56, Medium)

Sort by start time, iterate, and merge overlapping intervals. Reported in both the Karat screen and the DSA round. The single most commonly botched detail is not wrapping the end-extension in max(), which breaks when a short interval is fully contained inside a longer one. Candidates who have solved this before still make this mistake under pressure. Write a test case with a fully-contained interval before you declare done.

Quick Reference

Problem	LC #	Difficulty	Core Pattern
Find Leaves of Binary Tree	366	Medium	Post-order DFS, height grouping
Maximum Average Subtree	1120	Medium	DFS with tuple return
Validate BST	98	Medium	Range propagation
LCA + Org Hierarchy (graph)	236 + custom	Med-Hard	Tree LCA to graph BFS
Number of Islands	200	Medium	BFS/DFS grid
Graph Valid Tree	261	Medium	Cycle detection, Union-Find
Reverse K-Group	25	Hard	Pointer manipulation
LRU Cache	146	Medium	Doubly linked list + hashmap
All O'one Data Structure	432	Hard	DLL + dual hashmaps
Time-Based Key-Value Store	981	Medium	Binary search on timestamps
Longest Palindromic Substring	5	Medium	Expand-around-center
Trie Prefix Matching	14/custom	Easy-Med	Trie construction
Rate Limiter	Custom	Medium	Sliding window + OOP
File Dashboard / Top K	Custom	Medium	Hashmap + min-heap
Merge Intervals	56	Medium	Sort and greedy merge

Three Things That Make Atlassian's Bar Different

Code quality is scored in both rounds, not just correctness. The Coding Design round exists specifically to test whether you write code people can maintain. That standard carries into the DSA round. Messy variable names and unexplained pointer reuse get noticed. After your first working solution, ask: "Could a teammate read this in six months?" If the answer is no, that is the interview feedback before it becomes the interview feedback.

What Atlassian interviewers see when you declare your solution "clean."

Scale-up questions are part of the session, not extras. Problems 4, 13, and 14 all have confirmed mid-interview extensions. The interviewer adds a constraint and watches how you adapt without restarting. Atlassian's engineering interview guide explicitly lists adaptability as a scored criterion. Practice talking through constraint changes, not just solving the original problem. Freezing when the new requirement lands is a signal too.

The custom problems have product framing. The rate limiter mirrors Jira Cloud's API gateway. The file dashboard mirrors Confluence storage. The org hierarchy mirrors Jira's project structure. Candidates who practiced only the abstract LeetCode version occasionally miss what the product wrapper implies about edge cases and follow-up questions.

For a full breakdown of every round in the loop, including the Values interview and the Coding Design problems, see the Atlassian software engineer interview guide.

How to Prepare for the Atlassian DSA Interview

Practice these 15 problems with readable code as the bar, not just passing code.

Run voice-based mock interviews before the DSA round. Atlassian expects narration while you code, and silence is a scored negative. SpaceComplexity runs realistic voice-based DSA mocks with rubric feedback on communication, problem-solving, and code quality, which maps directly to what Atlassian interviewers score.

For the Coding Design round, practice Rate Limiter and Snake Game from scratch independently, targeting under 30 minutes each.

For more on graph patterns you will need here, see Graph Data Structure Interview and Merge Intervals Algorithm. If LRU Cache mechanics feel shaky, LRU Cache Implementation covers the sentinel node approach in depth.

The Short List

• Prioritize these four if time is short: LRU Cache (146), LCA with graph extension, All O'one (432), and the custom Rate Limiter
• Scale-up extensions are documented and expected; practice adapting your solution when a constraint changes mid-interview
• The three custom problems (Rate Limiter, File Dashboard, Org Hierarchy LCA) are the most Atlassian-specific and the hardest to prepare for without knowing they exist

Further Reading

• Atlassian Engineering Interview Guide (Official)
• LeetCode Company-Wise Questions: Atlassian
• LeetCode Discuss: Atlassian P50 Interview Experience, Jan 2025
• LeetCode Discuss: Rate Limiter (Atlassian)
• GeeksforGeeks: Atlassian Interview Questions