[fullsend]

Yeah it is a skill set in and of itself. To pass a modern interview in my experience you need to take a week or two on Leetcode to brush up and do a run through Cracking the Coding Interview for concepts/terminology. In my opinion this is fueled by an abundance of excellent sheep (a good book) among hires at tech companies. If you’re trained for years and years (middle, high school, and college in the US) to study for SAT style tests (cracking the coding interview is full of test taking tactics) then when you’re asked to design interviews this is stuff you gravitate to because it’s easy to reproduce and understand. An excellent sheep appears to be a high achiever but only knows how to be given hurdles and jump them, not how to identify creativity or get nuance out of an interview process that is already woefully shallow. So it’s all people who spent lots of time studying for algos and data structures class asking each other those same questions. Asking “Are you one of us?”

[strikelaserclaw]

some leetcode is good, too much is pretty much useless. There are people who study all solutions to hundreds of leetcode problems to crack the interview, while this hard work is admirable, i feel like they wasted so much time studying that than something that actually makes them a better engineer. For example, i studied Floyd's hare and tortoise algorithm for cycle detection in a linked list a couple months ago, its a beautiful algorithm but i doubt it made me even a little better as a software engineer, that is just one instance of my leetcode adventure, which after a certain point i felt like "man i learned a solution to this random problem which does not extend in a general way to increasing my knowledge and i will most likely forget the solution in a couple months anyway"

[tubby12345]

Just because you do not do the kind of work that necessitates being familiar with that solution doesn't say anything about the universe of programming jobs. Realize two things

1) many Leetcode style solutions are to problems that were at one time practical engineering problems; cycle detection infact is still relevant in cryptography.

2) novel implementations are required all the time in companies that have bandwidth for greenfield projects (ie FAANG). For example, if you search through the source of pytorch (or tensorflow) you will find implementations of the solution to https://leetcode.com/problems/merge-intervals/description/

So everyone always lamenting how useless Leetcode is, is pretty much telling on themselves re the kind of work they do.

Edit: though this isn't what you broach, people that think there's no meaningful difference between eg O(n^2) and O(nlogn) are also broadcasting to the world that they've never run code "at scale". These companies have power bills that are denominated in Bs not Ms and so improving perf by even 1% (on a critical hot path) can be worth millions to the company (and RSU refreshers to you). If you don't believe me then believe Andrei alexandrscu

https://youtu.be/ea5DiCg8HOY?t=175

>So if you shave 1% you've made your salary for 10 years alone

[sjtindell]

Yeah I don’t intend to put down leetcode or algorithms and data structures that are the foundation of the work we do. I agree there is a difference between the level of programmer who calls sort() and the level of programmer who has to implement sort() for their service. But I’ve found that these tests, although grounded in something useful like you say, have become a sort of easy out for a class of interviewers. You can tell this live - the good kind will accept mistaken syntax as long as your algorithm is right, you try to handle edge cases, etc. and the other kind I call excellent sheep will only accept one particular path because their very mentality is rote and by the book. It’s become its own entire interview metagame because of those people. Rather than for the application or the deeper knowledge it might indicate, this test is given because it’s all the interviewer knows! I like your point about the value of a 1% gain, etc.

[strikelaserclaw]

i mean, i never said it wasn't required for a programmer to know about time,space complexity and some frequently used algorithmic patterns and data structures. My lamentation was against grinding leet code (not studying leetcode mind you) but grinding it and in general against interviews that seem to raise the bar higher and higher on the kind of leetcode questions they give. For that cycle detection algorithm example, if i ever encountered it in a real world scenario, i would just google "algorithms for cycle detection in a linked list", and just study some of them.

[alfiedotwtf]

I'm blanking on the actual quote, but something along the lines in chess is the same...

"Someone with a 2300 ELO is a good player. Someone with a 2750 ELO has wasted their life"

[908B64B197]

> So it’s all people who spent lots of time studying for algos and data structures class asking each other those same questions. Asking “Are you one of us?”

In my experience, there's a point where it becomes 100% cargo-culting/rote.

The best approach is to keep the coding (it's essential to be able to write code on the whiteboard, period) and have some elements of algorithmic reasoning but focus on using those to solve a real problem.