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:
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.
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.
Keep up the great work, and continue the work on targeting large enterprise companies in addition to the bottom-up user-growth we currently have.
Recruiter call followed by a technical screen. Then onsite. Onsite was nice and there was a break for lunch too. Overall a pretty smooth process though they did kind of lag in between the screen and onsite.
Gave a simple 90-minute interview with discussion afterwards. The question was easy, and the discussion was smooth. Have a good understanding of your code and be prepared to explain all of your design decisions.
This was a discussion about some algorithm. It was an open-ended question about how I would solve the problem, essentially a proxy for remembering graph algorithms. I didn't pass, primarily because I wasn't familiar with the specific technique for f
Recruiter call followed by a technical screen. Then onsite. Onsite was nice and there was a break for lunch too. Overall a pretty smooth process though they did kind of lag in between the screen and onsite.
Gave a simple 90-minute interview with discussion afterwards. The question was easy, and the discussion was smooth. Have a good understanding of your code and be prepared to explain all of your design decisions.
This was a discussion about some algorithm. It was an open-ended question about how I would solve the problem, essentially a proxy for remembering graph algorithms. I didn't pass, primarily because I wasn't familiar with the specific technique for f