Atlassian Browser Coding Interview: Build and Test an Interactive UI

For an Atlassian Browser Coding interview, prepare to build a small interactive interface in a working browser, explain its behavior, and demonstrate tests. A useful rehearsal begins before the prompt: your project starts cleanly, the page renders, and you can change one interaction without spending the session repairing dependencies.

This article distinguishes official preparation instructions, candidate reports, and our original practice recommendations. Browser Coding and AI Code Design have different briefs. Permission described for the latter should not be carried into the former.

Use Atlassian Frontend Engineer questions to rehearse related implementation and design decisions. The project directory below is an original exercise, not a disclosed Atlassian assignment or a prediction of your question.

What does Atlassian officially say about Browser Coding?

Official: the fullstack preparation PDF linked from Atlassian's engineering interview page describes Browser Coding as implementing and executing a simple interactive UI. It asks candidates to prepare an IDE for a familiar framework and a browser page displaying the time at initial load. It describes coding sessions capped at 60 minutes, screen sharing, advance coordination for a CodePair alternative, and attention to communication, testing and TDD. Atlassian fullstack preparation PDF

The same PDF separately describes AI Code Design: a HackerRank environment, AI assistants, and work in an existing repository. Those statements establish two distinct preparation contracts. They do not establish that AI assistance is allowed in Browser Coding. Confirm the tools allowed by your invitation.

The PDF carries a 2024 copyright and remains linked from the current official page. It is a preparation source, not proof that every role follows an identical 2026 loop. Atlassian engineering interview handbook

Candidate-reported: a comment in a late-September/early-October 2026 discussion describes receiving a TypeScript file after preparing a JavaScript React project, with time lost to setup. The interview date is unspecified. This is one account, not evidence that TypeScript is mandatory or that setup failure determines the outcome. Candidate discussion

We did not locate two independent reports establishing the same recruiting-cycle format. The preparation recommendations below follow the official brief and explicitly invented behavior contracts.

Start with a reproducible browser environment

Our recommendation: run a small preflight from a fresh terminal rather than checking only an already-open development server. Install the locked dependencies, start the documented command, render the page, edit visible text, and run one test. Then restart to confirm that success does not depend on an old process or cached build.

Ask the coordinator about starter files, expected language, allowed packages, test runner, and whether the task requires API calls. A JavaScript app accepting a TypeScript file is a compatibility question; a preinstalled editor extension does not solve it. Check compilation support when the brief requires it, and keep a minimal fallback that you can explain.

If an alternative hosted environment is promised, confirm how you will receive it before the session. Save the run and test commands in a short README. Screen-share the browser, editor and relevant test output without exposing unrelated account pages or private projects.

Do not build a large reusable interview repository that takes longer to navigate than a fresh component. The starting project should remove installation friction while leaving the interviewer able to see what you implement.

Rehearse an interactive project directory

Our original prompt is deliberately smaller than a Jira application: show projects returned by a search service, allow a user to expand one project's details, and provide a retry when loading fails. The service returns stable project IDs and display names. Leave editing, authentication, drag-and-drop and persistence for later requirements. First demonstrate the search, disclosure and retry path.

Clarify whether search is local or remote before choosing state. For this rehearsal it is remote, and a later search can finish before an earlier one. Details are a disclosure inside a project row, not a navigation menu or autocomplete. That distinction keeps the keyboard contract manageable.

Define acceptance criteria through visible behavior. The first successful response renders matching projects. A successful empty response shows an empty-state message. A failed request shows an error and a usable retry. Opening details changes the disclosure state without losing focus. The current query remains visible while work is pending.

A component boundary is useful when it assigns a responsibility: the directory owns requests and selection; a search field owns input semantics; a row renders one project and its disclosure. Creating separate components for every label adds files without clarifying ownership.

Model state around mutually exclusive outcomes

A UI state model describes which information must be true together. Here, idle, loading, ready, empty and error are mutually exclusive request states. The query and expanded project ID are separate user choices. Visible rows derive from the accepted response rather than a second independently updated list.

Use stable IDs for row identity and expanded state. An array index changes when search results reorder, so storing index 2 can expand a different project after refresh. If the expanded ID disappears from a new result, close that disclosure deliberately and explain the policy.

Decide whether a new search clears old results or keeps them visible with a pending indicator. Both can be reasonable; this exercise clears them to avoid showing stale rows as current results. If retaining them, distinguish pending data from a completed empty response, and prevent a user from confusing old selection with the new query.

A useful review question is: can the page claim both “no results” and “request failed”? If so, separate those meanings. Empty is a successful answer with zero matches. Error means the request did not supply a trustworthy answer.

Protect the UI from a late response

Consider this trace: request A starts for “plat”; request B starts for “platform”; B completes first; A completes later. Rendering both completions would put A's older data under B's current input. The defect is visible even if each request is individually correct.

This original implementation sketch accepts a completion only when it belongs to the latest request:

let version = 0;
async function loadProjects(query) {
  const mine = ++version;
  render({ status: "loading", query, items: [] });
  try {
    const items = await getProjects(query);
    if (mine !== version) return;
    render({ status: items.length ? "ready" : "empty",
             query, items });
  } catch (error) {
    if (mine !== version) return;
    render({ status: "error", query, items: [] });
  }
}

getProjects and render are injected rehearsal functions, not framework APIs. A query reset or component teardown should invalidate the active version too. Otherwise an old request can repopulate a cleared screen or update an unmounted view.

Official technical reference: AbortController can cancel supported asynchronous operations, including fetch. Cancellation can save unnecessary work; the version check expresses which response may update this UI. The same ownership check applies to failures: cancelling an older request must not replace a newer success with an error. MDN AbortController

Give keyboard behavior an explicit contract

Use a labelled search input and native buttons. For each project, a button controls a details region and exposes whether it is expanded. A visible focus style is part of the usable result, not finishing decoration.

Official accessibility reference: the W3C disclosure pattern uses a button with aria-expanded; Enter and Space activate the disclosure. aria-controls may identify the controlled content. Follow the pattern's behavior as well as its attributes. W3C disclosure pattern

For the original directory, Tab moves through the search field, retry when present, and visible disclosure controls. Activating a row keeps focus on its button. Loading and error messages should be exposed appropriately without forcing focus away on every network response.

Do not add role="menu" because the UI contains a list. A true menu has a different interaction contract. Adding ARIA does not finish the accessibility work. Verify a keyboard path and explain any screen-reader behavior you have not tested.

When a refresh removes the currently focused row, choose a sensible focus destination, such as the search field or a stable results heading. Treat this as a user transition requiring a decision, rather than allowing focus to disappear accidentally.

Test the risky transitions before polishing the surface

Write tests that prove a user-visible contract. Testing Library's official guidance emphasizes DOM behavior resembling actual use, rather than inspecting component instances. Testing Library guiding principles

For this rehearsal, a small test matrix is more useful than many snapshots:

Transition	Evidence to demonstrate
A starts, B starts, B resolves, A resolves	Only B's results remain visible.
Latest request fails, then retry succeeds	Error is replaced by the returned projects.
Latest response contains no rows	Empty state appears without an error claim.
Keyboard activates a details button	Expanded state and visible region change together.
Query resets while loading	Old completion cannot repopulate the cleared view.

Use controllable promises for request-order tests: the test chooses when each request resolves or rejects. Arbitrary sleep durations can hide a race on a faster machine. Assert the final project names and status after resolving each promise, and separately test a rejected stale request after a newer success.

A manual keyboard check complements automated request logic. It can reveal missing focus styling, an unreachable retry, or a disclosure that works only by pointer. Pure-function tests do not prove browser focus, layout or assistive-technology output.

If the interview setup cannot run your preferred testing tool, keep the same acceptance criteria and demonstrate the behavior through the available browser and test harness. State what was verified, what remains untested, and the next meaningful test.

Adapt when the interviewer changes the prompt

A change from one expanded project to several exposes a state choice: replace a single ID with a set of IDs and preserve stable identity. A request to sort results should derive order from accepted data, not launch unrelated network work unless the service owns sorting.

If details become asynchronous, identify whether each row needs an independent request version. A single global version for all detail requests would let opening one project invalidate another unnecessarily. Separate list-search ownership from row-detail ownership before adding a cache.

When time runs short, demonstrate the runnable path and one high-risk transition. Explain the remaining failure state precisely: “Retry works, but a disappearing focused row still needs a focus fallback” gives the interviewer something inspectable. Avoid an unsupported claim that an unfinished feature is trivial.

For a rehearsal using the PDF's 60-minute cap, reserve time for clarification, a working path, failure behavior, and test demonstration. Choose the allocation based on your current weak point. This is our planning advice, not Atlassian's internal scoring schedule.

Sources and Further Reading

• Atlassian official engineering interview handbook
• Atlassian linked fullstack preparation PDF
• Candidate discussion containing a reported Browser Coding setup issue
• MDN: AbortController
• W3C ARIA Authoring Practices: Disclosure
• Testing Library: Guiding Principles

Research checked October 4, 2026. Role, language, permitted tools and interview setup may vary. The directory, code sketch and test matrix are original practice material; they do not reproduce an employer assignment.