Frontend interview guide
Atlassian
Jira, Confluence, Trello, Bitbucket. A frontend culture built around collaborative, multi-user products.
Frontend engineers interviewing for the Atlassian stack — React/TypeScript across the Atlassian Design System.
Last reviewed 2026-10-04
What they emphasise
- Real-world product building — architecture that scales across a 50-engineer team, not just a single feature.
- Multi-user, collaborative UX — concurrency, presence, autosave, and the honest conflict stories.
- Design-system fluency — building against (and extending) a mature shared library (ADS).
- Behavioural depth — the five Atlassian Values are a real part of the loop, not a slide at onboarding.
The loop, round by round
6 rounds. Durations and formats are typical, not guaranteed — confirm the loop shape with your recruiter in the screen.
Round 1
Recruiter screen
~30 minCallWhat it covers
- Walk through your resume and recent work.
- Confirm location, visa, and compensation expectations.
- Overview of the loop and the level you're being considered for.
What they're looking for
- Clear communication under light time pressure.
- A specific, honest answer to "why Atlassian" that isn't the About page in different words.
Round 2
Technical phone screen
60 minLive coding on CoderPad (or similar)What it covers
- A medium-difficulty FE problem — building a small, correct UI from scratch, or a JS idiom round (debounce/throttle, promise control-flow, deep-equal).
- Reasoning out loud, not just typing.
- A short extension — "now make it handle N items" or "now add keyboard support".
What they're looking for
- Working code within the hour, not pseudo-code.
- The ability to name an edge case before the interviewer does.
- Clean iteration — nobody expects it right the first time; they expect it to improve under feedback.
Round 3
Onsite: machine coding
90–120 minPaired build on your IDE or CoderPadWhat it covers
- Build a real UI component — commonly in Atlassian's world: a Kanban board, an inline comment thread, a tag/mention picker, a filter panel.
- React/TypeScript. The ADS components aren't required for the exercise, but awareness that they exist is a signal.
- Add polish incrementally — accessibility, keyboard nav, loading/empty states — once the core works.
What they're looking for
- Clean component boundaries and prop APIs — not everything in one file.
- Awareness of accessibility (semantic HTML, keyboard, focus) built in, not bolted on at the end.
- An explicit stance on what you're not solving in the time available.
Round 4
Onsite: system design
60 minWhiteboard discussion (virtual whiteboard — Miro, FigJam, or a shared doc)What it covers
- Frontend-shaped prompt — "design a Kanban board that handles 2 000 cards per column with real-time updates", "design the comment thread for Confluence", "design a filter sidebar that is shareable by URL".
- Rendering strategy, data model, concurrency, real-time updates, and scope-out decisions.
What they're looking for
- Clarifying questions before proposing anything.
- Trade-offs named explicitly — "this works at 500 users, breaks at 50 000, here's why, here's the alternative".
- Explicit scope-out — "I'm not solving offline here, which would need …".
Round 5
Onsite: values / behavioural
45–60 minConversationWhat it covers
- Deep dive on three or four of the Atlassian Values (Open company, no bullshit; Build with heart and balance; Don't #@!% the customer; Play as a team; Be the change you seek).
- Real stories with concrete decisions, pushback, trade-offs, outcomes.
What they're looking for
- Specifics, not generalisations. "We prioritised X over Y because Z" beats "we always ship with quality."
- Visible self-awareness — a story about a time you were wrong, with what changed.
Round 6
Hiring manager / team-fit
45 minConversationWhat it covers
- Role expectations, team shape, what you'd be working on.
- Your own questions — ask them.
What they're looking for
- Thoughtful, specific questions about the team's actual problems.
- A real sense of what you want to work on — "anything" is a bad answer at any level.
What each level expects
The bar you're being measured against — plus the failure modes candidates most often trip on at that level.
SDE 2 / mid
~2–4 yearsOwns a well-scoped feature end to end on an existing codebase.
What they expect
- Writes production React/TypeScript cleanly, catches obvious bugs, reviews peer PRs usefully.
- Can decompose a feature brief into small PRs without being asked.
- Comfortable debugging — reads a stack trace, inspects network, uses the profiler on at least one occasion.
Common failure modes
- Jumps into coding before clarifying requirements in the system-design round.
- Over-engineers the machine-coding build — context, custom hooks, memoisation everywhere — when a 60-line component would have been correct and finished on time.
Senior
~5–8 yearsOwns a technical area; mentors mid-level engineers; proposes architecture that lives beyond one feature.
What they expect
- Can own a system-design round confidently — rendering strategy, state at scale, concurrency, honest trade-offs.
- Behavioural stories at the level of 'I led the migration of X across Y teams', with specific numbers.
- Visible influence — PRs reviewed deeply, docs that juniors cite, patterns that outlived the original author.
Common failure modes
- Senior candidates often fail the system-design round not on knowledge but on scope control — proposing a 50-component rewrite for a problem that needed one hook change.
- Behavioural answers at mid-level granularity — 'I worked on a thing' rather than 'I led, decided, measured'.
Staff
~8+ yearsTechnical direction for multiple teams; sets patterns, kills tech debt, influences strategy.
What they expect
- A system-design round that is really a conversation between two senior engineers — not a candidate presenting to a judge.
- Behavioural answers rooted in cross-team influence — 'this team needed to adopt X; here is how I earned that'.
- A clear design philosophy with evidence — not opinions, patterns you have shipped.
Common failure modes
- Showing up as a Senior+. The staff bar is specifically about leverage — your work making other engineers more productive — not about doing more of what Senior did.
- No concrete 'how I was wrong' story. At Staff, the lack of one reads as insufficient scar tissue.
How to crack it
Day-of advice. The specific moves that separate offers from no-offers when the content is already in your head.
- 1Study the ADS. You don't need to memorise it, but you should know what components it has, what tokens it uses, and the pattern of how they're composed. Interviewers will favourably notice.
- 2Prep two or three machine-coding builds in the Atlassian problem shape — Kanban, nested comments, tag picker, mention autocomplete — until you can ship them in 60 minutes with keyboard support and empty states.
- 3In the system design round, start every answer with clarifying questions. Three good questions is better than straight into a diagram.
- 4For the values round, pre-write five stories: a conflict handled well, a time you were wrong, a decision you pushed through, a team you unblocked, a customer-impact call. Rehearse them to under 2 minutes each.
- 5Ask one concrete question per interviewer about their current work. 'What's the hardest thing about the frontend here right now?' separates the thoughtful from the rote.
How to master it (over months, not days)
The longer-horizon work. These are the habits that pay off at Senior+ bars where cramming visibly fails.
- Build (or contribute to) one real multi-user product on your own — a shared whiteboard, a chat tool, a Kanban board. The muscle you need for Atlassian onsite is built in weeks, not days.
- Read Atlassian's engineering blog monthly. Not for leaks — for how they talk about problems.
- Learn one accessibility primitive deeply (focus management, ARIA tabs, live regions). Depth in one is more valuable than surface-level everywhere.
- Practise system-design out loud with a timer. The round is 60 minutes, and the common failure is not time management, it's not having rehearsed the structure.
- Keep a weekly 'what I learned' doc. The values round rewards specifics; those come from a habit, not from the week before the interview.
Resources
On-site content for the technical prep, plus short-list of external links worth your time.
- lessonDesign a Kanban BoardJira/Trello-shaped prompt walked end to end.
- lessonDesign a Collaborative WikiConfluence-shaped prompt with CRDT, autosave, presence.
- pathFE Interview Essentials path24-item sprint covering the practice loop.
- problemMachine coding: nested commentsA recurring Atlassian/Confluence-shape component.
- problemMachine coding: tag inputThe chip/mention primitive Jira and Confluence both lean on.
- externalAtlassian engineering blogHow the team actually talks about their problems.
- externalAtlassian Design SystemThe library every candidate should at least recognise.