Asana·Software Engineer·Onsite - System Design / Architecture
Jul 2026
Asana system design round focused entirely on building a collaborative todo-list service, the kind of thing that sounds deceptively simple until you're 20 minutes in and realize you haven't even touched real-time sync yet. Heavy on trade-offs, concurrency models, and consistency decisions.
- Design a collaborative todo-list service where teammates can create shared lists, add and edit items, assign owners, set due dates, reorder items, and see each other's changes in near real time across web and mobile.
- How would you order concurrent changes to a shared list so every client, including one that's been offline, can reason about what happened and catch up from a single cursor?
- When multiple users reorder items at the same time, what goes wrong with dense integer positions and how do you handle the merge?
- Walk through how a committed write reaches all other connected clients. What guarantees that the published event isn't lost if the message bus is briefly unavailable?
- How does your design change if a single hot list suddenly has thousands of simultaneous editors instead of tens?
- An offline client made three edits while disconnected, two of which conflict with changes committed by others in the meantime. What happens on reconnect and what does the user see?
- How do you prevent the operation log from growing indefinitely while still letting a client that's been offline for days catch up?
- If you needed to add collaborative rich-text editing inside an item's description, what would you change and why is that harder than syncing item fields?
“This is the main question and it ate the whole session.” The rest of the author's notes on Software Engineer interview at Asana, Onsite - System Design / Architecture round, covers how they worked through the question, what the panel pushed back on, and what they would do differently.
View Post