Atlassian-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Atlassian is well known for a machine coding / take-home-style round that values clean, extensible code over raw speed. You’re handed a product-shaped problem — a ticketing workflow, a permission model, a feature rollout — and asked to build a runnable service that a reviewer can read, extend, and reason about.
The scenarios come straight from the SaaS-product world Atlassian builds in: state-driven workflows, multi-tenant isolation, roles and scopes, versioned content, and configurable rules. This page breaks down the commonly reported shape of Atlassian-style rounds, how they’re graded on design quality, and Gronex problems in the same style you can rehearse in a real repository.
What a Atlassian-style machine coding round looks like
The typical shape is 90–120 minutes (or a short take-home), solo. You get a product-slice problem — a support-ticket SLA engine, an article publishing workflow, a scoped API-key system — with requirements and a couple of extension hooks hinted at. You produce a working, cleanly factored service, usually with your own tests.
Atlassian-style rounds weight readability and extensibility more heavily than most. The demo must run, but the conversation lingers on how you modelled the workflow, where the seams are, and how a reviewer would add the next rule. Tests you write yourself are a strong signal here.
The follow-up adds a rule — a new ticket state and SLA tier, a new role with narrower scope, a versioning or approval step. Rounds in this style are explicitly checking that your design absorbs change without a rewrite.
How you’re evaluated
A running, tested demo
Requirements implemented, the flow executable, and ideally your own tests showing you thought about correctness — a strong Atlassian signal.
Design quality
Clear entities, state transitions that block illegal moves, and seams where the next rule obviously slots in — readability is graded, not incidental.
Multi-tenant & permission correctness
Isolation between tenants, roles and scopes enforced consistently, and no cross-tenant leak under the reviewer’s probing.
Extensibility under change
A new state, role, or rule added in the follow-up lands in one place rather than rippling through the codebase.
Common mistakes that fail this round
- Optimising for speed and shipping tangled code — this round rewards the readable, extensible solution.
- Skipping your own tests when the round explicitly values them as a design signal.
- Modelling workflows as ad-hoc booleans instead of explicit states with guarded transitions.
- Leaking across tenants or mis-enforcing scopes because permission checks are scattered rather than centralised.
- Hard-coding the first rule so the inevitable "add one more state / role / tier" extension forces a rewrite.
Quick tips for the room
- Get a runnable skeleton up early, then invest the remaining time in clean seams.
- Model every workflow as an explicit state machine with illegal transitions blocked.
- Centralise permission and tenant checks so scopes are enforced in one place.
- Write a few tests as you build — they double as your correctness argument.
How to prepare
Practise building small SaaS-product services under a timer, and write a couple of tests as you go — Atlassian-style rounds treat those tests as evidence you reason about correctness, not an afterthought.
The Gronex problems below mirror the format from the other side — real backend repositories with failing tests over workflows, permissions, and rollouts, so you rehearse reading and extending product code cleanly. Start with the free ones, then take the multi-tenant and workflow problems.
Practice problems in the Atlassian-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Customer Support Ticket SLA System
A ticket workflow with SLA clocks: state transitions, escalation, and deadlines that stay correct as tickets move.
Open the challenge →Multi-Tenant API Key & Scope Management
Per-tenant API keys with scoped permissions and hard isolation — no cross-tenant leak under load.
Open the challenge →CMS Article Publishing & Versioning Workflow
Draft, review, publish, and version content with a workflow that blocks illegal transitions.
Open the challenge →Expense Report Approval & Reimbursement
A multi-step approval workflow with roles, limits, and an audit trail that stays consistent.
Open the challenge →Notification Preference & Delivery
Preference-aware, idempotent delivery across channels without duplicate sends. Free to try.
Open the challenge →Job Queue: Delayed & Priority Extension
Extend a job queue with delayed and priority scheduling behind a clean, testable interface. Free to try.
Open the challenge →FAQ
Is the Atlassian round really about clean code, not speed?
Atlassian-style rounds are known for weighting readability, extensibility, and your own tests heavily — a runnable demo is necessary but the design conversation decides the result. These are Gronex originals in that style; Gronex is not affiliated with Atlassian.
Were these problems actually asked at Atlassian?
No. Every problem here is a Gronex original built in the same style — SaaS-product workflows, permissions, and rollouts with working-code grading. Gronex is not affiliated with Atlassian.
Should I write my own tests during the round?
For an Atlassian-style round, yes — a few well-chosen tests are treated as evidence you reason about correctness. The Gronex problems ship with failing suites so you practise exactly that habit.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Atlassian. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Atlassian.