Hiring Juniors When AI Writes the Code

In our latest junior developer hiring round, we found that the prompt trail shows how a candidate thinks better than the final code does. Infinum built the take-home assignment around Claude Code and evaluated how candidates led the AI, questioned it and made decisions. The result: better-prepared final interviews and 4 new junior hires out of 50+ applicants.

This summer, our Podgorica office selected junior software engineers, who joined in September and October. Every candidate in the take-home assignment round got a Claude seat and an OpenRouter API key for the LLM calls in their app, and we graded both their code and how they used AI to build it. With the right setup, AI makes a candidate’s thinking visible.

A lot of companies have stopped hiring juniors. The usual argument is that AI writes the code a junior used to write. We think that is a mistake, so we kept hiring juniors and changed how we run the take-home assignment. Here is how we ran the process, what we measured, and what we would do better.

After CV screening, the selection had four steps:

1

HR interview

Understanding candidate motivation and communication style.

2

Take-home assignment with AI

Understanding candidate motivation and communication style.

3

Psychological

Assessing cognitive abilities, problem-solving styles, and workplace personality fit.

4

Final interview

Presenting and discussing the reasoning behind their decisions.

This article focuses on step 2, the part we redesigned around AI.

Why we still hire juniors

AI makes writing code easy. Deciding what to build, checking what the AI produced, and owning the result stay as hard as ever. That judgment is what makes a senior engineer valuable, and it takes years of practice to build.

If the industry stops hiring juniors, it stops producing seniors. In three to five years, the market will be short of exactly the people who can direct AI well. We would rather grow them ourselves.

But the junior profile has changed. Juniors now need to work with AI from day one. Juniors who copied code without understanding it were a problem long before AI. AI makes that faster and easier, so a junior who accepts every AI suggestion without challenging it may create more noise and damage than value. So our take-home assignment tested two things: how candidates think, and how they use AI to support that thinking.

The setup: same tools for everyone

We received more than 50 applications. After screening and HR interviews, 20 candidates moved to the take-home assignment. Most take-home assignments try to keep AI out. We wanted candidates to use it, so each of them got the same toolkit:

  • A Claude seat in a dedicated workspace. We opened a separate Claude Team workspace just for the assignment, isolated from our company workspace. Every candidate logged in through a dedicated alias, and the workspace was shut down as soon as the round ended.
  • Claude Code as the mandatory development tool. Mandatory for everyone, because we wanted to compare people on the same tool, regardless of what they are used to.
  • A personal OpenRouter API key. The assignment was an AI travel agent that plans trips for a customer, so it needed its own LLM calls. Each candidate got their own key. With it they could pick any LLM they wanted, and every key had the same budget. We did not tell candidates the limit; if they ran out, we expected them to ask for more. Nobody hit it. We wanted to see who creates the most value with identical resources in the same environment.

What we tracked, and why

Candidates knew upfront what we would collect. The assignment email said AI use was expected and that we would read how they used it. We did not share how we would score it.

In short: we looked at how candidates got to the result as closely as at the result itself.

We looked at four things:

1

The prompt log

A Claude Code hook (a small script that runs automatically) in the starter repo saved every prompt to a file committed alongside the code. This showed us whether the candidate led the AI or simply followed it.

2

The commit history

Candidates sent us the full Git history, not only the final code. We could see how the solution evolved, step by step.

3

Models and usage

After submission, we exported which models each candidate used, how much, and how many requests they made. Efficient candidates spent tokens on thinking through the problem. Others spent them on trial and error.

4

A short README note

Candidates had to explain how they used AI, list what was unclear in the brief, and say what they decided for each point. This showed whether they noticed the gaps and made deliberate decisions.

The assignment had architectural and logical traps built in: choices that work in a demo and break in a real product. Claude offered a working solution for each one. The prompt logs showed the difference. Strong candidates asked why, asked for alternatives and pushed back. Weaker candidates wrote “implement it” and moved on.

Some lessons were simpler. One technically strong candidate did not submit the Git history, so we had nothing to evaluate the process on.

We also made it visible when a candidate used another AI tool on the side. Every AI-generated commit had to match prompts in the log. Hand-written code was allowed, but in separate commits, so we could see how big the manual changes were. A large one raised a fair question: why not let the AI do it?

Code that came with neither a prompt trail nor a separate manual commit was a clear signal that the candidate had worked outside the shared environment and broken the rules.

The final code shows what the AI can do; the prompt trail shows what the candidate can do.

Grading with AI, judged by humans

If we expect candidates to work with AI, we should do the same. Every submission went through the same pipeline:

1

Run it

The app had to start with a single command. If it did not, that was the first data point.

2

Models Test it like a usee

Claude opened each app in a real browser (via browser-use) and clicked through it like a user would, saving screenshots and checking the database. Fully automated.

3

Review the code and the prompt trail

A Claude-based evaluator scored each submission and cited evidence for every claim.

4

Human calibration

We also graded every submission ourselves: on top of the automation, our seniors spent four working days reviewing all 20. The final decision stayed with us.

The evaluator did part of the evaluation, but not the final one. For each candidate, it pointed out where they stood out and where they made mistakes, so we knew exactly what to focus on in the interview. The automated score and our own score together gave us the 10 finalists.

One clear signal of how fast the AI landscape advances is the difference between last year’s and this year’s application process. Last year we had fewer applications and reviewed 10 assignments in one day, with a smaller scope and lower expectations. This year we reviewed 20 assignments in four days: the scope was much bigger, our expectations were higher, and every candidate used AI far more. As a result, we got a much deeper view of how each candidate thinks, and we were far better prepared for the final interviews. We see those four days as an investment, and we expect each round to take less manual review time.

We invited the 10 strongest candidates to short final interviews, all held within three days. That is where we asked the questions AI cannot answer for them: why this design, what would break first, what did you reject, and why.

We also checked how clearly each candidate explained their work, because clear communication matters from day one, inside the team and later with clients. The final decision combined all four steps: HR interview, assignment, psychological testing, and final interview. We hired four.

Left to right: Pavle, Jovana, Ivona & Amer. Right to left: still four great hires.

What worked, what can be better

What worked

  • Everyone was using the same tools and had the same conditions.
  • Prompt histories indicated differences between candidates that were not obvious from the final code.
  • Automated testing made us more efficient, as opposed to clicking through 20 products by hand.
  • As a result, we arrived at each final interview already knowing where to dig.

What can be better

  • Next time we will add more test flows in automated testing, and every gap between Claude’s results and ours will go back into the tests and the evaluator.
  • Next time we will share upfront what good AI usage looks like to us: how they plan, how they prompt, and how they check what the AI produced.

The takeaway

In true AI fashion, the first results came fast here too. The new hires spent their first weeks on an internal project, where we already saw strong potential. Everyone who started in September also earned Anthropic’s Claude Certified Architect, Foundations certification within their first month. These are early signals. Client work comes next, with senior support.

We have always weighed soft skills as much as technical ones, and that has not changed. What is new is the extra focus on how candidates work with AI, and evidence that with the right setup, AI makes a candidate’s thinking visible.

Our main lesson: The final code shows what the AI can do; the prompt trail shows what the candidate can do.