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

111–120 of 152 posts

Re: Asana Engineering Interview Guide

#111

Post by so0k »

fapjacks wrote: post #103
Tiks wrote: post #35

Earlier quoted context omitted.

Have you tried this? :) https://codefights.com/bots/botasana

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

for the HTML parsing - I was able to pass all the test cases using a stack (push the tags when they open and pop them as they close). I was doing zero validation as the challenge was to take valid html. (I didn't verify that the proper tag was being closed, I knew I'd get out of bound errors due to this, but it should work for valid html)

I was using a string builder to eat the input as I had parsed it... but I got an error on submitting my result - it gave "unexpected termination" even when I had replicated the "unexpected termination" error with a custom test case and caught the error - I still got an unexpected termination error when submitting - sigh - maybe it's related to using C# for the challenge... overall not so hard though...

Re: Asana Engineering Interview Guide

#112

Post by anarazel »

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

Don't get me wrong. I don't like the way interviews are conducted much. Especially the "trying to trip up" part, and the focus on absolutely artificial problems.

But:

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

Actually, I spent a lot of time with stuff like that. And I'm certainly not alone. And a lot of the problems I deal with is where people haven't thought about algorithmic problems (complexity, constant factors like latency, cache efficiency, ...).

Now you can certainly argue that that's not the case for most SV jobs. And that you can re-train a lot of that on the job. And I'd agree to a good degree. But I think ridiculing the importance of such topics just mirrors the mistake the of the interviewing side.

Re: Asana Engineering Interview Guide

#113

Post by plinkplonk »

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…

"But a programmer with seven years of experience must prove that he or she knows what a binary tree does?"

you'd be surprised at how many programmers with seven years experience have no freakin clue what a binary tree does!

There is a reason fizzbuzz is phenomenal filter.

Re: Asana Engineering Interview Guide

#114

Post by rifung »

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

> Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever.

There are a lot of people agreeing with you so I guess I'm just the outlier here but I don't see why you would not want people to know about hashmaps/binary trees. Sure we don't normally have to implement them ourselves but I imagine most people use them all the time.

Balanced binary trees are often used to implement Maps/Sets so by knowing what the time/space complexity of operations on them you should know how they behave. Knowing them off the top of your head also makes it easy to compare them to choose the optimal data structure for whatever it is you are doing.

I agree that open source or take home assignments are great for seeing how cleanly someone can code and perhaps this is not emphasized enough with our current interview "culture" but I don't think the other extreme of completely ignoring algorithms is a good idea either.

Re: Asana Engineering Interview Guide

#115

Post by dvt »

fapjacks wrote: post #103
Tiks wrote: post #35

Earlier quoted context omitted.

Have you tried this? :) https://codefights.com/bots/botasana

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

Re: Asana Engineering Interview Guide

#116

Post by dvt »

rifung wrote: post #114
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,…

> Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. There are a lot of people agreeing with you so I guess I'm just the outlier here but I don't see why you would not want people to know about hashmaps/binary trees. Sure we don't normally have to implement them ourselves but I imagine most people use them all the time. Balanced binary trees are often used to implemen…

> Balanced binary trees are often used to implement Maps/Sets so by knowing what the time/space complexity of operations on them you should know how they behave. Knowing them off the top of your head also makes it easy to compare them to choose the optimal data structure for whatever it is you are doing.

I don't see any virtue in knowing in-depth complexity analysis of any data structure off the top of your head. Sure, it's probably important to know that random access is faster in a hash map than a linked list, but generally questions are much more algorithmically in-depth. With that said, I know many people that would disagree with me and I think they are categorically wrong. Writing code is about building robust and scalable things. This involves planning and execution. Frankly, I don't think "tricky" algorithmic interview questions address either of those two.

And whatever, obviously to get a six-figure job (as I'm sure most people in this thread have), you need to drink the Kool-aid. But I'm not going to sit here and perpetuate this nonsense. Like I said, I don't even like interviewing people because it's expected of me to find annoying little logic or algorithmic puzzles that some poor guy or girl will struggle to solve.

Re: Asana Engineering Interview Guide

#117

Post by mattmanser »

pspeter3 wrote: post #42
wdewind wrote: post #37

Earlier quoted context omitted.

> I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve What makes you think they are asking questions they know don't really relate to the sorts of problems you have to solve?

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

This generally means asking an obscure edge case which was only challenging because you can't Google it and so is a wildly inappropriate question for an interview.

Re: Asana Engineering Interview Guide

#118

Post by Rapzid »

benwaffle wrote: post #108
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…

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

Re: Asana Engineering Interview Guide

#119

Post by adrianN »

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…

If they say average case O(1), worst case O(n), hit them with them with O(log n / loglog n) with high probability from a simple balls-into-bins type argument.

Re: Asana Engineering Interview Guide

#120

Post by Aeolun »

dvt wrote: post #26
ryanSrich wrote: post #24

Earlier quoted context omitted.

On the flip side, Asana clearly indicates that they don't test candidates on day to day development. This is good, because now I know I would never work for Asana. Those interested in non-applicable CS problems would probably love Asana. Although I'm not sure how any of this relates to a pretty basic project management app.

Yeah, exactly! It's like fucking insane how these companies hype themselves up. All you are is a glorified to-do list, calm down, Asana.

It is a very, very fancy to do list though.

To be honest, it was more usable when it was just released. The simplicity was one of the strong points.

Post reply on HN