Avoiding Leetcode Anxiety

For example, some LeetCode questions are textbook problems. You really should familiarize yourself with them, but you will probably never see them verbatim on an interview. Other LeetCode questions are too tedious or time-consuming to do on a whiteboard in an hour. You will also not see them on an interview. For some people they can be fun brain-teasers, but if what you want from LeetCode is time-efficient prep material, you need to be able to tell apart these three kinds of questions.

If you look at comments on LeetCode questions, you will immediately discover that tons of people treat LeetCode as a pissing contest for its own sake. Should it matter that your solution runs in 18 milliseconds and theirs runs in 15? Or that they code-golfed theirs into 200 characters? Probably not. On the other hand, most canonical problems do have canonical solutions, and you should probably know what they are.

Knowing what to take from LeetCode and what to leave is almost its own discipline.

Computer Science can be quite fascinating and can involve considering fancy data structures/algorithms, applications of linear algebra in terms of computer graphics / computer visions, machine learning or AI.. or stuff like how a compiler or a search engine works.

But I'd say moving from System Administration to DevOps, it's more important to know software development skills (like using version control software, or how to achieve the things you'd do as a sysadmin using a programming languague) than it is to know about algorithms for balancing a binary search tree, or to crank out leetcode problems.

Frankly, I'm sick of leetcode, and I feel like it takes a lot of fun out of working in tech to have to grind this skill that's completely unrelated to any sort of real work. (Rant mode off)

Anybody know of such a list?

Edit: I should add that I'd really like to be pointed toward companies that use a structured interview process. Literally fewer than 1 in 10 SF tech companies seems to have any idea what they're doing when it comes to interviewing, and a structured interview process goes a long way toward fixing that deficiency.

I'm familiar with the "hiring without whiteboards" list, and that does't seem to be quite what I'm looking for.

Both require you to be disciplined and dedicate time on a daily basis, otherwise you won’t get further.

Having the time to address this is absolute luxury to me. Only when I became relatively rich (I‘m coming from a poor background) could I consider learning Leetcode problems. Before that point, I was learning whatever earns me survival money.

LeetCode seems to have become accepted by candidates as a way to do (1), leaving the interviewer more time for (2).

At least, that how I assume people think it works. In reality, hiring is just hard, and if you lean too hard on shortcuts like LeetCode, you come across as lazy, and you end up hiring LeetCode assholes who you catch doing LeetCode during work hours "to stay sharp". One of the most useless team members I ever worked with was good at code challenges but terrible at real work because he didn't care. He wasn't invested in working on the actual problems we faced as a company or as a team.

When we had an opening for an infrastructure engineer I created a handful of gitlab projects (terraform, puppet, python) and put some effort into building some baseline infrastructure. I allowed the candidate to choose one to work on, and then gave them a real world challenge. Not some tricksy bullshit to catch them out, just a realistic task they might encounter. They were given access to an environment where they could run the code. So at the end, I had a runnable merge request to review. Why? Because, to me, the purpose of a code challenge isn't to find the top 10%, it's to weed out the bullshitters. The rest is about figuring out what makes them tick, whether or not they're a good personality fit etc.