Asana Engineering Interview Guide

Do these companies not recognize that moment of cognitive dissonance that surely -must- come when, as they're faced with "how do we determine if someone will be productive coming here" decide "I know; let's ask a bunch of questions we don't expect them to know! And then, let's provide a study guide so that they -can- cram before the test and come in and show they know it!"

I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve, but to implicitly admit it, -and- to also acknowledge that it isn't something you expect people to have off the top of their head by providing a study guide? What are you trying to measure?

I came looking for some new or interesting way of doing tech interviews, but it's the same typical SV bullshit. Lol: "Hashes, sets, heaps, binary trees, linked lists, all the usual suspects." Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. I'm a strong believer that there are two primary ways of testing someone's coding ability:

1) Open-source, or otherwise public, contributions.

2) Real-world take-home assignments.

I've opted out of interviewing people because it's such a miserable experience. I guess I'm just not a sadist that enjoys watching some poor 22-year old squirm in his chair because he can't remember what the upper bound on the insert operation of a red-black tree is.

What a joke.

> “We want every candidate who comes into an interview with us to feel prepared and confident.”

Was expecting to then see a list of specific resources that a candidate could use to become prepared and confident. Instead, the guide provides a high-level overview of "algorithms", "data structures", and "modeling" and refers me to "HackerRank and Interviewing.io" for tips on how to prepare.

This seems like it could be improved. You value learning -- so give candidates something to learn and see if they can do it.

> Our goal is not to simulate day-to-day software development — where we read docs and write lots of tests!

I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard.

I recently interviewed with Asana, and unfortunately would review their process as the opposite of what they're going for.

The first sentence is not far off from what their process is. My interviews with them were composed of one helpful database problem, after which they explained how they designed their production database, followed by a bunch of frivolous algorithms problems.

I did not receive an offer from them, so take what I say with a grain of salt. Asana seemed like a company that has some great engineers, and runs well in general. I would, however, like to provide some constructive criticism for their interview process.

1. Their engineers can use some training on how to interview. Several of them came into the room noticeably anxious. Hearing what the problems were was easy, but communication was very difficult when it came to figuring out what kind of answer they were actually looking for.

2. The questions they use are very academic, which to me means they are mental exercises lacking practical grounding. As an interviewer, it's very uninspiring to have to solve academic problems without getting a peak into the business' real problems.

3. The whole process wasted way too much time. Obviously I wouldn't have cared as much if they had given an offer, but I think it's important to be conscious of this nonetheless. My suggestion would be to pick topics for interviewers to cover, and cut out the repetition of the problems. Plan a process that will lead to a decision with one shorter visit, be respectful of peoples' time.

I hope that helps. I received more offers I'm excited about, and I hope to see the company succeed from the outside.

The funny thing is that Asana is possibly the worst performing web app out of all the ones I use on a regular basis. I have a strong suspicion there's at least one or two O(n^2) algorithms hiding there that could use the same kind of attention and reasoning abilities they expect from their candidates.

> We’ll ask you to solve some coding questions in a language and text editor of your choice. Feel free to bring your own laptop, or we’ll be happy to provide one. Notably, we ask candidates not to compile or run their code during this exercise, and not to refer to online resources.

Every time interviewing comes up, I have this funny feeling about letting people look things up vs. whiteboarding them out. Reading this finally broke something loose:

Coding in interviews should be as hard as the hardest coding you'll do on the job. Heck, anything in the interview should be about how you do things when the job is hard.

Now, this doesn't mean under stress. That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that.

They'll pass over people who are exceptionally good at searching / synthesizing information. They'll ding people who focus on tightening the iteration time as a way of learning faster. But that's OK. They've probably built a culture where that kind of person thrives, and they're trying to find more engineers who will thrive at Asana.

Ah, got to love the subscription pop-up with a close button that doesn't work. A timeless web design principle.

Aside from that, when will we get past the requirement for data structure knowledge for positions that center around web design? Data structure knowledge is available at my fingertips throughout the work day. Why must I memorize implementation boilerplate for an interview?

I tried interviewing with Asana and they rejected me on the basis that I didn't have a computer science degree. For the record, I've built apps that have generated millions in revenue and I have many years of experience. If they are trying to be meritocratic and community friendly with this, they should change that aspect of their culture to reflect that.

From the guide: "we ask candidates not to compile or run their code during this exercise, and not to refer to online resources"

Seriously? You don't allow referring to online resources? Do you also unplug the internet connection for all of your existing programmers so they don't refer to online resources?

The whole point of the interview is to see how you would perform at your job at the first place, creating an artificial job for an interview where you swap words in the array or solving some other stupid quiz + disconnecting you from online resources is just plain stupid in my opinion.

I did an extensive set of interviews with Asana and did not enjoy the experience. After an initial screen, I was required to complete a fairly extensive take home data science problem that involved querying an AWS-hosted database, fitting a predictive model on that test data, then writing a report summarizing which factors in my model were most important and what else I might do.

Considering that (a) some of the data in the database was erroneous, but when I alerted them about it they took a long time to respond and I had to just hack a work around, and (b) it was a huge time sink in an otherwise busy week for me, I was very proud of my solution.

It was a simple random forest model, with no exploration of optimizing the parameters, and some simple entropy metrics for feature importance. I wrote nicely encapsulated SQLAlchemy for the database side, then modular sklearn and pandas code for the model fits and plots, including calibration curves in addition to accuracy. I put it all together into an 8 page TeX write up with plots.

I got virtually no feedback, then after a long time I was asked to have a technical phone interview reviewing my submission that was with two data scientists simultaneously.

They barely asked me anything about my code design. They asked a few questions about my choice of accuracy measures and entropy scores, but it was extremely hard to understand what they wanted to hear (why do companies still think that a multi-party phone call is a good use of time??).

It was a major instance of "guess the teacher's password" which was a huge turnoff for me.

Then they asked very vague, high-level questions about designing a news-feed-like interface, and how might you determine which articles are newsworthy on an individual basis. Again, super vague. I threw out all kinds of ideas about seasonality, correlation to major events, properties of your network, ... But nothing seemed interesting to them at all. They clearly wanted someone to recite some well-known stuff Facebook already used, but none of that was part of the job ad or even related at all. It was bizarre.

After that, another mysterious block of time went by with no feedback, then I got rejected with no explanation.

Later I learned that Asana has pivoted to focus on providing Agile junk for enterprise project management, so I was relieved to have dodged that bullet, but it was still a vague and time-wasting interview process, with so much magic "guess the teacher's password" nonsense.

> Our goal is not to simulate day-to-day software development...

I don't understand this. Why do they not want to see how well a candidate performs the tasks that they will be expected to perform on the job? Does this not result in them selecting for the wrong set of skills/knowledge?

Much more interesting is the guide that this blog post mentions at https://asana.com/eng/interview-guide.

I had an onsite interview for a new grad engineering position at Asana recently. It's true that they test you on technical problems you don't know the answer to; sometimes it seems like they tested me on technical problems that had no answer. One of their interviewers, who was in charge of both conducting a one-on-one with me and explaining the programming questions to me, was very friendly but also had a hard time clarifying any of his questions for me. I didn't really understand him and it was obvious from his facial expressions that he believed that his explanations had sufficed from the very beginning. The questions were either too vague and could be approached from many different directions or were so specific that it was obvious the right solution would have to be found in an epiphany-like "aha!" moment of mathematical understanding. I was able to answer and program most of the questions. I have to say that I was really happy to receive feedback following my interview, which no other company did. My advice to Asana: Don't let any one interviewer dominate the experience of the interviewee (especially if you may have suspicious that the interviewer may be overly didactic or has difficulty explaining things.) Of course, that's just my experience. I ended up finding a good position somewhere else and think Asana's interviews were some of the best ones I had the honor of failing.

Sigh, more marketing. Sorry, but at the end of the day any company that does technical interviews evaluates candidates the same ways and asks the same type of questions, having an interview guide that says things like "Instead, let’s open a dialogue. Let’s solve problems together and see what we can learn in the process. Let’s have fun!" is just trying to get more people to apply.

And I'm not slamming algorithms or technical interviews, but its time companies stop trying to dress themselves and say it how it is.

I had a really stellar interview experience at Asana (and, full disclosure, I didn't get an offer).

What really stood out was the pages of notes that the recruiter sent me before inviting me to apply again in a few months. I had just been through many on-site interviews at many companies, and no one came close to providing the level of feedback that Asana did. The document that I was sent can't have been too far off from the unedited notes that the interviewers shared with each other in their debrief. It really spoke to Asana's commitment to transparency and helping develop people - even those they didn't want to hire. I'm happy where I am now, but based on this experience, I would absolutely apply again in the future.

I appreciate the sentiment behind documents like this, but, Asana, you can do better. When you do, you'll find it gets easier to hire people, and, perhaps counterintuitively, the quality of your hires will go up.

Specifically:

It's clear from the tone that you're trying to mitigate the hostility and unfriendliness of the conventional programmer interview. Great! But you need to do more than superficially adjust your tone. What this document describes is literally the circa-1999 software developer interview, in almost every detail --- the fuzzily described coding question, the "algorithm and data structures" interview, the design review.

Everyone has heard of interviews that pointlessly refuse candidates the opportunity to consult Internet references, like every working programmer does every time they code anything ever. But your process goes a step further: you won't even allow candidates to compile their code. How can this possibly be helpful to your process?

The most alienating and hostile aspect of the conventional job interview is on-the-spot whiteboard programming. You shouldn't have programmers write code in interviews at all, if you can avoid it; instead, take a week or two and design programming questions that candidates can do at home, on their own schedule, in their own surroundings.

But if you're going to make people code in an environment that is utterly unlike the one professionals actually work in, the onus is on you to do everything you possibly can to mitigate the performance penalty you're imposing. Why not, instead of coming up with crazy rules like "no running your own code allowed", point your creativity in the opposite direction and find ways to get candidates to be more at ease with writing code with someone looking over their shoulder?

Here are some things you can do right now to make your interviewing guide actually helpful to candidates:

* Provide sample questions. They do not need to be the ones you're asking in real interviews (although: if they are truly good questions, they could be!), but they should be close enough that a candidate would have no business being surprised by the real ones.

* Provide a detailed breakdown of your interviewing process. Do you phone screen? How many times? Who staffs the phone screens? What kinds of questions get asked on them? Who delivers the in-person interviews? How long do they last? These are some of the questions real candidates have about interview processes. I don't understand why more companies don't just answer them up front.

* Provide reference material for candidates. Don't point them to other people's interviewing guides! You know your jobs better than anyone else does... right? How about instead: what are the most popular books on the shelves at your team? (Bonus points: buy those books for candidates). What are some Github repositories you think represent really well-engineered software? What are some examples of really hard problems your team is still grappling with?

I hired for years and years with a battery of over-the-top technical questions and a rolodex of personal contacts. Then my team and I had a crazy idea: we opened our whole interview process up, standardized it, and took pains to make it understandable to people with no experience in our field. What we learned was that there is a huge amount of underutilized talent out there that can't (because it's locked out due to jargon and poorly described requirements) or won't (because it's denied social permission) apply for jobs unless you go out of your way to bring them in. Many of these people are better than you are. At least, they were for me. Stop bloodying your forehead against the wall competing with Facebook and Google for people who --- if they can navigate the process you describe --- can get an offer from those companies any time they want.

Why does everyone love algorithms and data structures of all the CS topics so much? I would like to be asked about covariance and contravariance, LALR parsing or some basic statistics for once.

But more importantly, I would love to be asked about CS topics that arise every day in development: code organization. How many times do you get a new requirement that makes you throw all previous assumptions (that an architecture was naively built upon) out of the window? When it turns out that module A and B, which were completely different and didn't even know about each other, now need each other's data? Yes, this situation arises when original architecture wasn't thought through enough — and we all were guilty of this at one point or another.

Now, what a developer does in that situation is much more important than whether he remembers what complexity what kind of hash table (with all the chaining and hashing types) is. Does he just hack it so it works, creating a lot of fun for future maintainer? Does he decide to spend 2 days to refactor the whole system into a new architecture? Or does he find a balance somewhere in between?

i dont understand why you would even listen to them, their website is such a piece of shit- terrible performance, terrible ui. maybe their infrastructure is good, but i can tell you they absolutely suck at frontend js.

> We design our interview questions to see how engineers work through technical problems they don’t know the answer to yet.

That's the way to do it, I think. In my own technical interviews, I pose (relatively) simple questions that require some problem analysis, a strategy discussion, and then some coding and testing, with a goal of testing aptitude for basic programming abilities like modularization, indirection, recursion, defensive programming, unit testing, etc. I keep things interactive and collaborative and see how much the candidate can do for themselves.

I have interviewed (phone screened) at Asana. It was delightful. I really liked the people I met there and enjoyed the problem I worked through over the phone. It really did feel collaborative and like we were solving a problem together just as software engineers do when they're not in this artificially combative environment we often create when interviewing.

Regarding the problem, I didn't have the best approach out of the gate. In fact, I had a vague memory of the right approach ("I seem to recall it uses two data structures, and if I really stretch I think it was X and Y, but I don't remember the details.") That made it harder to get to the final solution. The interviewer was very good at at talking things through with me in a way that didn't seem like they were frustrated or otherwise grumpy that I didn't know this particular problem cold. They apparently thought the results were encouraging enough to move to an onsite, but I got an offer from my current employer (where I am working with close personal friends) and had to pass on the chance to find out what that would be like.

All in all I think Asana is probably a great place to work. I also like the product, although it seems like you need a whole team to adopt it to make it sticky.

I find it funny that startups only implement these ridiculous hiring practices after they start to grow. Imagine if the founders had to quiz each other on algorithms before they agreed to do a startup in the first place. The first few hires at a startup are arguably the most important, yet they don't go through the bullshit that later stage startups put potential employees do.

Their subscription pop up at the bottom of the page with a close button that does nothing only makes me sure I don't want to work for them.

I like the idea behind this but the actual guide is pretty thin:

https://asana.com/eng/interview-guide

would be great to see a more detailed guide covering the concepts they like to see master of and problem solving skills they are looking for.

Disappointing. The links to Triplebyte and Stripe are far more informative.

How do these question align with the work Asana is doing? Side note: The blog site performance degrades as you keep scrolling down.

Maybe you could hire someone that will design you a mobile website?

I'm not installing your app on my phone...

There are many different types of engineers This guide is for software engineers

this place has so much cash, they may as well hire trial by fire, create an onboarding experience for serious candidates, morph them to your liking or let them go, stop guessing with goofball interview theater.

- smart

- gets things done

- able to actively engage in discussion about software development

- works hard

- wants to work here doing this job

- loves to learn

- not overly dogmatic

The rest, meh.