Atlassian Interview Experiences

1. 🔹

   Telephonic Screening

   A recruiter emailed me in August about a Principal Engineer opening and the first step was a phone screen with an engineering manager, about an hour long. He started by asking me to walk through my current role and the biggest system I had owned, which took around fifteen minutes. Then he asked me to design an LRU cache — not to code it, just explain the data structures. I described the hashmap plus doubly linked list, explained why both operations were O(1), and he asked what changes if it has to be thread-safe. I talked about locking the list and where a striped approach would help. The last part was a conversation about designing a collaborative document editor, like Google Docs, with file storage and search over the stored files. I covered how concurrent edits get merged, where the files live, and how a search index gets built from them. It stayed high level because we were on the phone. He said the recruiter would follow up, and a week later the full loop was scheduled.

2. 🔹

   Values Round

   The on-site loop was spread across two days on video. The first round of day one was the values round, 45 minutes, with someone from a completely different team. She explained up front that she would ask situational questions and that each one tied back to one of the company's stated values. The first was about a time I had to share bad news with stakeholders. I told the story of a launch we had to delay and how I communicated it. The next was about a time I disagreed with a decision because of its impact on customers, then one about helping a team succeed when it cost me something personally. For each story she asked follow-ups about what I specifically did and what happened afterwards. I tried to keep every answer to a concrete situation, my action, and the result. It was conversational and she took notes throughout. There was no technical content at all. We ended a couple of minutes early and she asked if I had questions about the culture, so I asked how the values show up in code reviews.

3. 🔹

   Leadership Craft Round

   Right after the values round, with a short break, came the leadership craft round with a senior engineering leader. It was an hour. He said the goal was to understand how I lead as an engineer, not as a people manager. The first question was about the biggest technical direction I had driven across more than one team. I described a migration I had led, how I got agreement from the teams involved, and where it went wrong in the middle. He dug into that part — what I did when a team pushed back, how I decided what to cut. Then he asked about a time I had to grow someone more junior into owning a large piece of work, and about a technical decision I had made that I now think was a mistake. I answered honestly on that one and explained what I would do differently. At the end he asked what I would want to work on in my first six months at the company. The round felt fair and I came out of it feeling fine.

4. 🏗️

   System Design Round

   Day two opened with the dedicated system design round, one hour, with a principal engineer. The problem was a web-scraping system: take URLs, crawl them, extract the images, and expose specific API endpoints — one to submit a crawl job, one to check its status, and one to fetch the extracted images. I first asked about scale and whether we crawl beyond the submitted page, and he said assume a bounded depth. Then I laid out the pieces on the whiteboard tool: an API layer that writes a job record and puts URLs onto a queue, a pool of fetcher workers with per-domain rate limiting, a parser step that pulls image URLs out of the HTML, an image download step that stores the files in object storage, and a metadata database that ties images back to the job. He asked how I would avoid fetching the same URL twice and how a job reports progress when it is split across many workers. I covered a seen-URL set and a per-job counter. We ran slightly over time on the failure-handling discussion.

5. 🔹

   Code Design Round

   Next was the code design round, an hour, in a shared editor. The problem was a cinema scheduling system: a cinema has screens, each screen has showtimes already booked, the cinema operates from 10 AM to 11 PM, and given a new movie with a duration I had to decide whether it can be fitted into the schedule without conflicts. I spent the first ten minutes agreeing on the classes — Cinema, Screen, Showtime, Movie, and a ScheduleManager that does the fitting. Then I wrote the core method: for each screen, sort its showtimes, walk through the gaps including the gap before the first show and after the last, and check whether any gap is at least the movie's duration within operating hours. The interviewer asked about a cleaning buffer between shows, so I added it as a parameter on the screen. Then she asked how I would return the actual slot instead of a yes or no, and I changed the method to return the earliest fitting slot. I wrote two quick test cases at the end.

6. 🔹

   Data Structures Round

   The final round was data structures, one hour, and it was the one that hurt me. The problem was an employee hierarchy — groups containing sub-groups and employees — and given a set of employees, find the closest parent group that contains all of them. I knew it was a lowest-common-ancestor question, but I started by explaining how I would represent the tree, then how parent pointers work, then how ancestor chains are built, and I spent far too long on those basics before writing anything. By the time I started coding the ancestor-chain intersection, more than half the hour was gone. The code itself was fine and passed the example, but the interviewer only had a few minutes for follow-ups, and I could not get to the case where an employee ID is missing. I knew as I left that the round had been weak. About a week later the recruiter came back with an offer at P50 instead of the P60 role I had interviewed for. I thought about it for a few days and declined.

Key takeaway: Preparation in hierarchical/tree data structures pays off — this candidate spent too much time re-explaining basic tree concepts in the final round, and ultimately declined a downlevel offer after a weak showing in that coding round.

1. 💻

   Round 1 (DSA)

   A recruiter contacted me in the first week of January and the loop was set up as three back-to-back video rounds on one day. The first was DSA, one hour. The interviewer shared a doc describing a company hierarchy — departments containing sub-departments and employees — and asked me to find the closest department that covers a given list of employees. I recognised it as a lowest-common-ancestor problem and started coding almost immediately. I built a parent map, walked up from each employee, and intersected the ancestor chains. It worked on his example. Then he asked what happens if one of the employee IDs is not in the hierarchy at all. My code would have crashed on the lookup, and I had to patch it in while he watched. He also asked whether I had thought about an employee appearing twice in the input. I had not. We finished on time but I could tell those two misses mattered. Later feedback confirmed this round was a no-hire, mainly for jumping in without asking any clarifying questions first.

2. 🔒 2 more rounds — continue this journey in the full kit

1. 🔹

   Karat Elimination Round

   I applied on the careers page in April and got an email a week later to book a Karat screening slot. It was a one-hour video call with a third-party interviewer, not an Atlassian engineer. He started with five short system-design questions, all situational — things like what you would do if a service's latency suddenly doubled, or how you would keep two data stores in sync. Each one had about three minutes, so I gave direct answers and moved on. Then came two coding problems in a shared editor. The first was an easy array question, which I finished in about ten minutes and walked through with a test case out loud. The second was a medium string problem; I explained a hashmap approach first, wrote it, then ran through the edge cases he suggested. He did not give any hints or feedback during the call, which felt odd, but two days later the recruiter wrote back that I had cleared it and the on-site loop would follow.

2. 🔒 5 more rounds — continue this journey in the full kit

1. 🔹

   Karat Screening

   A recruiter reached out on LinkedIn in June for a backend SDE-2 role and the first step was a Karat screening. I picked a weekday evening slot and the call ran for about an hour. The interviewer began with five system-design questions, one after another, each expecting a short spoken answer — how I would cache a read-heavy endpoint, how I would handle a message queue backing up, what I would check first when a database started timing out, and so on. I kept my answers to a minute or two each and named the trade-off in every one. After that we moved to a code editor for two DSA questions. The first was an easy hashmap problem, which I finished quickly and tested with two inputs. The second was a medium two-pointer problem; I talked through the brute force first, then the optimised version, then coded it. He asked me to dry-run it on one edge case. The result came a few days later as a hire, and the recruiter scheduled the full loop for the following weeks.

2. 🔒 5 more rounds — continue this journey in the full kit