me and a friend were arguing about this and i think the part i left out before is AI
like even if you accept that leetcode was never supposed to perfectly simulate the job and is just meant to test reasoning/pattern recognition/grind or whatever, does it still work as a hiring signal today?
you now have AI that can look at a self-contained coding problem, reason through it, generate multiple approaches, optimize the brute force solution, explain the complexity, all in minutes. then you have tools like Cluely and similar stuff specifically built to sit alongside interviews
you can’t really just pretend those don’t exist
meanwhile the actual job has also changed. engineers are already using AI to write code, review code, debug things, generate tests, understand unfamiliar systems, etc.
so wouldn’t it make more sense to assess someone inside an actual codebase? give them a scoped repo, a task, maybe even an embedded AI assistant and see what they actually do with it
can they find the relevant code? understand the system? decide what needs changing? tell when the AI is wrong? make the change without breaking something else?
obviously you can still cheat and obviously i’m not saying “here’s our 10 million line production repo, you have 40 minutes”
but surely a whole codebase with context is harder to just outsource to some interview copilot than “here’s one neatly packaged algorithm problem”
so i’m genuinely curious why we’re still optimizing hiring around leetcode instead of adapting the assessment to how software engineering actually works now
IMO, Leetcode and other programming exercises are a simulacrum for assessing aptitude. The exact exercise is not the point -- though many managers might think otherwise -- but rather is the process: can a candidate methodically approach a challenge with sufficient rigor as becoming of an engineer?
I've written before about what I look for when conducting interviews, in the context of embedded software engineers. In that realm, I'm usually probing for prior experience with computer architecture in general, not necessarily in the particular framework that the job will deal in. I want to see transferrable skills, because it's kinda rare to actually find perfect candidates that already meet our final requirements. So instead, I expect candidates to be quick studies, the sort of people that can draw analogies and get an approximate answer. Everything else can reasonably be looked up in man pages and web searches.
But this might just be specific to embedded, where we do actually care about the nitty gritty compiler and assembly details, when there's only 512 KB of RAM. And to be clear, a candidate that knows bit tricks will likely do well, but if that's the only tool in their toolbox and they don't or can't understand why writing maintainable, mostly-portable code is important in a medium sized organization, then that could be a problem. In this realm, programming exercises are still a view into a mindset. Other CS fields may vary.