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

11–20 of 152 posts

Re: Asana Engineering Interview Guide

#11

Post by pklausler »

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

Re: Asana Engineering Interview Guide

#12

Post by avoutthere »

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

Re: Asana Engineering Interview Guide

#13

Post by neofrommatrix »

pspeter3 wrote: post #5
toomuchtodo wrote: post #4

Earlier quoted context omitted.

Yes! Would be interested in seeing how much coding they ask for when interviewing for devops or ops positions. Some orgs require only scripting, some go so far as to want application engineers who also know everything about AWS for devops/ops roles. Disclaimer: I already asked via their google form for this information to be added in their docs.

I haven't followed the recent updates to our interview process closely but we traditionally looked for general knowledge over specific knowledge. I'm not sure how much that has changed recently though. Edited In Response To Parent Edit: Thanks for asking! We should definitely make it clearer if there are differences per role.

"looked for general knowledge over specific knowledge" - incidentally, I was rejected because I could not answer (to the interviewer's satisfaction) how to implement an in-memory LRU cache. I made some good recommendations but the interviewers were expecting a very specific answer which exactly matched http://www.programcreek.com/2013/03/leetcode-lru-cache-java/

Re: Asana Engineering Interview Guide

#15

Post by vonmoltke »

trjordan wrote: post #10

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

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

I also admire that they are upfront about this, but the attitude in general rubs my classical engineering self the wrong way.

"[R]eason[ing] about things from first principles" is not the same thing as having those first principles memorized. That was one thing my undergrad taught me repeatedly. Engineering isn't about memorizing formulas, it is about learning what those formulas mean, how to use those formulas, and when to apply them to a task at hand. Software engineering should be no different. Expecting people to solve hard and novel problems with no resources whatsoever is ludicrous.

Re: Asana Engineering Interview Guide

#16

Post by orangetabbycat »

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.

Re: Asana Engineering Interview Guide

#17

Post by swanson »

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

Re: Asana Engineering Interview Guide

#18

Post by riyadparvez »

orangetabbycat wrote: post #16

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

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

I think this a common problem. Many companies let a single interviewer has huge influence on hiring decisions. What if the interviewer himself/herself had some bias that s/he wasn't aware of?

Re: Asana Engineering Interview Guide

#19

Post by riyadparvez »

twphonebillsoon wrote: post #7
artimaeis wrote: post #3

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

I don't really see whats interesting about this either way. Lots of places you interview at tell you what the interview is going to be like and what you are expected to be familiar with. This is just 'write code and we'll be testing you on data structures and algorithms!' There's some flowery language there about having a genuine desire to want to hire you unlike those 'other evil companies!'... sounds like the same…

I had also the same impression. I think one of the best approaches is let the best engineers at the company go through same interview process. If they can't get pass through the hiring bar of the company, then maybe that company should re-think their hiring process.

Re: Asana Engineering Interview Guide

#20

Post by riyadparvez »

neofrommatrix wrote: post #13
pspeter3 wrote: post #5

Earlier quoted context omitted.

I haven't followed the recent updates to our interview process closely but we traditionally looked for general knowledge over specific knowledge. I'm not sure how much that has changed recently though. Edited In Response To Parent Edit: Thanks for asking! We should definitely make it clearer if there are differences per role.

"looked for general knowledge over specific knowledge" - incidentally, I was rejected because I could not answer (to the interviewer's satisfaction) how to implement an in-memory LRU cache. I made some good recommendations but the interviewers were expecting a very specific answer which exactly matched http://www.programcreek.com/2013/03/leetcode-lru-cache-java/

> looked for general knowledge over specific knowledge

This is one commonly thrown BS regarding interviews. At the end of the day it is all about one-dimensional usual algorithmic questions.

Regarding LRU cache, I think this is one of less crazy interview questions. In one phone interview, I had to solve a DP problem, code it perfectly and pass all the test-cases on HackerRank in less than twenty minutes. I am not certain how many developers out there can pass such interviews without months of preparation in such situations. Tech interviews are basically programming contests. I am not against programming contests or algorithmic questions. But it seems the interview questions are getting crazier day by day.

Post reply on HN