Asana · Primly Community

Asana senior / L5 system design interview, what to expect (went through it in March 2026)

corp_refugee · 5 replies

Just finished my Asana loop a couple months ago for a senior SWE role. Sharing since there's not a ton of detail out there on what the system design round actually looks like.

Short version: it's not a trick. They want to see how you think about collaborative, real-time systems, which makes sense given what Asana actually is.

The prompt I got: design a real-time task management system that handles concurrent edits. Basically a stripped-down Asana. I don't know if that's a permanent prompt or rotates, but it felt very deliberate.

What they're actually looking for: How you handle conflict resolution when two users update the same task field at the same time (CRDT, last-write-wins, OT, whatever your reasoning is). Your API design, both REST and thinking about when WebSockets make sense vs polling. How you'd shard or partition data for a team with 50,000 tasks. Notifications and event propagation at scale.

They pushed back on every hand-wavy answer. When I said 'we can use a message queue' they immediately asked which one, why not Kafka vs SQS, what happens if the consumer falls behind. Standard stuff but they don't let you skip it.

The interviewer was an L6. Asked clarifying questions throughout rather than just listening. It felt more like pair designing than a test, honestly. That surprised me coming from places where the interviewer is stone-faced for 45 minutes.

Time: 45 minutes actual design time, 5-10 minutes of intro and wrap.

One thing I'd flag: Asana's product is deeply about workflows and dependencies. If you can naturally work in comments like 'task dependencies would need special handling because...' it signals you've thought about their domain, not just abstract system design.

I made it to the next round so this worked well enough. Happy to answer specific questions.

5 replies

staff_steph

The collaborative-editing angle is real. I interviewed there a while back and got a very similar prompt. They care a lot about consistency models. Worth reading up on eventual consistency vs strong consistency tradeoffs before you go in. Not because they want you to lecture them, but because the 'what are you willing to sacrifice' question will come up.

corp_refugee

Exactly this. They asked me directly: 'for a task name field, does the user care about strong consistency or is eventual okay?' The right answer depends on product reasoning, not just tech. I said eventual is fine for name but you'd want stronger guarantees for task status in a workflow dependency chain. They seemed happy with that framing.

visa_vik

How many system design rounds is it total? And is there a separate architecture or infra round or just the one?

corp_refugee

Just the one system design round in the onsite. The other technical rounds were coding. There's no separate infra round unless you're interviewing for a platform-specific role.

careerveteran

Good write-up. As a hiring manager I'd add: bring a whiteboard structure from the start even in a virtual setting. Scope, constraints, API, data model, scale. Interviewers at companies like Asana see a lot of candidates who jump straight to the fun distributed systems part. Anchoring the conversation early is what separates good candidates from great ones.