Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asana Engineering Interview Guide

blog.asana.com

Post reply on HN
Print view View original

91–100 of 152 posts

Re: Asana Engineering Interview Guide

#91

Post by markbnj »

tptacek wrote: post #30

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…

>> 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.

Phenomenally good advice. I wonder, and I don't mean this to be a loaded question because I really don't know the answer: do other practitioners in other highly-skilled disciplines have to dance these sorts of dances to get hired? Does a doctor have to diagnose on the spot? Does an architect have to design a building on a whiteboard? Do they make a lawyer stand up in front of a group of partners and argue some case off the top of his head? Perhaps they do. I really don't know. But it seems to me that basically professional experience counts for little other than to keep the resume out of the trash folder.

Re: Asana Engineering Interview Guide

#93

Post by viraptor »

markbnj wrote: post #91
tptacek wrote: post #30

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…

>> 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. Phenomenally good advice. I wonder, and I don't mean this to be a loaded ques…

Don't know about the architect, or a lawyer, but doctors do get real-life questions... although probably not the ones with years of experience and more letters in the title than in the name. A bigger difference though is that lawyers and doctors have to pass an exam to practice their profession, which already excludes a lot of people. Anyone can be a programmer.

Re: Asana Engineering Interview Guide

#94

Post by bertr4nd »

tptacek wrote: post #38
dvt wrote: post #22

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,…

I agree with this sentiment wholeheartedly but bounds on balanced binary trees are worth knowing (like lookup, it's log n), since that fact is one of just two reasons you'd ordinarily ever use a tree. However, I will offer you some Interview Candidate Self Defense, which I'll repeat from something I yelled on Twitter a few weeks ago: If interviewers ask you about bounds for data structures, pick a fight with them ove…

I assume you mean this tongue-in-cheek, but someone yelling at me in an interview is probably not going to score well on the "Do I want to work with them?" X-factor.

Of course, a well-informed discussion of hash table complexity would be pretty fun to hear from a candidate. It's always great when I learn something new in an interview.

Re: Asana Engineering Interview Guide

#95

Post by dbt00 »

sudo_bang_bang wrote: post #27

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.

I just accepted a position at Asana, and I don't have a CS degree. Are you sure you're correctly attributing your non-offer here? (Note I don't call it a failure. Hiring is a weighted RNG -- false negatives are common.)

Re: Asana Engineering Interview Guide

#96

Post by dbt00 »

tptacek wrote: post #38
dvt wrote: post #22

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,…

I agree with this sentiment wholeheartedly but bounds on balanced binary trees are worth knowing (like lookup, it's log n), since that fact is one of just two reasons you'd ordinarily ever use a tree. However, I will offer you some Interview Candidate Self Defense, which I'll repeat from something I yelled on Twitter a few weeks ago: If interviewers ask you about bounds for data structures, pick a fight with them ove…

This is mostly good advice -- it's worth knowing both worst case and amortized average time -- but plenty of interviewers will filter you if you're being an aggressive asshole, even if you're right about facts.

Make sure you're considering what the workday environment is like (something you can usually tell from the prep materials or discussions with recruiters) and acting the way you think you'd act in that environment.

Re: Asana Engineering Interview Guide

#98

Post by tptacek »

bertr4nd wrote: post #94
tptacek wrote: post #38

Earlier quoted context omitted.

I agree with this sentiment wholeheartedly but bounds on balanced binary trees are worth knowing (like lookup, it's log n), since that fact is one of just two reasons you'd ordinarily ever use a tree. However, I will offer you some Interview Candidate Self Defense, which I'll repeat from something I yelled on Twitter a few weeks ago: If interviewers ask you about bounds for data structures, pick a fight with them ove…

I assume you mean this tongue-in-cheek, but someone yelling at me in an interview is probably not going to score well on the "Do I want to work with them?" X-factor. Of course, a well-informed discussion of hash table complexity would be pretty fun to hear from a candidate. It's always great when I learn something new in an interview.

I'm like 60% tongue in cheek, because the reality is, for every interviewer who will filter you for being too aggressive, two more will filter you for lack of confidence.

Re: Asana Engineering Interview Guide

#99

Post by sulam »

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.

Re: Asana Engineering Interview Guide

#100

Post by sulam »

tptacek wrote: post #98
bertr4nd wrote: post #94

Earlier quoted context omitted.

I assume you mean this tongue-in-cheek, but someone yelling at me in an interview is probably not going to score well on the "Do I want to work with them?" X-factor. Of course, a well-informed discussion of hash table complexity would be pretty fun to hear from a candidate. It's always great when I learn something new in an interview.

I'm like 60% tongue in cheek, because the reality is, for every interviewer who will filter you for being too aggressive, two more will filter you for lack of confidence.

I have never once filtered someone for lacking confidence. I have never seen someone filtered for lack of confidence by any panel I've been on or any panel I was the hiring manager for. At this point in my career I have interviewed ~1000+ engineers.

I think you're interviewing with the wrong people, or at the wrong places. Way too many people treat interviewing as a way of demonstrating intelligence via computer science trivial pursuit. 5 minutes with Google will demolish 99% of the questions you might ask if all you care about is getting correct code on the board. The interesting part is the process and discussion the code creates, not whether or not they know the secret handshake.

Post reply on HN