Atlassian SWE: Coding Interview - Code Design / Craft Guide

Estimated read time: 7-9 minutes

Summary: The Atlassian SWE code design or craft interview looks beyond whether you can make code pass. It asks whether you can structure a small system so another engineer could maintain it, extend it, and reason about it. This guide covers the format, realistic question shapes, level expectations, and failure modes.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• Atlassian's official engineering guidance separates code design or craft from data structures coding.
• The round can apply across levels, but senior and staff candidates should expect a higher maintainability bar.
• Expect practical implementation with changing requirements, object boundaries, API choices, and tests.
• The interviewer cares about code that can evolve, not only code that works once.
• Frontend, backend, fullstack, and SRE roles can shape the exact exercise.

Quick FAQ

Is this system design?
No. It is usually smaller and closer to code. You may design classes, modules, APIs, or components rather than a distributed architecture.

Is this just object-oriented design?
Not always. The core signal is maintainable structure. That can appear in object-oriented code, functional decomposition, frontend components, or service boundaries.

Should I optimize immediately?
Only when the requirement demands it. Clean structure and correctness usually come first.

---

1) How the round runs

The interviewer may ask you to build a small feature, refactor a messy implementation, model a domain, or extend an existing design. The first version is often simple. The follow-up exposes whether your structure can handle new requirements without becoming tangled.

For Atlassian, practical product domains are useful to rehearse: issues, workflows, permissions, notifications, comments, boards, documents, deployments, and integrations. You do not need internal product knowledge. You do need a design that is easy to discuss and change.

---

2) Candidate-facing question examples

• Design and implement a simple issue tracker. Start with create, assign, transition status, and list by owner. Then add custom workflows per project.
• Build a voting or ranking service for feature requests. Then support duplicate votes, vote changes, and tie-breaking rules.
• Implement a notification router. Start with email notifications, then add Slack, batching, user preferences, and retry behavior.
• Refactor a small service where validation, persistence, and formatting are mixed together. Add a new validation rule after the refactor.
• Design a comment thread model. Support nested replies, edits, deletes, permissions, and pagination.
• Build a simplified board for tasks. Support moving cards between columns, ordering cards, and rejecting invalid transitions.
• Implement a plugin registry. Add install, uninstall, version compatibility, and permission checks.

---

3) Evaluation signals

Strong candidates separate responsibilities cleanly. They name the core entities, define the operations, keep state transitions understandable, and leave room for follow-ups. They also explain what they intentionally are not building yet.

For senior candidates, the bar rises. The interviewer may expect better API boundaries, testability, migration thinking, and a sharper sense of which abstraction is worth adding. Staff-level candidates should connect the small design to broader maintainability and team ownership.

---

4) Common failure modes

Writing one large function. It may pass the first case and collapse under the second requirement.

Adding abstractions too early. The best design is not the most abstract one. It is the one that fits the known change pressure.

Ignoring invalid states. Permission checks, status transitions, and duplicate operations matter in product-like exercises.

Failing to explain tradeoffs. Code craft rounds are collaborative. The interviewer needs to understand why you shaped the code this way.

---

5) How to prepare

• Build small domain models for tickets, boards, notifications, comments, and permissions.
• Practice extending an implementation after 20 minutes instead of starting over.
• Explain where you would add tests and which behavior each test protects.
• Practice naming classes, functions, and state transitions clearly.
• For frontend-heavy roles, rehearse component state, data loading, and user interaction boundaries.