Trees & Graphs

Trees are the loudest single bucket in Atlassian coding rounds, and the round that carries them, the Data Structures interview, often opens with an empty editor. No TreeNode class, no adjacency list, no parser to turn input into a structure. You define the node, you build the test input, then you solve. Candidates who have only ever filled in a function body inside prepackaged scaffolding lose the first few minutes hunting for a class that was never going to appear. Write it from memory. Practice typing the node and the graph by hand so that part is reflex and the clock goes to the algorithm.

Atlassian builds team software: Jira for issue tracking, Confluence for docs and wikis, Trello for boards, Bitbucket for code. Every one of those products is a hierarchy at heart. A Jira epic holds stories, a story holds subtasks. A Confluence space holds a page tree many levels deep. An org directory nests employees under managers. So the classic tree and graph problems arrive here in that language, and an interviewer will sometimes hand you the product framing and watch whether you spot the traversal underneath. The bar is a solid medium. The set is standard: depth-first and breadth-first traversal, each iterative and recursive, plus the two graph workhorses of reachability and dependency ordering.

The Atlassian angle

Type the structure first, before you touch the algorithm. When the editor is blank, the opening move is the scaffold: a node with a value and child pointers, a children list built from parent indices, or a defaultdict(list) for a graph. Narrate why as you build, that a Jira hierarchy is a node with a parent and any number of children, that an adjacency map ties each node to its neighbors. This is partly a real-skill check and partly an Atlassian habit, since the products themselves are trees to the core. An interviewer who watches you scaffold a clean structure in twenty seconds is watching someone who has modeled data before, not only memorized answers.