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.

https://en.wikipedia.org/wiki/Balls_into_bins

This reference from the wiki is good http://www14.in.tum.de/personen/raab/publ/balls.pdf

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.

I think you're interviewing with the wrong people, or at the wrong places. Way too many people treat interviewing as a way of demonstrating intelligence via computer science trivial pursuit. 5 minutes with Google will demolish 99% of the questions you might ask if all you care about is getting correct code on the board. The interesting part is the process and discussion the code creates, not whether or not they know the secret handshake.

That said, there are places that don't interview the way you describe. I'm equally sure there are places that do (I vividly remember my Dropbox interview). My hope has always been that Darwin's Law will apply to such places over the long run, but instead I think what actually happens is that as these organizations grow the interview process just ends up being a diluted version of the same BS, which translates into "lowering the bar." Nevermind that your bar was curvier than Lombard Street.

They did and that's the problem ;)

Make sure you're considering what the workday environment is like (something you can usually tell from the prep materials or discussions with recruiters) and acting the way you think you'd act in that environment.

In the case that all your keys have the same hash, right?

Too clever by half.

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.

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

I've actually used their product, and I'm in the same boat as you because of it.

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.

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.

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.

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.