I agree with this now. I just went through some interviews and I should have practiced more leetcode, should have practiced whiteboard pseudo code and should have reviewed my big-o. With 10 years in, the skills needed to demonstrate knowledge in an interview are stale because things like big-o are internalized/intuitive and don't often come up in actual work (as something that gets discussed much as it might in an interview, YMMV).

I really resisted buffing up in my interview skills because it seems silly but I realized after the last couple that it clearly impacts the perception of those interviewing you (should have been obvious as I'm interviewing others but not all places interview the same -- we don't ask much about CS fundamentals). And that perception likely has a big impact on your compensation negotiating because you're going to get pegged lower than your ability and be less desired unless you can clearly demonstrate your knowledge.

>Your ability to solve leetcode problems fundamentally determines your job prospects

For those companies that make you do leetcode problems.

For better or for worse, 95% of the places I apply to don't make you solve problems about algorithms or data structures. It's mostly about concrete knowledge in specific languages or frameworks.

I’m using the word leetcode loosely. The broader point is that doing well on job interviews is how you get a job and thus a worthwhile skill to practice. Leetcode is just what big SF tech cos ask in their interviews.

Leetcode problems rarely come into play outside of tech hubs or quant firms. I live in Chicago and rarely encounter such problems in job interviews. And just Leetcode easies at that. They do ask you do take-home assignments, though.

And leetcode is trivial. Think reverse a linked list or something. I used to ask candidates to implement binary search correctly and I stopped because nobody could do it on a whiteboard.

It's funny: if you asked me that right now, I wouldn't be able to do it. That knowledge was in my brain at some point, but it fell out. I can, however, implement a PR quad tree[0] (which is a trie and not a tree) which allows efficient coordinate search of a 2D space since that's what I've been doing most recently. I think that's more impressive, but it's not what you asked for so I fail the interview. :3

0: https://en.wikipedia.org/wiki/Quadtree

For bonus points you can also implement an Octree.

That would be for coordinate search in 3D spaces. :D

It's fun how easy it is to program in higher dimensional spaces and how hard it is to think in them. Mathematical formalism is a superpower!

Yeah, that's how it appears it really works.

That said, the fundamental idea behind bsearch is toddler easy. It's interesting that such an apparently simple algorithm, namely start in the middle, pick left or right depending on the key, and repeat, is so challenging to code correctly.