Pros: Very chill work culture, good food, high talent.

Cons: Small company, unsure of its financials or future.

Pros: Engineers at Asana have the resources and room to be excellent mentors. As an early-career software engineer here, I feel like I am very well supported and grown.

Cons: Motivation has been down lately due to our stock price.

Pros: 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: * Engineering design process * Incident response and learnings * Distribution of responsibility 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. 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. 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.

Cons: Asana has some engineering debt on its hands. The company has been around for approximately a decade and has built some pretty complex things on its own, including a web reactivity framework and a GraphQL-like data loading system. Navigating that tribal knowledge can be tough at first, especially for engineers who are new to the core concepts. As Asana grows, there is also some pressure being put on the current set of leadership and responsibility constructs on a team level. Teams are now being split into “areas of work” with separate eng, design, and product leads, which is a step towards helping alleviate that.