Atlassian Backend Developer Interview Questions
Backend work at a company that makes team tools such as Jira, Confluence and Bitbucket is about shared data that many people change at once: issues, pages, comments and permissions. Prepare to talk through edits that collide, permission checks on a tree of pages, events sent to outside apps, and background jobs that must not fail quietly. What to show here: careful handling of shared team data and the apps built on it. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Atlassian hires, in its own words, and its questions for every job →
1. Tell me about a time a change you shipped made an API slower or different for outside developers who had built integrations on it. How did you find out and what did you do?
- Describe the change and who depended on the API.
- Explain how the problem came to light.
- Show the quick fix and the communication.
- Share what you put in place so it would not repeat.
“At my last job I added extra fields to a list endpoint, which meant one more database query per item. Our own screens were fine, but a partner's integration that fetched large lists began to time out. We learned it from their support ticket, which was too late. I first put the new fields behind an optional parameter so the default response was fast again. Then I wrote to the partner with what happened. Afterwards I added a test that measures response time for a large list, and a dashboard of latency by caller. The result was your result.”
Weak answers say the outside developers should have coded better, or fix it without telling anyone affected.
2. Describe a time a background job, such as sending notification emails or rebuilding a search index, was failing quietly and nobody noticed for a while.
- Describe the job and how it failed.
- Explain how it was noticed and how long it had been broken.
- Show how you repaired the missed work.
- Share the monitoring you added.
“In a past project we had a job that sent a daily summary email to users. A change in a template made the job throw an error for users with no activity, and it stopped at the first such user. Nobody noticed until a customer asked why the emails had stopped. I fixed the template, then made the job handle each user separately so one failure would not stop the rest. I also added a count of emails sent per run and an alert if the count dropped sharply. We resent the missed summaries with a short apology. The result was your result.”
Weak answers fix the bug only and add no way to notice the next silent failure.
3. Pages in a wiki sit in a tree, and a restriction on a parent page also applies to every page under it. How would you design the check for whether a user can view a page?
- Clarify the rules: who can restrict, and how parents affect children.
- Show the simple way of walking up the tree on each view.
- Explain storing the full list of ancestors or the computed restrictions per page.
- Cover what happens when a page moves or a restriction changes.
“The simple design walks from the page up to the root and checks each restriction. That is correct but slow for deep trees and very slow for search, where I must filter many pages. So I would store on each page the list of its ancestors, and keep a table of restrictions by page. One query can then fetch all restrictions that apply. For search, I would store the computed set of allowed groups in the index. The cost moves to write time: when a page is moved or a restriction changes, a background job updates the pages below it, and until then I fall back to the slow check.”
Weak answers cache permissions with no plan for page moves, so users keep seeing pages they should have lost.
4. Each project gives its issues a key that counts up, one after the other. How would you generate the next number when many people create issues in the same project at the same moment?
- Explain the race when two requests read the same last number.
- Describe a counter row per project updated inside a transaction.
- Discuss the lock this creates and whether gaps are allowed.
- Mention the unique constraint as a final guard.
“If two requests both read the highest number and add one, they create the same key. I would keep a counter row per project and increase it in the same transaction that inserts the issue, using an update that returns the new value. The database locks that row for a moment, so requests for the same project line up, but other projects are not affected. If the insert fails later, that number is lost, so I would ask whether gaps are acceptable. They usually are. I would also put a unique constraint on the key, so a bug can never create duplicates silently.”
Weak answers read the maximum value and add one in application code with no lock or constraint.
5. When an issue changes, we want to notify web addresses that customers have registered. How would you design this delivery so that a slow or broken customer server does not hurt anyone else?
- Write the event to a durable queue in the same step as the change.
- Deliver from workers with a short timeout.
- Retry with growing waits, then pause a receiver that keeps failing.
- State the guarantee: at least once, so receivers need an event id.
“I would never call the customer's server inside the request that changes the issue. I would record the event in a table in the same transaction, then a worker moves it to a queue. Delivery workers send each event with a short timeout. On failure they retry with a longer wait each time. If one receiver keeps failing, I pause its deliveries and tell the admin, so its backlog does not fill the shared queue. I would keep a queue per receiver or a fair scheduler for that reason. Events may arrive twice, so each carries an id and a time.”
Weak answers send the call during the user's request or promise delivery exactly once without explaining how.
6. Two teammates open the same issue, both edit the description, and both press save. How should the backend stop the second save from wiping out the first?
- Explain the lost update problem.
- Add a version to the issue and send it with each save.
- Reject a save whose version is old and return the latest content.
- Discuss field level saves or merging to make conflicts rare.
“This is a lost update. I would keep a version on each issue. The client receives the version when it loads the issue and sends it back on save. The update only succeeds where the stored version still matches, and it increases the version. If no row is updated, I return a conflict with the latest content, so the client can show both texts and let the user choose. To make conflicts rare, I would save each field on its own, so a change to the assignee never clashes with a change to the description. Locking the issue while someone types would block teammates.”
Weak answers let the last save win silently or lock the whole issue whenever someone opens it.
7. One customer starts importing a huge number of issues from a file, and other customers on the same service begin to see slow pages. What do you do right now, and what do you change afterwards?
- Confirm the import is the cause using metrics by customer.
- Slow down or pause the import without losing its progress.
- Tell the customer what is happening.
- Afterwards, move imports to a separate queue with limits per customer.
“First I would confirm the cause by looking at database load and request counts split by customer. If the import is the source, I would slow it down rather than kill it, so the customer does not have to start again. I would let support tell them the import is continuing at a lower speed. Once other customers are fine, I would look at the design. Imports should run on their own workers, in small batches, with a limit per customer and a pause when database load is high. I would also check whether the search index update was the real bottleneck.”
Weak answers cancel the import with no word to the customer, or only add more servers and leave the design as it is.
8. Why do you want to build the backend for tools where teams keep their issues, pages and code, instead of some other kind of product?
- Name the kind of backend problems you enjoy.
- Connect them to tracking and collaboration products.
- Mention the outside developers who build on the platform.
- Say what you want to get better at.
“I enjoy backend problems where many people change the same data and it still has to stay correct. Team tools are full of that: two people editing one issue, permissions that flow down a tree of pages, a search that must respect who can see what. I have used Jira and Confluence at work for years, so I know how much a slow page or a lost comment hurts a team's day. I also like that outside developers build apps on the same APIs, which forces the design to be clean. I want to get better at designing for that kind of shared use.”
Weak answers speak only about the company's name and show no interest in the data problems behind team tools.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.