49

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

you are viewing a single comment's thread
view the rest of the comments
[-] litchralee@sh.itjust.works 4 points 1 day ago* (last edited 1 day ago)

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.

this post was submitted on 14 Sep 2026
49 points (86.6% liked)

Programming

28471 readers
176 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS