Asana Software Engineer reviews

* Business is doing well and seems well positioned to become an industry leader. * Lots of opportunity for growth and accumulating responsibility. * Managers who care about your growth and wellbeing. * Strong and empathetic executive leadership. * Great teammates.

Especially for a company of Asana's size, the engineering processes and systems are refined and intentional. There are a few things that stand out in terms of helping engineers grow: (a) engineering design process, (b) incident response and learnings, and (c) distribution of responsibility. (A) Building a framework around writing, reviewing, and approving engineering designs requires a delicate mix of autonomy (so engineers feel empowered) and guidance (so engineers don’t feel lost or stuck). At Asana, there’s a support system to make sure that the author understands the goals of the project and is informed about the set of decisions they’re trying to settle. On the other hand, Asana doesn’t shy away from giving members of the team ownership over decisions and preventing an overly consensus-focused decision process. Asana’s philosophy around the end-result is also different. Design docs are not intended to be internal-to-team-facing documented decisions. Instead, they’re a place for the entire engineering team (when relevant) to leave feedback and have a discussion. As a new engineer at Asana, you have the option to read docs and comment threads, even in areas of the system you're not directly involved in. This really helps you gain visibility into system architecture thinking (both current and historical trajectory) and exposes you to challenges and tradeoffs in areas you'd usually treat as a blackbox. (B) As any other company serving realtime traffic, Asana has its share of production incidents. Though there is a lot of work that goes into running that realtime response smoothly, the meat of interesting discussion happens afterwards in a post-mortem. Asana is mindful about when having these in-person-post-mortems are useful and doesn't do them as a matter of process obligation. (C) Internally, Asana has an “Areas of Responsibility” Asana project to outline who is responsible (i.e. often the decision maker or triage-point-person) for which area — technical and not. This helps newer engineers get involved quickly with technical decision making (less HiPPO effect) and also avoids a cycle where people are using entirely cultural knowledge to figure out who has relevant context when working in a new system area.