I have to admit I only do leetcode problems when job hunting. But I noticed when reading Building an LLM from Scratch in Rust something I wouldn’t have noticed if I wasn’t in another leetcode season of life - the “pair_counts” function in the “Training Performance” section read like a solution to a coding practice problem. I didn’t understand the code on first pass even though I could understand the concept. Rust might not be my primary language, but the pair_counts code is not THAT complex.

Divorced from their context (in this case, the contents of the ‘tokens’ data structure and how they relate to building a tokenizer) leetcode problems can seem like silly brain teasers, a more sophisticated crossword that we don’t have to worry about after the interview loop because they are solved problems. And the reason most of us even approach them has more to do with getting a job than doing well in the one you have. It’s performing competence. This doesn’t make competence and doing well on leetcode problems mutually exclusive, but it doesn’t make one a surefire signal for the other.

The irony is that understanding is the muscle leetcode problems help us build. That philosophy does nothing to increase the odds of getting me a new job in the short term, but recognizing the duality is important because I assume I will have a new job at some point, and it will be important that I understand new and different parts of the system. And even if I wind up handing the actual coding portion to an agent, it’s important that I have an idea of what a performant design looks like when making a spec and what it should look like coming out (probably not running a loop inside of a loop inside of a loop… right?).

What’s the input, what is the output and how we get from one to the other is just life. Especially the “how we get from one to the other”.