Asana Engineering Interview Guide • Hacker News Board

Re: Asana Engineering Interview Guide

#121

Post by Aeolun » Tue, Mar 29, 2016, 8:53 AM UTC

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.

Just the fact that you've built (worked on?) apps that generated millions of revenue is not a measure of compatibility/competence, nor is experience.

Might be different if they actually said they didn't want you because of a lack of CompSci degree though.

Re: Asana Engineering Interview Guide

#122

Post by golergka » Tue, Mar 29, 2016, 9:30 AM UTC

Why does everyone love algorithms and data structures of all the CS topics so much? I would like to be asked about covariance and contravariance, LALR parsing or some basic statistics for once.

But more importantly, I would love to be asked about CS topics that arise every day in development: code organization. How many times do you get a new requirement that makes you throw all previous assumptions (that an architecture was naively built upon) out of the window? When it turns out that module A and B, which were completely different and didn't even know about each other, now need each other's data? Yes, this situation arises when original architecture wasn't thought through enough — and we all were guilty of this at one point or another.

Now, what a developer does in that situation is much more important than whether he remembers what complexity what kind of hash table (with all the chaining and hashing types) is. Does he just hack it so it works, creating a lot of fun for future maintainer? Does he decide to spend 2 days to refactor the whole system into a new architecture? Or does he find a balance somewhere in between?

Re: Asana Engineering Interview Guide

#123

Post by thaumasiotes » Tue, Mar 29, 2016, 9:30 AM UTC

Rapzid wrote: post #118

benwaffle wrote: post #108

Earlier quoted context omitted.

>If they believe it's O(1), argue it's worst case O(n) In the case that all your keys have the same hash, right?

It seems to me this would entirely depend on the implementation and how collisions are handled.

Buckets. :)

Re: Asana Engineering Interview Guide

#124

Post by clentaminator » Tue, Mar 29, 2016, 9:40 AM UTC

dvt wrote: post #115

fapjacks wrote: post #103

Earlier quoted context omitted.

I like how they slip in "Oh, all you have to do is parse HTML with regex" on the last problem.

God, I really hope they grasp the stupidity of using regular expressions to parse an irregular language. Implementing a very simple HTML parser takes at least a half-dozen man hours; seeing that question honestly makes Asana seem like amateur hour, and I've had to do some pretty stupid shit in my time. Snapchat, for example, had me solve Sudoku (???).

I'm assuming it's a reference to http://stackoverflow.com/a/1732454

Re: Asana Engineering Interview Guide

#125

Post by [deleted] » Tue, Mar 29, 2016, 9:41 AM UTC

dvt wrote: post #115

fapjacks wrote: post #103

Earlier quoted context omitted.

I like how they slip in "Oh, all you have to do is parse HTML with regex" on the last problem.

God, I really hope they grasp the stupidity of using regular expressions to parse an irregular language. Implementing a very simple HTML parser takes at least a half-dozen man hours; seeing that question honestly makes Asana seem like amateur hour, and I've had to do some pretty stupid shit in my time. Snapchat, for example, had me solve Sudoku (???).

[deleted]

Re: Asana Engineering Interview Guide

#126

Post by vain » Tue, Mar 29, 2016, 9:42 AM UTC

Their subscription pop up at the bottom of the page with a close button that does nothing only makes me sure I don't want to work for them.

Re: Asana Engineering Interview Guide

#127

Post by sorokod » Tue, Mar 29, 2016, 9:44 AM UTC

Rapzid wrote: post #118

benwaffle wrote: post #108

Earlier quoted context omitted.

>If they believe it's O(1), argue it's worst case O(n) In the case that all your keys have the same hash, right?

It seems to me this would entirely depend on the implementation and how collisions are handled.

In Java 8, collisions in Maps are stored in a tree structure so worst case is O(log n)

Re: Asana Engineering Interview Guide

#128

Post by zeemonkee3 » Tue, Mar 29, 2016, 9:54 AM UTC

markbnj wrote: post #104

viraptor wrote: post #93

Earlier quoted context omitted.

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.

>> Anyone can be a programmer. Anyone can be a doctor or lawyer too. I know what you mean, I think, but I don't know if I buy the distinction. There is a formal pass-the-bar testing event for lawyers. For nurses and I believe doctors there are boards. Same basic purpose AFAIK. They take these tests when they are just entering the profession. How meaningful are they years later, compared with the experience gained in…

Doctors, nurses and lawyers often have to think quickly, on the spot, in life or death (or at least life-altering) situations.

A developer (in a non-pathological work environment) has time to discuss and research a solution.

FWIW I don't remember the last time I had to implement a binary tree since my C++ course in college; I'm not a fan of pop quizzes in interviews, but if you're going to do them then at least make it relevant to the work you do on a daily basis.

Re: Asana Engineering Interview Guide

#129

Post by srcmap » Tue, Mar 29, 2016, 9:54 AM UTC

pspeter3 wrote: post #47

JonoBB wrote: post #39

Earlier quoted context omitted.

Yes! Honestly, they need to hire someone to fix the start up time of their app, because it's the slowest by far of any webapp that I use. That should be their first hiring priority.

It is one of our biggest hiring priorities and we are actively working on this.

Why not ask questions or ask for solution about that in the hiring and interviewer process? You might just find folks who love/know how to solved that kind of problems to work for you.

BTW, that is very trivial problem to solve for those who has done it.

Re: Asana Engineering Interview Guide

#130

Post by hkmurakami » Tue, Mar 29, 2016, 10:19 AM UTC

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…

> 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!"

That's exactly how the top management consulting firms operate their recruiting process. McKinsey even has a webinar for how to prepare for their interview and exactly what category of questions will be asked. The webinar is run by current associates.

Their recruiting works pretty darn well.