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.
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?
this is the wrong use if llms. they cant make the call on who is a good fit for your team. i never used quiz interviews when hiring. i always asked: tell me about your last project or a project you are proud of and let there answer guide the questions. what tech are you excited about?
i think we’re talking about slightly different things, i’m not suggesting the llm should decide whether someone is a good engineer or a good fit. i wouldn’t trust that either.
the interesting part to me is putting someone in the environment they would actually work in, repo, ticket, tests, AI available and seeing how they reason through it.
do they understand what the AI gives them? question it? verify it? know where to look when it’s wrong?
the conversation afterwards can still be the most important part. the repo just gives you something concrete to have that conversation about.
ok i re-read. i see. i still never gave code based interviews. i found that people who could go i to theor projects with depth had a solid understanding.
yeah, i get that. but i think what i’m more interested in is problem navigation.
once someone joins a company, they’re not always going to be working on things they’ve already seen before or can talk about from past experience. they’ll get dropped into unfamiliar systems, weird bugs, new constraints, and have to figure out what matters.
so part of the value to me is seeing how someone behaves when they don’t already know the terrain, where they look first, what assumptions they make, how they narrow things down, and how quickly they build enough understanding to make a good decision.
i think that’s probably part of why leetcode-style interviews survived this long too. for all their flaws, they give you a problem the candidate hasn’t necessarily seen (sometimes) in that exact form and let you watch how they navigate it.