Atlassian DevOps Engineer Interview Questions
Operations work at a company that offers Jira, Confluence and Bitbucket as cloud services means keeping the tools running that other teams need in order to do their own work. When they are down, customers cannot plan, write or ship code. Prepare to talk about staged rollouts, running customers' build scripts safely, protecting code repositories, alert noise, and honest status updates during an incident. What to show here: calm, honest operations for tools other teams depend on. 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 an incident where you had to keep customers informed through a public status page while the cause was still unknown. What did you write, and how often?
- Describe the incident and who was affected.
- Explain what you published first and why.
- Show how you kept a steady rhythm of updates.
- Share what you wrote after it was over.
“In my last role our login service failed for part of our customers. Within a few minutes I posted that we were aware of login failures and were investigating, without naming a cause we did not know. I agreed with the incident lead that I would post an update at a fixed interval, even if the update was only that we were still working. Each post said what was affected, what was not, and what customers could do meanwhile. After the fix, I published a short review with the cause and the changes we made. The result was your result.”
Weak answers stay silent until the fix, or publish a guessed cause that later turns out wrong.
2. Describe a time the on-call team was getting so many alerts that real problems were being missed. How did you cut the noise?
- Describe the volume and its effect on people.
- Explain how you sorted alerts by whether someone had to act.
- Show what you deleted, merged or changed.
- Share how you kept the noise from returning.
“On a previous team, the person on call got woken several times a night, mostly for alerts that cleared by themselves. I exported a month of alerts and marked each one by whether anyone had taken action. Most had not needed action. I removed those or turned them into daily reports. I merged alerts that always fired together, and changed the rest to measure what users feel, like error rate, instead of machine load. We then reviewed every page in a weekly meeting and asked if it was worth waking someone. The result was your result.”
Weak answers mute alerts without checking what they covered, or accept the noise as part of the job.
3. Customers run their own build and test scripts on a hosted pipeline service. How do you run code you do not trust without letting one customer reach another customer's code or secrets?
- Run each build in a fresh, isolated environment that is destroyed afterwards.
- Limit processor, memory, time and network reach.
- Inject only that build's secrets and mask them in logs.
- Assume a container escape is possible and add a second wall.
“I would give every build a fresh environment that is thrown away at the end, so nothing is left for the next customer. Containers alone share the host kernel, so I would place them inside small virtual machines or use a sandboxed runtime as a stronger wall. Each build gets limits on processor, memory and run time. The network blocks access to internal services and to the cloud metadata address. Secrets are handed to the build only when it starts, are scoped to that repository, and are masked in the logs. Build caches are kept per customer and never shared.”
Weak answers reuse build machines between customers or rely on containers alone as the security wall.
4. Teams plan their whole working day in your product. How would you roll out a risky change to the cloud service so that a bad release reaches as few teams as possible?
- Release to internal users first, then to a small group of customers.
- Define health signals and how long to wait at each stage.
- Stop and roll back automatically when signals cross a line.
- Order the stages by time zone and customer type.
“I would release in rings. The first ring is our own staff, who use the product for real work. The next is a small group of customers, then larger groups. At each ring the release waits for a set time while we compare error rate, latency and key actions, like creating an issue, against the previous version. If a signal crosses its line, the pipeline stops and rolls back without waiting for a person. I would time each ring to land outside the working hours of that region where possible. Database changes are made in a form that both versions can read.”
Weak answers release to everyone at once and rely on a fast rollback as the only safety.
5. You host Git repositories for many customers. How would you back them up, and how would you restore one customer's repository to yesterday's state without touching anyone else?
- Start from the restore cases you must support.
- Replicate repositories to other machines for hardware failure.
- Keep point-in-time copies per repository for mistakes and deletion.
- Test restores on a schedule and measure how long they take.
“I would begin with the restores we need. One is a lost disk, and for that I would keep live copies of each repository on several machines. The other is a customer who deleted a branch or force pushed by mistake. Replication copies the mistake too, so I also need snapshots over time. Git helps here because objects are never changed, so I can keep a log of reference updates and hold on to unreachable objects for some weeks. To restore one repository, I reset its references from that log. I would run restore drills regularly.”
Weak answers describe backups only and have never tried a restore, or can only restore a whole server.
6. Every weekday morning, customers' builds wait longer and longer in the queue before they start. How would you find the cause and fix it?
- Plot queue time against arrivals and running capacity.
- Find whether the delay is in adding machines or in total limits.
- Scale ahead of the known morning peak and keep a warm pool.
- Check that a few heavy customers are not taking the whole queue.
“A pattern that repeats every morning suggests we scale after the demand arrives. I would plot the arrival of builds, the number of runners, and the wait time on one chart. If new runners take several minutes to start, the queue grows during that gap. Since the peak is known, I would add capacity on a schedule shortly before it, and keep a pool of warm runners with common images already pulled. I would also check the mix of customers. If a few large ones fill the queue, fair scheduling per customer keeps small teams from waiting behind them.”
Weak answers only raise the maximum number of machines without looking at start time or fairness.
7. After a deployment, some customers say that search shows issues that were already closed, and new issues do not appear. Other customers are fine. Do you roll back or fix forward, and how do you decide?
- Measure how far the search index is behind, per customer.
- Check what the deployment changed and whether a rollback is safe.
- Roll back if it stops the damage, then repair the index.
- Tell affected customers and watch the index catch up.
“I would first look at how far the index is behind for each customer, to see who is affected and whether it is getting worse. Then I would check the release. If it changed the indexing workers, rolling back is likely the fastest way to stop the damage, and I lean that way unless the release included a data change that cannot be undone. A rollback will not fix the index by itself, so I would then replay the missed updates for the affected customers. Meanwhile, the status page should say that search results may be out of date.”
Weak answers debug in production while the lag grows, or roll back and assume the index is fine again.
8. Why do you want to run the infrastructure behind tools that other engineering teams use to plan work, host code and handle their own incidents?
- Explain what it means when a work tool is down.
- Link it to your own experience on call.
- Name the operations problems that interest you.
- Say how you want to grow.
“When a team's tracker or code host is down, they cannot do their own work, and some of them may be in the middle of their own incident. I find that responsibility motivating. I have been on call for services that others depended on, and I learned that clear updates matter almost as much as the fix. The problems here interest me: running builds for many customers safely, releasing in stages, and keeping repositories safe. I want to grow in designing systems where one failure stays small, and in writing reviews that teach something.”
Weak answers list tools they know and never mention the customers who depend on the service.
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.