Junior interviews don't test what they used to, and nobody updated you

You're in a loop for a role with "junior" or "entry-level" somewhere in the title, and the interviewer just asked you to walk through how you'd design something, then pushed back on your first answer, then asked what would make you change your mind. You came in ready to explain a for-loop and got cross-examined like you're six years into this. You leave thinking you bombed it, or that you're underqualified for a job that was supposed to be the easy one.

You didn't bomb it. The job changed underneath the title, and nobody sent out a memo.

For a long time, "junior engineer" meant a specific, boring, valuable thing: you wrote the CRUD endpoint, you scaffolded the test file, you fixed the bug where the date was off by one, you wrote the first draft of the documentation nobody else wanted to write. It wasn't glamorous. It was also real work that needed doing, and doing it badly for a year or two was how you learned to do it well — with someone more senior checking your output line by line, which was its own kind of training you didn't even notice was training.

Here's the uncomfortable part: that specific list of tasks is almost exactly what AI tooling now does fastest and cheapest. Boilerplate, scaffolding, first-pass tests, routine fixes, a documentation draft — a senior engineer with a model open in another tab can produce all of that themselves, in less time than it takes to explain it to a new hire. So the tasks that used to justify a junior headcount got absorbed upward, into the senior engineer's own workflow. What's left, the part that didn't get absorbed, is judgment — noticing when the obvious approach is wrong, knowing when to stop and ask, catching your own mistake before it ships. That was never really the "junior" part of the job. It was the part you were supposed to grow into over a few years, with somebody checking your work the whole time.

That's the piece that broke. Companies still post junior roles. Some of them still mean it. But a lot of the loops are quietly testing for the leftover part — judgment — because that's the only part of the old job description that's still worth a human doing it. Nobody rewrote the posting to say that, because nobody's entirely sure how to word it yet. So you walk in prepared for the old test and get asked the new one.

Not the right answer. They're listening for whether you can catch yourself.

When they ask you to walk through an approach, don't just state the answer — narrate the decision. "Here's what I'd try first, and here's the thing that would make me stop and try something else instead." That one sentence does more work than a correct solution delivered with no visible thinking, because it shows you have a way of checking your own output. That's the skill that used to get built by someone else checking it for you. Showing you already do some of that yourself is the whole signal.

When you genuinely don't know something — and in a junior loop you will hit one of these — say it plainly and show the next step: "I don't know that off the top of my head. I'd start by checking X, and if that didn't explain it I'd go look at Y." That's not a weaker answer than a guess. A confident wrong guess is the single worst thing you can do in this kind of loop right now, because it reads as exactly the failure mode they're trying to screen out: someone who needs a person standing over them to catch the thing they didn't know they didn't know.

And when they ask about a time something went wrong — even a small, practice-project, nothing-at-stake kind of wrong — give them the moment you noticed, not just the fix. "I noticed the numbers looked off before I'd even run the test, because they were too round" tells them something a fixed bug alone doesn't: that you were paying attention to your own work, not just producing it and moving on.

Some loops now ask the blunt version directly: why bring on someone junior at all, when the senior engineers already have the tooling to move fast on their own? Don't argue with the premise — it's half true. The honest answer is closer to: "Because someone still has to be the person who eventually doesn't need the tooling checked, and that only happens by doing the work now, badly at first, with someone watching." You're not claiming to be faster than the alternative. You're naming the thing you're actually there to become, which is a different pitch than the one the posting was written for a few years ago.

Push this too far and you walk in performing total self-sufficiency — no hesitation, no "I'd want a second opinion on this," every answer delivered like you've never needed help. That's not what judgment looks like either. Judgment includes knowing the edge of what you know, and an interviewer who's actually any good can tell the difference between someone who's thought it through and someone who's just not admitting to any gaps. The honest "here's where I'd want someone more experienced to sanity-check me" is not a weaker answer. For a role with "junior" in the title, it's often the correct one — it shows you know the limit exists, which is most of the judgment they're testing for in the first place.

If you are genuinely new to this — no internship, no bootcamp project that shipped to real users, nothing — this bar is not fair to you yet, and pretending otherwise would be a lie dressed up as encouragement. Judgment about when to double-check your own work is something people build through reps, and if the industry quietly moved the goalposts on how many reps you're owed before you're expected to have it, that's not a gap in you. It's a gap in how the pipeline was supposed to work. You can still show up and demonstrate the small amount of judgment you do have — plenty of people have some, built from school, from side projects, from just paying close attention — but if you don't get the offer, it is worth knowing the test itself shifted, and not every company re-leveled their expectations to match. Some of what happens next is you finding the ones that did. And some of it, like most hiring, is luck and timing you don't control — who else applied that week, whether the team had budget that quarter, whether the interviewer had a good morning. Naming that doesn't mean the preparation doesn't matter. It means the preparation isn't the whole story, and you shouldn't carry the parts that aren't yours to carry.

Before your next interview, pick one technical decision from something you've actually built — a side project, a class assignment, anything — and practice saying it out loud, start to finish, including the part where you'd check yourself: what you'd try first, and the specific thing that would make you stop and reconsider. Say it to your phone, play it back. You're not rehearsing the answer. You're rehearsing the sentence that shows you'd catch your own mistake, because that's the sentence the room is actually listening for now.

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected:

🤝 Want to make something with us? Write a piece, come on the podcast, or bring an idea that should exist — bestpractic.org/collaborate.

And if this one helped, send it to the person you know who needs it this week. That's what keeps these coming.