Senior Site Reliability Engineer Interview Experience at Atlassian – 2026

An initial recruiter screen covering background, current role, and specific interest in Atlassian as a company. The recruiter also confirms understanding of what the Senior SRE role actually entails at Atlassian specifically, since the title is used differently across companies, checking candidates are not expecting a purely operational role given Atlassian's stated expectation that SREs code to a genuine engineering standard.

The real, specifically reported Atlassian SRE coding prompt: modeling a Jira-style platform with two subscriber tiers, free and premium. Candidates are asked to write Python code that, given a list of premium users each with a signup date partway through a billing month, calculates both the full monthly amount owed and the correctly prorated amount for the partial first month, then generates a report of amounts owed per subscriber. A clean approach structures the solution around a simple data class for each user and a function computing prorated days as a fraction of the billing period. Interviewers typically raise an edge case on the spot: what happens if a user upgrades from free to premium mid-month, which requires tracking the exact upgrade timestamp rather than just the days remaining.

Candidates are given two to three existing architecture diagrams representing a simplified version of a real Atlassian-style service, and asked to propose a redesign that explicitly incorporates SRE practices rather than just optimizing for feature delivery speed. A strong redesign introduces explicit SLOs for the service's critical read and write paths, adds a circuit breaker between the service and a flaky downstream dependency shown in the original diagram, and proposes splitting a single monolithic datastore into a primary transactional store plus a read replica specifically to isolate reporting queries from the transactional write path. Interviewers push candidates to justify chosen SLO targets with a rough error budget calculation rather than picking round numbers arbitrarily.

A deep technical discussion centered on a hypothetical but specific production incident: a service's error rate silently climbing over several hours without triggering any existing alert, discovered only when a customer complained. Candidates are asked how they would instrument the service differently to catch this class of failure earlier - the expected answer focuses on adding a burn-rate-based alert on the SLO's error budget rather than relying only on a static error-rate threshold, since a slow, sustained climb is exactly the pattern that static thresholds miss until it is already severe. The discussion typically also covers what observability data (traces versus logs versus metrics) would be most useful for root-causing the issue after the fact.

The managerial/director round, covering structured behavioral questions rather than technical ones. The specifically confirmed real question from this loop is being asked to describe a time the candidate went above and beyond in a role - a strong answer uses a STAR-format story about volunteering to lead work outside the formal job scope. Interviewers typically follow up by asking what the candidate would have done differently in hindsight, testing for genuine reflection rather than a rehearsed success story with no acknowledged rough edges.