{"id":4343,"date":"2024-10-17T19:45:15","date_gmt":"2024-10-17T19:45:15","guid":{"rendered":"https:\/\/algocademy.com\/blog\/asana-technical-interview-prep-a-comprehensive-guide\/"},"modified":"2026-10-15T10:34:49","modified_gmt":"2026-10-15T10:34:49","slug":"asana-technical-interview-prep-a-comprehensive-guide","status":"publish","type":"post","link":"https:\/\/algocademy.com\/blog\/asana-technical-interview-prep-a-comprehensive-guide\/","title":{"rendered":"Asana Technical Interview Prep: Coding, Design and Product Sense"},"content":{"rendered":"

Asana makes work-management software, so the problems that fit its interviews are about tasks, projects, dependencies, notifications and many people editing the same data. Prepare the standard data-structure and algorithm set, then practice applying it to that kind of product: ordering tasks with dependencies, keeping a cache, handling real-time updates. This page gives you tested solutions for the likely coding problems and a plan for the design round.<\/p>\n

Asana does not publish its interview script. Candidate reports describe the familiar shape: a recruiter call, a technical phone screen (45 to 60 minutes of coding), and a final loop with coding, system design and behavioral rounds. Some teams may add a take-home or a pairing session. Ask your recruiter what applies to your role, and which languages you can use.<\/p>\n

What to know about the product and stack<\/h2>\n

Using the product for a week beats reading about it. Create a project, add dependencies, assign tasks, use a timeline view, and notice what updates live. Asana’s engineering page on its tech stack says it uses React on the web, native mobile apps, and an in-house reactive data layer called LunaDb, written in Scala, that pushes changes to subscribed clients; as of that page it was being modernized toward GraphQL-style queries. You will not be asked to reproduce this, but it shows what the company cares about: loading related data efficiently and keeping many clients in sync. Source: Asana’s tech stack page<\/a>.<\/p>\n

Coding problems, with solutions that run<\/h2>\n

Order tasks that depend on each other<\/h3>\n

This one is almost a literal feature of the product. Given tasks and “A must finish before B” dependencies, return a valid order, or report that no order exists because of a cycle. The standard solution is topological sort with in-degree counting (Kahn’s algorithm): start with tasks that have no unfinished prerequisites, and as you finish each, decrement its dependents.<\/p>\n

from collections import deque, defaultdict\n\ndef schedule(tasks, deps):\n    \"\"\"deps: list of (before, after). Returns an order, or None if there is a cycle.\"\"\"\n    out_edges, indeg = defaultdict(list), {t: 0 for t in tasks}\n    for a, b in deps:\n        out_edges[a].append(b)\n        indeg[b] += 1\n    q = deque(t for t in tasks if indeg[t] == 0)\n    order = []\n    while q:\n        t = q.popleft()\n        order.append(t)\n        for nxt in out_edges[t]:\n            indeg[nxt] -= 1\n            if indeg[nxt] == 0:\n                q.append(nxt)\n    return order if len(order) == len(tasks) else None\n\nprint(schedule([\"design\", \"build\", \"test\", \"ship\"],\n               [(\"design\", \"build\"), (\"build\", \"test\"),\n                (\"test\", \"ship\"), (\"design\", \"test\")]))\n# ['design', 'build', 'test', 'ship']\nprint(schedule([\"a\", \"b\"], [(\"a\", \"b\"), (\"b\", \"a\")]))   # None\n<\/code><\/pre>\n
O(V + E) time. If any task is left unprocessed, the graph has a cycle, which is exactly the case where the UI should refuse a new dependency. Follow-ups: detect the cycle when a single new edge is added (a DFS from the new edge’s target looking for its source), and find the longest chain of dependent tasks (the critical path) with dynamic programming over the topological order. Our graph DFS lesson<\/a> covers the traversal underneath.<\/p>\n
Detect a cycle in a linked list<\/h3>\n
Floyd’s algorithm: a slow pointer moves one step, a fast pointer two. If there is a cycle they meet; if not, the fast one reaches the end. O(n) time, O(1) space, which beats the hash-set solution on memory.<\/p>\n
class Node:\n    def __init__(self, v):\n        self.v, self.next = v, None\n\ndef has_cycle(head):\n    slow = fast = head\n    while fast and fast.next:\n        slow, fast = slow.next, fast.next.next\n        if slow is fast:\n            return True\n    return False\n\na, b, c = Node(1), Node(2), Node(3)\na.next, b.next = b, c\nprint(has_cycle(a))   # False\nc.next = b\nprint(has_cycle(a))   # True\n<\/code><\/pre>\n
LRU cache<\/h3>\n
A hash map plus recency order gives O(1) get and put. In Python OrderedDict<\/code> does both jobs; in Java LinkedHashMap<\/code> does. Be ready to build it from a hash map and a doubly linked list, and explain why each piece is there. The trade-offs against other policies are in our post on LRU and cache replacement<\/a>.<\/p>\n
Median from a data stream<\/h3>\n
Keep the smaller half in a max-heap and the larger half in a min-heap, with sizes differing by at most one. Adding a value is O(log n), and reading the median is O(1).<\/p>\n
import heapq\n\nclass MedianFinder:\n    def __init__(self):\n        self.lo, self.hi = [], []     # lo is a max-heap (negated values)\n\n    def add(self, x):\n        heapq.heappush(self.lo, -x)\n        heapq.heappush(self.hi, -heapq.heappop(self.lo))\n        if len(self.hi) > len(self.lo):\n            heapq.heappush(self.lo, -heapq.heappop(self.hi))\n\n    def median(self):\n        if len(self.lo) > len(self.hi):\n            return -self.lo[0]\n        return (-self.lo[0] + self.hi[0]) \/ 2\n\nm = MedianFinder()\nfor x in [5, 2, 8, 1]:\n    m.add(x)\n    print(x, m.median())\n# prints: 5 5, then 2 3.5, then 8 5, then 1 3.5 (one pair per line)\n<\/code><\/pre>\n
Mention what changes if values come from a small range (a counting array) or if you only need an approximate median (a sketch).<\/p>\n
Other problems worth practicing<\/h3>\n