the more i looked into this, the more i realized this isn't really hypothetical anymore

companies like bloomberg and goldman are already experimenting with AI-assisted interviews where you're dropped into a codebase and expected to actually figure things out.

and tbh for actual engineers, that part isn't new. that's basically the job. you get a repo, you get a ticket, you find the relevant code, make the change, test it, etc.

what i'm more curious about is people who've mostly learned through AI/vibe coding and are now trying to prepare for interviews like this.

because prompting something into existence is very different from being dropped into a repo you've never seen before and having to know where to look, what to ask, whether the AI is wrong, and how to verify the change.

that's mostly what i've been building Groundwork around — unfamiliar repo, ticket, IDE, terminal, tests and an AI assistant.

Groundwork

i'm mainly trying to figure out whether this would actually be useful for interview prep though.

if you were preparing for this kind of interview, would you use something like that?

and what part would you actually want to practice?

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

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