Atlassian Software Engineer Interview Questions
A software engineer at a company that makes Jira, Confluence, Trello and Bitbucket builds features for users who are often engineers themselves, and who shape the tools to fit their own way of working. Prepare to reason about filters that users write as text, automation rules that trigger each other, notifications that must not flood people, and changes to features that teams have built habits around. What to show here: features that fit many different teams without breaking their habits. 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 your users were technical people, such as developers or system admins, and their feedback on your work was blunt. How did you use it?
- Describe what you built and who used it.
- Share the feedback as it was given.
- Explain how you found the real problem behind it.
- Show what you changed and how you closed the loop.
“I once built a command line tool for the developers in my company. After the first release, one of them wrote in the team channel that it was slower than doing the task by hand. It stung, but I asked him to show me his screen. He ran it many times in a row, and each start took a few seconds because I loaded all the settings first. I changed it to load only what each command needed and added a batch mode. Then I replied in the same channel with what I had changed. The result was your result.”
Weak answers dismiss blunt feedback as rude, or change everything without understanding the cause.
2. Describe a time you had to change or remove a feature that some teams had built their daily routine around. How did you handle it?
- Explain why the feature had to change.
- Show how you found who relied on it and how.
- Describe the path you gave them and the notice period.
- Share the result and what you learned.
“In a past product we had an old export that produced a file in a format only that feature used. It blocked a database change, so we decided to remove it. Usage logs showed few users, but some ran it every week for a report. I spoke to a few of them and learned they only needed three columns from it. We added those columns to the standard export, showed a notice inside the old feature for some weeks, and wrote a short guide. A few users still complained, and I answered each one. The result was your result.”
Weak answers remove the feature because usage was low and never ask the remaining users what they did with it.
3. Users can filter issues by typing a query, for example status is open and assignee is me, ordered by priority. How would you turn that text into a safe database query?
- Split the text into tokens and parse it into a tree of conditions.
- Check each field and operator against a list of what is allowed.
- Build the database query from the tree with parameters, adding the permission filter.
- Return clear errors that point at the wrong part.
“I would not build SQL by joining strings. First a tokenizer splits the text into fields, operators and values. A parser then builds a tree, where and and or are inner nodes and comparisons are leaves. I check every field name against the fields that exist for this user, and each operator against the field type. From the tree I produce a query with parameters, and I always add the condition that limits results to projects the user can see. Words like me are replaced with the user's id. If the text is wrong, the error names the position and suggests valid fields.”
Weak answers paste the user's text into a SQL string or forget the permission filter.
4. An issue has many watchers, and a busy hour brings twenty small changes to it. How would you design notifications so that watchers stay informed but do not get twenty emails?
- Record each change as an event with its issue and author.
- Hold events for a short window per user and issue, then send one summary.
- Let direct mentions and assignments skip the wait.
- Respect each user's settings and never notify the person who made the change.
“I would store each change as an event. A scheduler groups events by user and issue, and waits a short time after the first event before it sends one message that lists all changes in order. Some events are urgent, like being mentioned or assigned, so those go out at once. The author of a change is never notified about it. Each user can choose instant, grouped or daily messages. I would also remove events that cancel each other, such as a status that changed and then changed back. The grouping must survive a restart, so the pending events live in a table.”
Weak answers send one email per change, or batch everything including urgent mentions.
5. Admins can create automation rules, such as when all subtasks are done, close the parent. One rule can trigger another. How do you stop rules from running in an endless loop?
- Explain how a loop forms between two rules.
- Carry a chain id and a depth counter with each triggered event.
- Stop at a depth limit and record why.
- Warn the admin at the time of saving when a loop is likely.
“A loop forms when one rule changes a field that triggers a second rule, which changes something that triggers the first again. I would attach a chain id and a depth to every event a rule creates. Each time a rule fires because of another rule, the depth goes up. At a fixed limit, the engine stops the chain and writes an entry in the rule's log that shows the full chain, so the admin can see what happened. I would also limit how many runs one rule gets per hour. At save time, I can warn when a rule's action matches another rule's trigger.”
Weak answers trust admins never to create loops, or stop the chain silently with no log for the admin.
6. A pull request was approved yesterday, and since then the target branch has received new commits. How would you decide whether it is still safe to merge?
- Check for text conflicts by doing a trial merge.
- Treat build results as valid only for the commit they ran on.
- Decide whether approvals survive new changes, as a setting.
- Explain the option of testing the merged result before it lands.
“There are three separate questions. First, does it merge cleanly? I would run a trial merge in the background whenever either branch changes and store the answer. Second, do the tests still pass? A green build on the old commit says nothing about the merged code, so I would run the build on the merge result. Third, is the approval still valid? If the author pushed new commits after the approval, a team may want it reset, so that is a setting per repository. For busy branches, I would queue merges and test each one on top of the ones ahead of it.”
Weak answers check only for text conflicts and trust a build that ran before the target branch changed.
7. You are turning on a new issue view for customers in stages behind a feature flag. After the second stage, errors rise, but only for customers with certain custom fields. What do you do?
- Stop the rollout and turn the flag off for the affected group.
- Find what the failing customers have in common.
- Reproduce with the same configuration and fix it.
- Add that configuration to tests before going on.
“I would pause the rollout first. If I can target the flag, I turn the new view off only for customers with those custom fields, so others keep the new view and we keep learning. Then I would group the errors by field type to find the pattern. Let us say a field with an empty default breaks the renderer. I would copy that configuration into a test site, reproduce it, fix it, and add that case to our automated tests. Before I continue, I would ask what other unusual configurations we have not tested, and add a few from real usage data.”
Weak answers keep rolling out while they debug, or turn everything off for everyone without checking who is affected.
8. Many of Atlassian's users are software teams. Why does building tools for people who do the same job as you appeal to you?
- Say why the problem area matters to you.
- Give an example of a tool that changed how your team worked.
- Admit the risk of assuming all teams work like yours.
- Say what you want to build.
“I spend a large part of my day in an issue tracker and a code review tool, so I feel their good and bad sides directly. On my current team, a small change to how we reviewed pull requests cut a lot of waiting, and that showed me how much tools shape habits. Building for software teams means I can test ideas on myself first. But I also know my team is not every team, and many users are in support, marketing or operations. I want to work on features that stay simple for them and still flexible for engineers.”
Weak answers assume that every user works the way they do, or give reasons unrelated to the products.
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.