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. Stanford researchers found that employment of workers aged 22 to 25 in AI-exposed occupations is 19% below the level seen in less-exposed occupations, mostly because companies hire fewer young workers.
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 junior developers
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.
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 for hiring junior developers
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. If you want to work this way, take a look at our open positions.
