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

51–60 of 152 posts

Re: Asana Engineering Interview Guide

#51

Post by pspeter3 »

wdewind wrote: post #48
pspeter3 wrote: post #42

Earlier quoted context omitted.

As an interviewer at Asana, my favorite questions to ask are based on actual technical problems we have had to solve.

Yep this does not surprise me. Reading the guide it's clear to me that when you say: > Our goal is not to simulate day-to-day software development You don't mean at all, you mean in its entirety (so you are leaving out the aspects you are less interested in, like reading stack overflow, and emphasizing the aspects you are more interested in, like reasoning about data structures). I think a lot of people on HN are get…

Absolutely and thanks for the advice. I think we should change that sentence. Looking forward to the one from Justworks!

Re: Asana Engineering Interview Guide

#52

Post by lostcolony »

bostonpete wrote: post #45
lostcolony wrote: post #25

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…

> let's provide a study guide so that they -can- cram before the test Did you look at the guide? I don't see anything you would be motivated to cram after reading through that other than to brush up on the "usual suspects" of data structures, but you should be doing that before any technical interview anyways IMO. Seems like the guide is mostly intended to give candidates an idea of what to expect during their interv…

Yes. Under "How To Prepare" -

Read through technical interview prep resources HackerRank and Interviewing.io are good places to start. We’re also fans of InterviewCake’s Coding Interview Tips.

I.e., "here, go study and cram for your quiz". If you expect people to know the data structures and algorithms off the top of their heads (because you believe that to be useful), then why tell them to prep?

That's what boggles my mind. Technical interviews relying on data structure and algorithmic questions started with a few companies (primarily Google) thinking it was a good way to gauge how strong a candidate was. For their purposes, it might have been. But as other companies started to cargo cult it (despite their businesses requiring far less algorithmic work), a cottage industry of interview prep sprung up (Cracking the Coding Interview, various sites intended to help you practice, etc). And since that then raised the bar (you were now competing against people who were -explicitly preparing- for these kinds of questions, and frequently would have seen the exact question they're being asked, or one akin to it), companies, such as Asana, decided "Okay, to be fair to everyone, we need to warn them that we're asking these kinds of questions and so they should prepare well in advance for them".

Or...you could take a good hard look to decide if that's the skillset that is really important in your hires. If it is, you can probably give them legitimate business questions (which to be fair, Asana might do), as it will cover some of the same basics, but then giving the candidate access to Google, and access to querying and digging and figuring out how best to solve it might be a better gauge of their ability to solve those problems in the real world (unless for some reason they're going to be developing without access to technical resources and the internet). Or, you might find that your business actually requires people able to solve different problems, where implementing fisher yates is not the key technical deliverable, and so you can instead ask those kinds of questions, and see who can solve them based on what they know, and what they think to ask you during the interview.

Re: Asana Engineering Interview Guide

#53

Post by usaphp »

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.

Re: Asana Engineering Interview Guide

#54

Post by SkidanovAlex »

usaphp wrote: post #53

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

The very next sentence there is "Our goal is not to simulate day-to-day software development", so no, they probably do not unplug the internet connection for the existing programmers.

Re: Asana Engineering Interview Guide

#55

Post by usaphp »

SkidanovAlex wrote: post #54
usaphp wrote: post #53

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

The very next sentence there is "Our goal is not to simulate day-to-day software development", so no, they probably do not unplug the internet connection for the existing programmers.

Why don't they ask them to play soccer on the interview or see how fast a person can run, if they don't care if the candidate will perform well in their day-to-day software development?

Re: Asana Engineering Interview Guide

#56

Post by szx »

pspeter3 wrote: post #49
szx wrote: post #32

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.

First, we're actively working on improving page load times. Second, having discovered issues with algorithmic complexity makes me question claims that they are not important for day to day work. What do you think?

Algorithmic complexity is certainly important. Intuition and knowledge of (or ability to research) the pros and cons of existing algorithms are essential. However, I don't think you need to see a single line of code (on a whiteboard or not) in order to test for that.

Re: Asana Engineering Interview Guide

#58

Post by pklausler »

p4wnc6 wrote: post #40
pklausler wrote: post #11

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

The problem is that Asana seems to have preconceived ideas of what answers are supposed to look like, but the questions are vague and open-ended enough that even very good candidates can give good answers that simply diverge from the manner of thinking that the Asana question designer had in mind. If the question has a well-defined answer, then this is good. If you are asking questions that the candidate "doesn't kno…

I use problems with multiple acceptable solutions and easy tests of correctness -- i.e., it's obvious whether or not the approach is sound and the code works. For example, write a function that determines whether two rectangles on a display overlap, given the coordinates of their corners. Solving it requires the ability to analyze the problem and describe the conditions, the ability to code a simple Boolean predicate, and some aptitude for checking boundary cases and writing unit tests. I have others; what they have in common is that they're really easy problems for great programmers, and well within the limits of a 45-minute technical interview for competent coders, and good at exposing candidates who lack some basic skills.

Re: Asana Engineering Interview Guide

#59

Post by pspeter3 »

szx wrote: post #56
pspeter3 wrote: post #49

Earlier quoted context omitted.

First, we're actively working on improving page load times. Second, having discovered issues with algorithmic complexity makes me question claims that they are not important for day to day work. What do you think?

Algorithmic complexity is certainly important. Intuition and knowledge of (or ability to research) the pros and cons of existing algorithms are essential. However, I don't think you need to see a single line of code (on a whiteboard or not) in order to test for that.

I agree

Re: Asana Engineering Interview Guide

#60

Post by jasode »

yummyfajitas wrote: post #50
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…

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? Here's how. Some problems - particularly those involving concurrency - don't lend themselv…

>It sounds like Asana wants to determine if people can do this kind of thing.

Same for Facebook/Google/Apple/Microsoft/Amazon/etc that also use whiteboard interviews. Those types of companies value seeing candidates' thought process more than the final code of work-at-home test questions. There's a signal there in whiteboard interviews that can't be replicated by at-home tests. Whether that unique signal is valuable or worth the cost is up for debate (as the ongoing disagreements about hiring practices show).

Post reply on HN