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.

Pros: - Dogfooding the product you work on every day. - Work is streamlined; everything is in Asana, making it easy to do deep work in that setup. - Very nice office. - Great benefits. - Strong engineering culture and great everyday developer experience. Huge investments were made to make dev work here efficient.

Cons: Similar to the cons of working in other "big tech" companies.

Pros: Asana is the best company that I've worked at, even though I've been lucky enough that all of the companies I have worked for have been good. The best thing about Asana for me is that it has a great culture. The company feels like one team, with cooperation and trust between different teams that traditionally don't work well together. Through many techniques, but especially the coaching that the company provides, we help people to become kinder and more effective communicators and to resolve problems better. I have grown in all of these ways while here. Other benefits include: * I work with the best group of coworkers that I have ever had * I work on interesting problems * I work on a product that makes the world a better place by helping people and teams to achieve their goals

Cons: I don't have much to say here. I wish that we'd already replaced all of our JavaScript with TypeScript and Scala, for example, but the important thing is that we are making these transitions. I wish that our chocolate suppliers were more consistent.