Atlassian Frontend Developer Interview Questions
Frontend work on team tools such as Jira, Confluence and Trello means building screens people keep open all day: boards full of cards, issue views with many fields, and a page editor. Prepare to discuss smooth dragging on long boards, safe handling of pasted content, updates that arrive while a user is reading, keyboard access, and apps from other vendors shown inside your page. What to show here: fast, accessible screens that teams live in all day. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Atlassian hires, in its own words, and its questions for every job →
1. Tell me about a time you took a screen crowded with fields and options and made it simpler, without taking away what experienced users needed.
- Describe the screen and who used it.
- Explain how you learned which fields mattered.
- Show what you hid, grouped or kept.
- Share the result and the complaints you handled.
“In my previous role we had a ticket form with more than thirty fields, all visible at once. New users were lost, but senior users liked having everything in reach. I looked at which fields were filled in most often and sat with three users from each group. We kept the common fields on top, moved the rest into sections that stay open once a user opens them, and added a keyboard shortcut to jump to any field by name. Power users got faster, and new users stopped skipping the form. The result was your result.”
Weak answers hide features because they look messy and never check what experienced users rely on.
2. Describe a time you found that a drag and drop feature, or a similar mouse-only feature, could not be used with a keyboard or a screen reader. What did you do about it?
- Describe the feature and how you found the gap.
- Explain the keyboard and screen reader behaviour you designed.
- Show how you tested it.
- Share how you kept it from breaking again.
“On a past project I built a list where items could be dragged to reorder. During testing I tried it with only the keyboard and could not move anything. I added a way to pick up an item with the space key, move it with the arrow keys and drop it with space again. I also added a live message that tells a screen reader the new position. I tested it with a screen reader myself and asked a colleague who uses one daily. Then I added an automated test for the keyboard path. The result was your result.”
Weak answers call accessibility a later task, or add labels without ever testing with a keyboard.
3. A board has columns with a very large number of cards. How do you keep scrolling and dragging smooth?
- Measure first to find whether rendering or scripting is slow.
- Render only the cards near the visible area.
- Keep each card cheap and avoid re-rendering the whole board on one change.
- Handle dragging past the edge of the rendered area.
“I would start by recording a performance profile to see where the time goes. Usually the problem is too many elements in the page. So I would draw only the cards in view plus a few above and below, and use empty space to keep the scroll height right. Each card should be memoised, so moving one card does not redraw the others. While dragging, I would move the card with a transform, which avoids layout work. The tricky part is dragging towards cards not drawn yet, so the column must scroll by itself and render new cards as the pointer nears the edge.”
Weak answers suggest paging the board or a faster framework without measuring what is slow.
4. Users paste content into the page editor from word processors, spreadsheets and other web pages. How do you handle the pasted content so that it looks right and stays safe?
- Read the pasted data from the clipboard event, not from the page.
- Convert it into the editor's own set of allowed nodes.
- Drop scripts, event handlers and unknown styles.
- Keep useful structure like tables, lists and links, and test with real sources.
“I would never insert pasted markup directly. I would read it from the paste event and parse it into a separate document that is not attached to the page. Then I walk through it and convert each part into the editor's own model, which only allows known nodes like headings, lists, tables and links. Anything else, such as scripts, inline handlers or odd styles, is dropped. Links are checked so that only safe schemes remain. I would keep a set of sample pastes from common tools as test cases, because each tool produces different markup. The server must apply the same rules again on save.”
Weak answers set the pasted markup as inner content and trust the browser, or rely on the client check alone.
5. A user drags a card to a new column and the board shows it there at once. Then the server rejects the move because of a workflow rule. How should the interface behave?
- Apply the change locally and remember the previous state.
- Send the request and mark the card as saving.
- On rejection, move the card back and explain why in plain words.
- Prevent the bad move next time by loading the rules up front.
“I like showing the move at once because boards should feel quick. Before I apply it, I store where the card was. While the request is running, the card shows a small saving state. If the server rejects it, I animate the card back to its old column and show a message near it that says which rule blocked the move, not a general error. I also have to handle a second drag that starts before the first answer arrives, so each move gets an id. Better still, the board can load the allowed moves first and dim columns that are not valid.”
Weak answers leave the card in the wrong column after a failure or show an error with no reason.
6. You are reading an issue while a teammate changes its status and adds a comment. How would you design the page so you see those changes without reloading, and without losing what you are typing?
- Choose the channel: a socket or server sent events, with polling as a fallback.
- Send small change events and apply them to a local store.
- Never overwrite a field the user is editing.
- Handle reconnects by fetching what was missed.
“I would open one connection per tab and subscribe to the issue being viewed. The server sends small events, such as status changed or comment added, each with a version. The client applies them to a local store and the view updates. If I am typing in the description and a change arrives for that field, I do not replace my text. I show a note that a newer version exists and let me compare. After a lost connection, the client asks for everything since the last version it saw. When the tab is in the background, I would slow down or pause updates.”
Weak answers reload the full issue on every event and wipe the text the user has not saved.
7. An app from another vendor, shown inside the issue view, loads slowly and users blame your page for being broken. What do you do?
- Measure how long the embedded app takes and how often it fails.
- Make sure your own content renders first and never waits for it.
- Give the app a loading state, a timeout and a clear label.
- Share the data with the vendor and with admins.
“First I would measure it, so we know how slow the app is and for how many users. Then I would check that our own page does not wait for it. The app should sit in its own frame and load after the main content, ideally only when its panel scrolls into view. It should have a fixed size so the page does not jump, a loading state, and a timeout that shows a message naming the app. That way users can tell what is slow. I would also share load times with the vendor and show them to admins.”
Weak answers say it is the vendor's problem and leave users staring at a page that looks broken.
8. What draws you to building the interface of tools that teams use for hours every day to track work and write pages?
- Say what is different about a tool used all day.
- Give an example from your own use of such tools.
- Name the frontend problems that interest you.
- Say what you want to learn.
“A work tool is different from a site people visit once. If a board takes a moment too long to respond, a team feels that many times a day. I like that kind of pressure on quality. I have used Jira and Confluence in my own teams, and I notice small things, like how fast I can create an issue from the keyboard. The problems interest me too: editors, drag and drop, live updates and dense screens that still need to be accessible. I want to learn how to keep such a large interface consistent across many products and teams.”
Weak answers could be about any website and show no feeling for tools that people work in all day.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.