Atlassian Values Interview: The 5 Values & How to Prep

Every Atlassian onsite loop carries a round that has nothing to do with algorithms or architecture. The Values Interview runs and is scored on its own, and it's weighted the same as any coding or system design round. It usually lasts around 45 minutes, it feels conversational, and it is the round candidates most reliably underestimate. A loop can be clean on the two coding rounds and the system design round and still end in no offer because the values read came back thin. People learn that the hard way.

The reason it hits so hard is that a real person outside your target team is reading you against Atlassian's five company values, and they are looking for evidence, not enthusiasm. Atlassian builds the tools a lot of software teams live in: Jira, Confluence, Trello, Bitbucket. It treats those five values as the durable spine of how it works, and the interviewer wants stories where your past behavior actually maps onto them. A warm chat where you agree that teamwork is good produces no signal, and no signal means a weak score.

The Atlassian angle

A strong technical loop does not rescue a weak Values read, because the two are scored separately and both feed the same committee. Atlassian does not let interviewers vote live. An independent Hiring Committee reviews the written feedback from every round holistically and decides both the hire and the level. The Values scorecard lands on that table with full weight, submitted by someone who has no stake in filling your team's seat. That impartiality keeps the values bar consistent company-wide and it means the round cannot be charmed or waved through. Among candidates who clear the technical bar and still get no offer, a thin values read is the reason cited most often.

One scope note before the values. For most candidates the Values Interview is the only behavioral round in the loop. Senior and Engineering Manager candidates report an additional round on top of it. It's a project deep-dive, sometimes framed as an experience or manager round, separate from the Values Interview and focused on the hardest work you have shipped. Reported prompts push on scale and technical depth over values, for example scaling a backend to serve traffic internationally or handling very large files. The interviewer keeps drilling into what you personally decided and why. If you are interviewing at that level, prepare one project you can narrate end to end and defend several follow-ups deep, alongside your values stories.

The five values, word for word

Atlassian's five values are Open company, no bullshit; Build with heart and balance; Don't #@!% the customer; Play, as a team; and Be the change you seek. There are exactly five, and they have barely moved since roughly 2007. The company draws a sharp line between values, which it says stay the same, and culture, which it says shifts as the company grows and varies office to office. That distinction matters for the round: the interviewer is testing durable values, so you want examples that show how you already operate, not a promise to fit in. Quote the wording precisely, including its deliberate quirks.

• Open company, no bullshit: Value 1. Information is open internally by default and sharing is a first principle. Speaking your mind is expected, but with thoughtfulness and care. Atlassian words this one bluntly on purpose, so the value is directness itself, not diplomacy.
• Build with heart and balance: Value 2. "Measure twice, cut once." Understand the goal before the first decision or line of code, weigh the trade-offs, then act decisively. Passion and considered judgment together, not one at the cost of the other.
• Don't #@!% the customer: Value 3. The bleeped profanity is deliberate and part of the official wording. Keep the customer in mind at all times and never screw them over, even indirectly. Softening it to "screw" is a tell that you did not check the source.
• Play, as a team: Value 4. Take the work seriously without taking yourself too seriously. People do their best work on a team they trust, one that has each other's backs and puts the team's interest ahead of individual glory.
• Be the change you seek: Value 5. Kaizen-style continuous improvement. Everyone can and should drive positive change, which takes courage and initiative. Take responsibility for making things better instead of waiting to be told.

The Atlassian angle

The wording carries small traps that mark whether you read the source or a summary of it. Value three is genuinely rendered "Don't #@!% the customer" on Atlassian's own materials, so quote it that way rather than softening it to "screw the customer," and value one is written just as bluntly. Do not pad the list to six or trim it to four; the count is five and has been for years. Team Anywhere, Atlassian's distributed-work model that keeps the loop 100% virtual, is a way of working, not a value, so do not cite it as one. "Ohana" belongs to Salesforce, not here. There is also no retired or dead value to dodge, which is unusual, so you can lean on the five as stable rather than hedging that one recently changed.

How the round runs and how it is scored

The tone is intentionally relaxed so you open up, but there is a rubric underneath. The interviewer works from a set of prepared scenario questions mapped to the values, listens for concrete behavior, and probes with follow-ups until they either hit real detail or hit a wall. The follow-ups are the test. They will rarely name the value they are testing. They ask about a situation and read the behavior you describe against the value it belongs to.

• Length: ~45 min. Some loops run 45 to 60 minutes. Conversational on the surface, structured underneath.
• Interviewer: Outside your team. A trained values interviewer, very often from a different function entirely: Sales, People, Support, Marketing, or a separate engineering org. Assume zero shared context with your work.
• Format: Scenario-based. Behavioral prompts tied to the values, then layered follow-ups asking for specifics. Rehearsed or canned-sounding answers get flagged and pushed on.
• Scoring: Full weight. A scorecard graded on evidence of the values, submitted to the independent Hiring Committee with the same weight as any technical round.

What each value actually probes for

Each value maps to a recognizable family of scenario questions. Knowing the mapping lets you hear the value behind the prompt in real time and reach for a story you have already tagged to it.

STAR, tuned to their criteria

Atlassian names STAR as the structure it wants: Situation, Task, Action, Result. Tune it to how this round scores. Keep the situation and task short, since the interviewer has no context on your work anyway. Spend most of the story on the action, told in the first person, because "we redesigned the pipeline" earns nothing until they know what you personally did. Land on a concrete result, ideally one you can put a number or a clear outcome on. Then stop. A tight two to three minute delivery that ends on a result beats a five minute tour that trails off.

Because the follow-ups keep coming, every story needs reserve detail below the headline. The interviewer will ask what the other person said, what you would do differently, how you knew it worked. Pick real examples with enough texture that the third and fourth question still find solid ground. Prepare at least two stories per value, roughly ten to twelve in total, each tagged to the value or values it demonstrates, and rehearse them against the prompts in Values Questions by Theme. Stories that cover two values at once are fine and common.

One worked answer, end to end

Take a real prompt for value three: "Describe a situation where you had to choose between what was best for the business and what was best for the customer." Here is a full STAR answer sized for the room, told first-person, from an engineer who does not assume the interviewer knows the product.

Situation. "My team owned the billing service for a B2B product, the part that decides what each account gets charged. A quarter-end deadline was coming and leadership wanted a new usage-based pricing tier live before it, because it unblocked a big sales push."

Task. "I was the engineer implementing the metering. Two days before the launch date, while validating against production traffic samples, I found that our usage counter double-counted a class of retried requests. Roughly 3% of customers would have been overbilled, some by a meaningful amount. Shipping on time meant shipping a bug that overcharged real customers."

Action. "I did not sit on it. I wrote up exactly what I had found: the affected request pattern and the estimated blast radius. Then I posted it in the open channel where my manager and the PM could both see it, instead of quietly trying to patch it under the wire. So I proposed a middle path instead of a binary slip-or-ship. Launch the tier on schedule, but gate the new metering behind a flag. Keep the old, correct billing path live for one more cycle, and give myself three extra days to fix the retry dedup and backfill a verification job. I paired with a teammate to review the dedup logic because I did not want a rushed fix to trade one billing bug for another. I also drafted the note the account team could send if any customer asked why usage-based pricing was arriving a cycle later than announced."

Result. "We hit the launch date for the sales push, and not one customer was overbilled. The dedup fix shipped four days later with a reconciliation job that has caught two smaller discrepancies since. My manager later used the flag-and-verify approach as the default pattern for billing changes on the team. The thing I am most glad about is that the problem was visible to everyone from the hour I found it, so the decision was made in the open instead of by me alone."

That answer does several things the round rewards at once. It refuses to screw the customer even under deadline pressure, which is value three squarely. It measures before cutting and finds a balanced path rather than a reckless ship or a stubborn slip, which is value two. It surfaces bad news early and in the open instead of hiding it, which is value one. It also survives follow-up. Ask "why not just delay the whole launch" and there is a real trade-off to discuss. Ask "what did your PM say" and there is a concrete exchange. Ask "what would you change" and the honest answer is that the dedup gap should have been caught in testing earlier.

Strong evidence versus thin evidence

The same story can score well or poorly depending entirely on how it is told. The contrast below is what separates a scorecard that reads "clear evidence of the values" from one that reads "pleasant, no evidence."

The Atlassian angle

These values are not an interview hoop, they run the company day to day, so the strongest answers sound like how you already work. Atlassian references the same five values in performance reviews, in leadership expectations, and in everyday product decisions across Jira, Confluence, and the Marketplace apps ecosystem. The distributed Team Anywhere model leans especially hard on two of them: written openness ("Open company, no bullshit") and high-trust asynchronous teamwork ("Play, as a team"). A lot of that work happens in docs and threads rather than in a room. An answer that shows you would live these values in that environment reads far stronger than one that name-checks them. Prepare accordingly: two real stories per value, tagged and stress-tested against follow-ups, told so a stranger from another function can follow every one.

Common questions