6 ms·

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

by dvt 11y ago

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, contributions. 2) Real-world take-home assignments. I've opted out of interviewing people because it's such a miserable experience. I guess I'm just not a sadist that enjoys watching some poor 22-year old squirm in his chair because he can't remember what the upper bound on the insert operation of a red-black tree is. What a joke.

ryanSrich 11y ago
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.
- dvt 11y ago
  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.
  - Aeolun 11y ago
    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.
- mpd 11y ago
  > This is good, because now I know I would never work for Asana. I've actually used their product, and I'm in the same boat as you because of it.
deleted 11y ago
[deleted]
tptacek 11y ago
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 over hash table complexity. If they believe it's O(1), argue it's worst case O(n). If they want you to say worst case O(n), argue that it's in the real world always O(1). It doesn't matter which is right, because these kinds of questions aren't about technology, they're about status signaling. Be the alpha nerd! As a bonus: interviewers are evaluating you for X-factors like "confidence". You know who never got dinged in an interview for lacking "confidence"? The person who yelled at the interviewer about hash table complexity.
- deleted 11y ago
  [deleted]
- Eratosthenes 11y ago
  Adopt an aggressive posture. Maintain eye contact and repeatedly say "amortized complexity".
  - selimthegrim 11y ago
    The Illustrated Tech Interview Survival Guide would like a word with you.
- bertr4nd 11y ago
  I assume you mean this tongue-in-cheek, but someone yelling at me in an interview is probably not going to score well on the "Do I want to work with them?" X-factor. Of course, a well-informed discussion of hash table complexity would be pretty fun to hear from a candidate. It's always great when I learn something new in an interview.
  - tptacek 11y ago
    I'm like 60% tongue in cheek, because the reality is, for every interviewer who will filter you for being too aggressive, two more will filter you for lack of confidence.
andersen1488 11y ago
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.
- sotojuan 11y ago
  I agree. I've been lucky to not have been asked any questions like these here in NYC—until now. The only reason why I am still going through it is because I really like the company and people, and they did ask me fair, on-topic questions in our first interview. But yeah, studying trees when I could be doing open source sucks.
anarazel 11y ago
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.
rifung 11y ago
> 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.
- dvt 11y ago
  > 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.
  - rifung 11y ago
    I'm not even sure we are agreeing or disagreeing anymore. I don't like tricky algorithm questions. Well that's a lie, I like them but I don't think they are appropriate for interviews. On the other hand, I don't feel like knowing the time/space complexity of data structures you would normally encounter in day to day coding to be "tricky". I wouldn't expect people to know about suffix trees or segment trees for example. > Writing code is about building robust and scalable things. This involves planning and execution. I completely agree! But I would argue that's why it's important to know your common data structures because otherwise how can you plan? I do find most interviews awful because of the time pressure which is completely unrealistic. On the other hand, if I'm looking at code my coworker wrote and ask them why they decided to use an array instead of a linked list, I would hope they have an answer.

by dvt 11y ago

ryanSrich 11y ago

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.

dvt 11y ago
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.
- Aeolun 11y ago
  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.
mpd 11y ago
> This is good, because now I know I would never work for Asana. I've actually used their product, and I'm in the same boat as you because of it.

deleted 11y ago

[deleted]

tptacek 11y ago

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 over hash table complexity. If they believe it's O(1), argue it's worst case O(n). If they want you to say worst case O(n), argue that it's in the real world always O(1). It doesn't matter which is right, because these kinds of questions aren't about technology, they're about status signaling. Be the alpha nerd! As a bonus: interviewers are evaluating you for X-factors like "confidence". You know who never got dinged in an interview for lacking "confidence"? The person who yelled at the interviewer about hash table complexity.

deleted 11y ago
[deleted]
Eratosthenes 11y ago
Adopt an aggressive posture. Maintain eye contact and repeatedly say "amortized complexity".
- selimthegrim 11y ago
  The Illustrated Tech Interview Survival Guide would like a word with you.
bertr4nd 11y ago
I assume you mean this tongue-in-cheek, but someone yelling at me in an interview is probably not going to score well on the "Do I want to work with them?" X-factor. Of course, a well-informed discussion of hash table complexity would be pretty fun to hear from a candidate. It's always great when I learn something new in an interview.
- tptacek 11y ago
  I'm like 60% tongue in cheek, because the reality is, for every interviewer who will filter you for being too aggressive, two more will filter you for lack of confidence.

andersen1488 11y ago

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.

sotojuan 11y ago
I agree. I've been lucky to not have been asked any questions like these here in NYC—until now. The only reason why I am still going through it is because I really like the company and people, and they did ask me fair, on-topic questions in our first interview. But yeah, studying trees when I could be doing open source sucks.

anarazel 11y ago

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.

rifung 11y ago

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

dvt 11y ago
> 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.
- rifung 11y ago
  I'm not even sure we are agreeing or disagreeing anymore. I don't like tricky algorithm questions. Well that's a lie, I like them but I don't think they are appropriate for interviews. On the other hand, I don't feel like knowing the time/space complexity of data structures you would normally encounter in day to day coding to be "tricky". I wouldn't expect people to know about suffix trees or segment trees for example. > Writing code is about building robust and scalable things. This involves planning and execution. I completely agree! But I would argue that's why it's important to know your common data structures because otherwise how can you plan? I do find most interviews awful because of the time pressure which is completely unrealistic. On the other hand, if I'm looking at code my coworker wrote and ask them why they decided to use an array instead of a linked list, I would hope they have an answer.