Atlassian India-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Collaboration products look simple at the surface and become state machines underneath: documents have revisions, work items have workflows, and every action is constrained by a project or workspace permission. Rounds in the style of Atlassian India use that product shape to test whether a candidate can make a small service coherent and extensible.
The useful preparation target is a working core with explicit ownership, transitions, and event history. This page describes the style without claiming any company question, then points to Gronex repositories that exercise the same mechanics.
What a Atlassian India-style machine coding round looks like
Expect a scoped 90–120 minute build such as a ticket tracker, document version store, or notification rule engine. The statement usually gives entities, a few legal transitions, and one permission rule, then asks for a runnable API or service layer.
The difficult part is the boundary between a command and its history. A ticket update should leave an audit event; a document edit should create a revision; a role change should affect future actions without rewriting the past. Modelling those boundaries explicitly makes the follow-up requirements manageable.
A live extension commonly adds a workflow state, a new role, or a subscription filter. Reviewers look for deterministic behaviour, readable domain objects, and tests around forbidden actions rather than a large framework scaffold.
How you’re evaluated
Explicit state transitions
Legal workflow moves are centralised and invalid moves return clear errors.
Permission boundaries
Access is checked from role and resource context, with no accidental privilege from a caller-supplied flag.
History that survives change
Revisions and audit events are append-oriented, queryable, and separate from current state.
Extension seams
A new workflow or notification rule fits through data and focused policies instead of scattered conditionals.
Common mistakes that fail this round
- Treating a workflow status as a free string with validation duplicated across handlers.
- Allowing a user to edit a resource by checking only user identity and ignoring project membership.
- Overwriting document history so the current row cannot explain how it got there.
- Building HTTP and persistence before demonstrating the core domain behaviour.
- Using unordered collections where listing and notification order must be deterministic.
Quick tips for the room
- Write the permission matrix before the first handler.
- Keep current state and audit history as separate concepts.
- Make list results stable with an explicit sort.
- Demo the happy path before discussing scale.
How to prepare
Build a small ticket or document service under a timer. Start with the transition table, permission matrix, and one end-to-end demo; then add history and an extension without breaking the first flow.
Practise the Gronex repositories below as code-reading exercises: understand the existing model, fix the failing service behaviour, and explain the invariant that each test protects.
Practice problems in the Atlassian India-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.
Issue Tracker Workflow & Permissions
Workflow transitions, project roles, and audit history in a collaboration backend.
Open the challenge →Document Versioning & Collaborative Editing
Revisions, conflict checks, and deterministic history for shared documents.
Open the challenge →Notification Preference & Delivery
Preference-aware, idempotent notifications for workspace events. Free to try.
Open the challenge →Role-Based Access Control
Roles, resource scope, and safe permission changes.
Open the challenge →Audit Log & Compliance Events
Append-only, queryable events for sensitive workspace actions.
Open the challenge →FAQ
Were these Atlassian India questions?
No. These are Gronex originals written in the style of collaboration-product rounds. Gronex is not affiliated with Atlassian and does not republish company interview questions.
Should I build a full web application?
Usually no. A runnable domain service and focused tests show the important behaviour faster than a large UI or deployment setup.
How should I handle permissions?
Write a small role-and-scope matrix, centralise the decision, and test both allowed and forbidden actions.
What makes the design extensible?
Keep transitions, policies, and notification rules behind small seams so a new rule does not require rewriting every command.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Atlassian India. 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 India.