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: I tend to be skeptical about "too good to be true" things, so I came in with somewhat tempered expectations. However, this turned out to be completely unjustified. The great company culture at Asana isn't just hype; it's real. There are many great things that have been cultivated at the Asana work environment, but perhaps more important than the particulars is the process through which such a great environment has developed. Developing a great work environment and culture isn't just something that is paid lip service to, but something that is actively focused on in every decision made. Some of the details that particularly appeal to me though: * Your manager isn't there to dictate what you do, but to support you in becoming a better engineer and achieving your own goals. * Employee growth isn't one-track either - there are several different areas in which an employee can grow, and depending on the employee's particular personality, they can choose to grow broadly or focus on a few areas where they'd like to grow in their role. The coworkers are a really great group of people. All the engineers are extremely talented and smart, and many have backgrounds at places like Google, Facebook, and Dropbox, but you'll also meet various engineers from a non-traditional background as well (such as a music major who worked for Hans Zimmer once). People at Asana are extremely supportive and inviting. I hypothesize the employees here are nicer from the outset due to being a self-selected group (since the work culture appealed to them), but the positive and collaborative environment also brings out the best in everyone - I've certainly noticed this happen for myself. The engineering team is still small enough that as an engineer you can work on the core frameworks running the product, whether they be on Android or iOS, the web client, or on the server, on such things as the data model, the pub-sub system for reactivity, or the client datastore. Perhaps best of all is the opportunity to work on a product that is experiencing rapid user growth (particularly for the enterprise market) and is beloved by its users. It's really encouraging to look at tweets to @asana and see how much users love the product and the company.

Cons: It always feels like there is so much more that we could add to the product if only we had more engineers, but we're stuck prioritizing because of basic constraints due to the number of engineers. We're actively growing the engineering team, but it's a tight market, particularly for the very talented engineers that Asana selects for. The flip side is that Asana is focusing on sustainable growth, which is likely to achieve profitability sooner rather than later due to revenue growth outpacing spending growth. There are internal levels and salary bands used by the compensation team to ensure pay is fair and equitable, but employees don't have direct insight into what level they're considered internally. All that employees know is their salary and stock grants. This means less direct transparency as to how the company views you and whether your own perception of your growth as an employee matches that of the company. The thinking is that this will cause employees to focus more on holistic growth, but I'm not sure it's worth the lack of transparency in an otherwise very transparent organization. Location is a bit of a walk from BART and rather far from the nearest Caltrain station. It is, however, right off of the freeway. This may be more of a short-term factor, though, as the main office will probably have to move to a new building in the coming years due to expansion.