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

61–70 of 152 posts

Re: Asana Engineering Interview Guide

#61

Post by bostonpete »

lostcolony wrote: post #52
bostonpete wrote: post #45

Earlier quoted context omitted.

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

Wow, you really read way more into that than I would have. I barely even looked at the first bullet in the "How to Prepare" section. I suspect it's was just there for completeness and I think it's basically a given that people should brush up on technical interview-type questions before going into a technical interview.

For me, the real meat of that section was in the 2nd and 3rd bullets!

The 2nd bullet is telling people to reflect on their experiences and come prepared to discuss. This may be a no-brainer for some, but for those who don't have a lot of interview experience, I suspect it's easy to get caught up with the "what should I know" mentality and forget to spend a little time reconstructing the interesting projects and situations that they've navigated in your career. For most of us, only the most recent stuff tends to be fresh in our minds.

The 3rd bullet emphasizes that you should come prepared to evaluate them. Again, perhaps a no-brainer for most experienced candidates, but it's nice to see the interviewers acknowledging that this is a two-way evaluation and encouraging candidates to be sure they're making the right choice.

While it's unusual for candidates to show up unprepared for technical questions, I've seen many candidates show up completely unprepared to discuss their experiences or ask questions that will help them evaluate the position/team/company/manager.

Re: Asana Engineering Interview Guide

#62

Post by thedufer »

vonmoltke wrote: post #15
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 als…

Much of the point of "first principles" is that there aren't very many of them. If you have any trouble at all remembering them, you can be fairly certain that you have not trimmed enough.

Re: Asana Engineering Interview Guide

#63

Post by tptacek »

jasode wrote: post #60
yummyfajitas wrote: post #50

Earlier quoted context omitted.

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…

I am not disputing that it is possible to design serious, rigorous evaluations that somehow hinge on candidates not using their normal tools to answer programming questions.

What I dispute is that anyone really does that.

It is awfully easy to rationalize any hazing ritual with this sort of six- degrees- of- concurrency- and- formal- methods logic. But there's a simple observation to make about all these questions: they do not mimic the experience of doing the work the interviewer is evaluating candidates for.

The more a question diverges from the experience of doing the job, the more process and framework and structure and rigor is needed to extract value from it. But really: most of these questions are just the same dumb fucking programming questions, just with different variants of the interviewer repeatedly whacking the candidate over the head with a paper towel roll while trying to answer.

Re: Asana Engineering Interview Guide

#64

Post by marknutter »

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.

Re: Asana Engineering Interview Guide

#65

Post by Xyik »

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.

Re: Asana Engineering Interview Guide

#66

Post by andersen1488 »

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

Thanks for a dose of sanity. After a round of SV interviews this past week, I've vowed to never put myself through something like that ever again.

Re: Asana Engineering Interview Guide

#67

Post by [deleted] »

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…

[deleted]

Re: Asana Engineering Interview Guide

#68

Post by jacklionheart »

swanson wrote: post #17

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

Hey -- I work at Asana.

Great idea! Took a task to add more resources to learn from to the doc.

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

Hmm, the way we framed that is confusing. Thanks for the feedback! To be sure, our goal is to accurately assess what your day-to-day contributions would be like, and simulation is a really good way of eliminating accidental bias in that process. To that end, we do have every engineer submit actual code during the interview process, and we generally avoid white-board programming in favor of higher-level discussions (that may also use the whiteboard). But perfect simulation is possible (and time-consuming), so we've tried to focus on the higher order bits.

Re: Asana Engineering Interview Guide

#70

Post by jacklionheart »

marknutter wrote: post #64

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.

> I find it funny that startups only implement these ridiculous hiring practices after they start to grow

Hmm, I'm curious what you're assuming! At Asana, at least, our first hires went through many of the same questions that interviewers today go through, but we were just a lot less systematic about our evaluation and less scrupulous about accidentally testing for knowledge/context rather than ability. The intention of this guide was to make the interview /less/ bullshit-y, by giving people enough grounding to not be thrown off by unexpressed expectations.

Post reply on HN