Asana Engineering Interview Guide

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.

On the flip side, Asana clearly indicates that they don't test candidates on day to day development. This is good, because now I know I would never work for Asana.

Those interested in non-applicable CS problems would probably love Asana. Although I'm not sure how any of this relates to a pretty basic project management app.

Yeah, exactly! It's like fucking insane how these companies hype themselves up. All you are is a glorified to-do list, calm down, Asana.

I wish they (asana) listed down some of their real problems along with few possible solutions. A candidate can provide his solution or recommend one of their solutions. I think this approach can lead to a nice discussion where both parties can get to know each other.

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.