My Awesome Asana Interview Experience

Hi! I’m Vincent. On my journey to find a job as a recent graduate, I recently interviewed with Asana, a mid stage startup based in SF. After my final onsite interview, I was definitely exhausted, but I remember standing right outside their office building and thinking — man, what a place this is, and what an experience that was. So I knew I had to share.

A little background

I graduated a year early, in May 2018, with a CS degree from Boston College. I would like to say I started looking for a job right after graduation, but I think it’d be more accurate to say I really started five months later, in October (I spent most of the summer hanging out with family and friends who were interning in the Bay Area).

In these past few months, I had been mainly looking and interviewing for software engineering roles. One day, however, I was browsing on a job posting site and saw a startup posting for a developer advocate role. At that time, I had no idea what a developer advocate was, but I looked at the job description and requirements, thought “this looks really cool and interesting,” and applied.

Throughout this interview process with this startup, I learned a lot more about developer advocacy. I was ultimately rejected after the final round of interviews — I’ll always remember this because I had a Google interview right after I was notified I hadn’t gotten an offer — but I realized this was a job that I believe I could really excel in. More importantly, it seemed to be something I would love doing.

And so on the same day of the rejection and subsequent Google interview, I searched for other companies that were also looking for developer advocates. What I found in the process is that there aren’t really any developer advocate new grad postings, as there are for software engineering. Still, I thought that if one company had taken a chance to spend time interviewing me, there could potentially be others as well. That’s when I found Asana.

I applied, and on the very next day, a member on the developer advocacy team at Asana got back to me. When I heard back, I remember thinking of the quote “when one door closes, another one opens…”

We scheduled a call for the day after that. It was basically 30 minutes of me asking questions so I could get a better idea of the role, and Asana as a whole. To be honest, I didn’t know much about Asana when I applied. I only knew then that one of the big things they are known for is their culture (more on this later). At the nearing end of the call, he asked me:

“So, are you interested?”

“Definitely!”

Among other things, he told me that the developer advocacy team was comprised of two(!) members, and they were looking to expand to a team of four. I thought this was particularly cool because it meant that the things I would potentially work on would most likely prove to have an impact in the lives of others, and I could also learn a lot from the other two members on the team due to its close-knit nature. Moreover, since the developer advocacy team at Asana is a team within the overall engineering team, I would additionally be able to work with other engineers.

Knowing I was on board, he gave me an outline of the interview process. It would first start with an hour long coding assignment that they gave to all their engineering candidates. If I had passed this, I would go directly onsite to their office and spend a day interviewing there. When I heard this, I was both surprised and excited at the same time. Let me go on an aside and explain why.

For those not familiar with the typical software engineering interview process for new grads at companies like Google or Facebook, it typically goes something like this:

1. Recruiter phone screen (to make sure you are actually a real and somewhat capable human being)
2. Technical phone screen #1 (where the interviewer gives you a problem or two or sometimes even three if they’re feeling really nasty, like validate a binary search tree — hint: use an iterative inorder traversal — or implement a LRU cache — use a hash table and a doubly linked list together (teamwork makes the dream work) to achieve that coveted O(1) time complexity for get and put operations — and you are expected to clearly communicate and code a working solution on Google Docs or any other screen sharing text editor within 45 minutes)
3. Technical phone screen #2 (this can be skipped if you dazzled the first interviewer with your brilliance)
4. Day of onsite interviews (usually consisting of 4 to 5 interviews, with a lunch break)

As this cool person explains in his blog post, your chances of landing an offer go down the more interviews you have to pass. If this seems like common sense to you, that’s great. But here’s a little bit of math just to confirm your intuition.

Let’s say you’re a really good engineer AND a really good interviewee (wow, what a combination — believe it or not, you can be a really good engineer and not so good at technical interviews, or the other way around) and consequently you have a 80% chance of passing each interview. In the example above, let’s assume the worst and say you’ll need to pass a total of eight interviews. Then, your chances of getting an offer turns out to be (.8)⁸ = ~16.8%! So yeah. Those aren’t the best odds. Not to mention, the dreaded interview anti-loop, that Steve explains in his blog post here, is always lurking around.

The bottom line is a lot of things can go wrong in the interview process, some of which may be out of your control. Thus the fewer the interviews you have to do, the better your chances of getting a job offer.

Roughly a week or so after I finished the coding challenge, I heard back and was notified that I had passed the coding challenge. Real cool. I gave them my availability for the day of onsite interviews, and shortly received this confirmation from one of their recruiters:

Before I go into detail about my onsite interview experience, I think it’d probably be a good idea for me to give more context about Asana as a company, and what developer advocacy is all about. If you already have a good idea about the former, latter, or both, feel free to skip ahead!

What is Asana?

On its homepage, Asana is described as “the work management platform teams use to stay focused on the goals, projects, and daily tasks that grow businesses.” The Asana product is used to eliminate the “work about work”, which includes meetings and emails, so teams can focus on the real work. At its essence, it is a productivity tool that is used by teams at Airbnb, Spotify, Lyft, Uber, Google, IDEO, Facebook, The New York Times, and Teach for America, to name a few.

It didn’t take much research for me to realize that Asana is a company many would love to work at. Moreover, the fact that they have been placed on both the breakout list and Wealthfront’s 2019 Career Launching Companies list gives you a sense of where they are right now, and where they are projected to be in the future. Of course, there is much more to Asana than what has been said here. But since the focus of this post is about my interview experience, I will just leave a link here if you want to learn more.

What is Developer Advocacy?

The first time I was searched about developer advocacy, I stumbled upon this Medium post by ashleymcnamara. I don’t think I could explain this role better than she does, as she is a developer advocate, so please give her post a read.

The only insight I can share is from talks with the people who have interviewed me, and with one of my dad’s friends, who has worked at Google as a developer advocate for nearly a decade.

From what I have gathered, there are two main things that being a developer advocate entails:

1. Working with external partners to use your company’s product
2. Working with your company’s internal developers and teams and providing them feedback about the product — this feedback is gained by working with the people using the product (part 1)

At the heart of it, developer advocacy seems, to me, to be a combination of education and technology. The education comes in the form of teaching, as you, as a developer advocate, try to help others with any problems or questions they have concerning your product. Technology then comes into play when you give the users’ feedback to your internal developers, and work with them to help develop the product.

There may additionally be an element of marketing involved, as developer advocates may need to market the product or service their company provides if it is not too well known yet (this was the case at the aforementioned first company I interviewed with).

The best part about all of this is that in the process of helping and collaborating with others, you learn a lot too (remember when I mentioned education?) — whether it be about communication, troubleshooting, or technology in all its forms!

Again, there’s way more to developer advocacy than what I have mentioned here. Personally, I think it is a really cool job that is not realized enough.

Preparation for Onsite Interviews

I essentially had a week to prepare, so I knew I had to prioritize what to study.

My recruiter told me the coding session after lunch would be the only coding I had to do the whole day, and it would be focused on building an integration for the Asana product. To be honest, I wasn’t sure what this meant, but I figured he was purposely vague and didn’t want to give too much away. I didn’t spend too much time preparing for this interview, mostly because I wasn’t sure how I could prepare. I looked on Glassdoor hoping someone before me could help me out, but unfortunately no one had ever posted their interview experience for this developer advocate role.

As a result, I decided I would just review how to work with JSON data and the Asana API by reading their Getting Started guide and some of the code on Github written by Asana’s engineering team. My thinking was that to build an integration for their product, I would probably have to use either their API or some other API. The rest then, I hoped, I could figure out during the interview (god I’m optimistic…) This was pretty much my thinking in a nutshell:

“How in the world am I going to build an integration in less than an hour?”

“Then again, if the interview is less than an hour long, I’m pretty sure it should be something reasonable…right?”

“Yeah, let’s just hope so.”

So that left me with three interviews. I had a feeling the second and third interviews with the two members on the developer advocacy team would focus more on the behavioral, based on what I was told in my first phone call. Here, I figured I would just be as honest as I could be while still presenting myself in the best possible light. After reading some of Asana’s blog posts and exploring their website, I already knew I really wanted to work there, and I had concrete reasons as to why that was the case. The passion was definitely there — I just had to let them know.

And so the interview I mainly focused on studying for was the first one. Since it was listed in the email to be over an hour long and involved whiteboarding, I had guessed it would be a system design interview. For those who are unfamiliar with what a system design interview is, please check this out (sample design questions asked include Design Twitter or Design Instagram).

This was pretty daunting for me for the sole reason that I had never had to try and pass a system design interview before. Nonetheless, I asked some friends who had gone through this trial by fire and consulted the almighty world wide web for some guidance on how I could ultimately impress my interviewer.

Oh yeah, this was the other thing —this first interviewer was the second ever hire at Asana, and has been working there for nearly a decade. Needless to say, he’s a big deal. With that in mind, I decided that even if I were to bomb the coding interview, I would still try to ace this system design interview and leave him in awe of my awesomeness, however improbable that was.

To prepare, I used donnemartin’s system-design-primer repo and Grokking the System Design Interview in tandem. The former explains system design topics in slightly more detail, whereas the latter provides more problems to go through. Both are excellent resources, in my opinion. Here are some realizations I made while studying:

1. My distributed systems professor (shoutout to Professor Lewis Tseng) touched upon a lot of these topics during class. If only I had paid a little more attention…(I took the class pass/fail my last semester in college, since I had already fulfilled all the requirements for my CS major)
2. System design interviews are much more fun (yeah, I just used fun to describe an interview…maybe that’s not the right word) compared to the typical data structures + algorithms coding interviews, since there is no one right answer. These interviews give you more opportunities to showcase your knowledge and experience, since a system consists of many different parts (go figure, right?) and as such you can really wow the interviewer by going in depth and diving deep into an aspect of the system — say, databases

The Day Of

My first interview of the day was at 10am. But before that, I had to get to their office first; Asana’s SF office is located in the Mission District, and about a 10 minute walk from Airbnb’s HQ on Brennan Street. For another (and maybe more useful) reference, it is less than a 10 minute drive from the SF Caltrain station. I live in Mountain View, and so I had planned to take the ~8:30 Caltrain and arrive in SF at around 9:30. Then, I could call a ride to bring me to their office. But as so often happens, life had its own plans for me.

Long story short, the trains that morning were not running on schedule, for some unknown reasons. The train I had planned to take had been delayed, and I knew if I had waited for the next train available, I most likely would have been late to my first interview. And I definitely did not want that to be the first impression I made.

Luckily, my dad had waited around the station after dropping me off, and saw my message that the trains were delayed. He said he could drive me instead, and thanks to his masterful driving, I got to the office building with plenty of time to spare. He definitely saved me there.

When I got to their reception desk on the 2nd floor of the building, one of their employees greeted me, made me a badge and told me one of my recruiters would be notified shortly of my arrival. He told me that I was early, but it was definitely better to be early than late. Amen. In the meantime, I could help myself to any drinks or snacks in the mini kitchen bar located next to the reception desk.

As I’m writing this, I realize I should’ve took some pictures. But at that time, I was naturally more focused on the upcoming interviews. I also did not plan on writing this blog post. For some visual context, check out their Instagram here.

A while later, one of my recruiters came to get me and since we still had time to spare, she took me upstairs and showed me around. She told me that Asana shares the building with other companies, and operates on several floors. As I followed her around, I found that the floors had modern designs with a focus on the concept of open space. Based on my description, you might be able to tell that I don’t know much about architecture and design — I just thought that their office floors were really nice (fun fact: their building used to be home to a brewery).

What really got my attention, however, was a dog lounging in their café. My recruiter told me that Asana is a dog friendly place and on Wednesdays, their day of no meetings, all the employees bring their dogs and a dog party basically comes to life. In other words, each Wednesday becomes a day of bliss. As a big fan of dogs, especially huskies, I thought that was awesome.

Finally, my recruiter led me to this cozy room with glass panels, a whiteboard, and a small round table in the middle, with a couple of chairs placed around it. As I stood by the window in the room, I could see Franklin Square and the Mission District. She told me all my interviews on the day would be done here, and that my first interviewer would be here soon. I thanked her, and then she left.

My First Chance to Impress

My first interviewer, Asana’s second ever hire, aka my potential big boss, came in a few minutes later. After he introduced himself, he laid out the plan for this interview— we would talk a little first, and then dive into the technical problem after. He wanted to get a better sense of who I was and started by asking about my background, why I wanted to work at Asana, and why I wanted to be a developer advocate. In turn, he told me about himself and the company, and here something he said really stood out to me. It has to do with Asana’s culture.

He said that the cofounders, Facebook cofounder Dustin Moskovitz and ex-Googler Justin Rosenstein (fun fact: both Dustin and Justin had each made a product like Asana while they were working at Facebook and Google, respectively), developed — and still develop — Asana’s culture as they would a product. Accordingly, their culture goes through its own development lifecycle, where it is designed and iterated upon.

Another thing that resonated with me, while I was looking through Asana’s website, is Asana’s commitment to diversity and inclusion. As a third culture kid and someone who moved quite a bit growing up, I know how tough it can be to feel like you belong. So when I found out that that they have Employee Resource Groups and even recently started a event series called Real Talk, to encourage authentic discussions on a myriad of issues important to different communities, I was charmed.

After this, we transitioned to the technical part of the interview.

We walked to the whiteboard, where he showed me an app on his phone. He described what this app did, and listed out some use cases on the whiteboard. The focus of the interview then, was for me to design a database schema that could be used to satisfy the use cases.

When I heard this, I was slightly bummed out, because this was not the system design interview I had prepared for. As a result, I would not in fact be able to dazzle him with my system design and distributed systems knowledge that I had been reviewing, like a mad man, for the past week.

While I did study stuff about databases, they were mostly as it related to system design. Namely, the pros and cons of SQL vs. NoSQL databases, the different types of NoSQL databases, and scaling techniques like replication, federation, and sharding. I did not study much about database schemas. Still, I didn’t let that discourage me, and tried to remember as much as I could from what I had learned in my databases course a little over a year ago.

We managed to get through all the use cases he had listed at the beginning, but by then we only had a few minutes left, and he said he wanted to leave time for me to ask any questions I had for him. I got the feeling that had I gone through the use cases faster, he would have had more followup questions for me. I knew then that this was an interview I could have definitely done better in, since I already knew the material but just hadn’t visited it in a while.

Even so, I didn’t want that to weigh me down, seeing that I still had the rest of the day to go. Regardless of my subpar performance, I felt like it was a nice interview — a big reason for this is that as I went through the problem and voiced ideas to solve the problem, he was interactive and helpful, providing me with hints whenever I got stuck.

Meeting the Developer Advocacy Team

After he left, my second interviewer came in. This was the same person I had first talked to on the phone, one of the two members of the developer advocacy team. As I had more or less guessed, this interview was mostly behavioral. A big part of it was him presenting scenarios and problems that could occur, or had already occurred in his experience on the job, and asking me how I would deal with them. Near the end of the 45 minutes, he, like the first interviewer, left me some time to ask him anything I wanted to know. To be honest, I wasn’t sure what he thought of my answers, and therefore I had no idea how I did here. I just did the best I could.

Next came my third interviewer, the other member on the developer relations team and my potential direct boss. This interview, to me, definitely felt like my best interview, mainly because it didn’t feel much of an interview at all. Of course, I have no idea what he thought of it all from his perspective, but from the moment I shook hands with him, I felt like we clicked (cue upbeat happy music). This interview overall was a little more technical than the last, but still very conversational. Before I knew it, 45 minutes had nearly gone by, and he likewise left some time for questions. All I knew at the end of this interview was that I would love to have him as my boss — what a real, friendly and genuine person. It’s funny it turned out this way, because when I checked out his LinkedIn profile beforehand, I remember being intimidated by his picture, just because of how cool he looked.

An Adventure to their Café

At the end of my third interview, a lady came up to me and told me she would be my lunch buddy for the day. She took me to the café where the dog had been lounging at the beginning of the day, and we found a table to sit at after getting our food.

Speaking of, the food at Asana is amazing —let me just go on the record and say their culinary team is no joke. That day, I believe lunch was mediterranean themed, but they have dishes inspired by all cultures and places. For example, my lunch buddy told me that they had Hawaiian poke the day before. You can check out their culinary team on Instagram here.

At the beginning of lunch, I was slightly distracted, thinking about how I had done in my first three interviews, and the coding session and interview that was still to come. I think my lunch buddy could tell; she told me she remembered how exhausted she was after her day of onsite interviews. She asked me about my hobbies, favorite TV shows, books, and whatnot. As she shared more about herself, I remember thinking, wow, this woman is awesome. We talked about our mutual interest in soccer, which led to her telling me that companies around the area form teams and compete with each other in a league. She also showed me a picture of her beautiful dog called Snacks, which I thought was a great name.

Through our conversations, I was able to relax a little more and enjoy lunch. I probably wasn’t the best person to have lunch with, just because I was already pretty tired by then and knew I still wasn’t done. As my hour lunch break was nearing its end, I knew I was very lucky to have her as my lunch buddy, and very grateful to have been able to meet her. God bless.

The Final Interview

After my lunch buddy brought me back to my interview room and left, my last interviewer came in. This engineer told me a little bit about what they were currently working on, and subsequently gave me a coding problem that was given to all onsite engineering candidates. I was to go over it, and ask any clarifying questions before he left for 50 minutes, during which I would be on my own and expected to code as much of a solution as possible.

As I read over it, I was surprised because, as I mentioned earlier, my recruiter had told me this interview would involve building an integration. Yet in reality, the coding problem I was asked to solve was not that at all. I told my interviewer this, and he said that the “build an integration” problem was still in development.

I thought, “okay, that’s cool. I’ll try my best to solve this problem.” To me, the problem was pretty unique — one that you probably wouldn’t encounter while interviewing at a company like Google. Instead, I was given a list of functions, all relating to the same problem, and descriptions of what the functions were supposed to do. What I had to do then, was implement these functions. In a way, I thought this could have even passed as a problem set that I might have been assigned in one my CS courses in college.

The only difference is that in college, I would probably be given a day or two at least to finish this problem set, whereas I only had 50 minutes here. Alas, at the end of the 50 minutes, I had implemented some of the functions, but not all of them. As such, I was really glad that I had an additional 50 minutes to go through my code and thought process with my interviewer afterwards.

For these additional 50 minutes, I did my best to explain what I had implemented, what I would have wanted to code if I had more time, and how I approached the problem. I remember drawing pictures on the whiteboard with the hopes that my interviewer could better understand the ideas I was trying to convey. I’m not sure how successful I was in doing so, but we managed to find solutions for all the functions initially described at the end of it all. I want to point out here that this interviewer was really patient in listening to my ideas and solutions. I also appreciated the fact that they did not belittle or dismiss my ideas in any way, and instead tried to help me as much as possible without giving too much away.

I’m not sure how my performance fared compared to previous engineering candidates, but I was glad I was able, with my interviewer’s help, to at least solve the problem at hand. I don’t think this was a problem I could have specifically prepared for, as it relied more generally on mastery of data structures and knowing which ones to use. Equally as important, as emphasized by Asana in their first coding assignment, are code design, readability, and proficiency with a chosen language (if you’re curious, I used Python, because that’s what I’m most comfortable with, and you can achieve a lot with minimal syntax in Python — you don’t have a lot of time to code in these interviews; for this reason, the less you have the type, the better).

After this interview, I was pretty much finished. After my last interviewer left, my other recruiter came in the room to wrap up. Among other things, he asked me about any deadlines I had regarding other offers, and if I had a compensation range in mind. When I heard this, I remember thinking that I really just wanted to work here. I didn’t really mind how much I get paid, as long as it was reasonable. I trusted that if I were to receive an offer, he would give me the best possible offer, for he said he has never been rejected by a candidate because of compensation. Finally, he let me know when I could expect to hear back, and escorted me out of their building.

Aftermath and Closing Thoughts

Mission Dolores Park — Photo by Koushik Chowdavarapu on Unsplash

After my interview, I walked to Mission Dolores Park and just sat on a bench, replaying the day in my head and thinking about things I could do better next time. For a little over a week, I prayed every night, hoping that my recruiter would get back to me with good news. After going onsite and meeting some of the people who worked there, I really believed — and I still do — I would love working at Asana.

And that’s why I was definitely disappointed when my recruiter let me know, a little over a week after my onsite interview, that I would not be getting an offer. Still, I started writing this blog post less than an hour after I heard back. Even though this was the outcome, I still felt compelled to share my experience, because I am really grateful that I had the opportunity to interview at a really cool place and meet the people who work there.

For now, for me, the job search continues — here’s hoping for great things to come in 2019. If you have read this far, a massive thank you, and if you enjoyed reading this or have any questions regarding my experience, feel free to leave a comment!