How we screen developers in Serbia, and what you should test

My technical screening has three parts: a conversation about motivation and English, a technical interview, and a short assignment in the client's stack. That tells us whether someone can do the job. After that you interview the candidate yourself, because you are the best judge of whether that person fits your team and your codebase. You also decide who joins.

The profile comes before the candidates

Before I talk to anyone, I want to know what the developer will do for you. "Senior React developer" says very little. I ask about the stack and the versions you run, the state of the codebase and what the person needs to deliver in the first months. Someone setting up a new Next.js project needs different strengths from someone fixing bugs in an eight-year-old Laravel application.

I also ask how your team works. Do you review each other's pull requests? Is there a tech lead? Does most discussion happen in writing, or is the team in calls for a large part of the day? Those answers also decide which developer fits, apart from the stack.

First conversation: English and motivation

Our working language is English. In the first conversation I check whether someone can explain a technical problem in English and ask follow-up questions when something is unclear. Accents do not matter, but someone has to be able to say in two sentences, during a stand-up, where they are stuck.

I also ask why someone wants to work inside a client team. A developer placed with a client works in that client's tools and rhythm, and has to want that. Developers who prefer to build a product from start to finish sometimes fit better on the projects we deliver ourselves.

The technical interview

I ask the candidate to walk me through a project from the last few years, and I dig into the decisions. Why this database? What would you do differently now? What broke in production, and how did you find the cause?

The answers quickly show whether someone did the work or mostly sat next to it. Someone who knows a system well can also tell you what is wrong with it.

I always ask how someone uses AI coding tools, because our developers work with tools like Claude Code every day. I want to hear how a candidate checks the output, when they stop trusting the tool and what they do when generated code works but nobody can explain why. The team agreements around this are in my post on AI coding tools in a remote team.

A short assignment in your stack

I avoid algorithm puzzles, because they mostly measure whether someone has practised puzzles. An assignment that looks like real work tells you more. Two formats work well:

• building a small feature in the client's stack, with tests, in a few hours;
• reviewing an existing pull request that contains mistakes, such as a missing authorisation check or an N+1 query.

Candidates may use AI tools for the assignment, since they will use them on your project as well. Afterwards we go through the code together and the candidate has to explain every line. For me that conversation is the most important part of the assignment, because it shows whether someone understands what is on the screen.

What you test as the client

When a candidate has passed our screening, you know the technical basics are in place. Your interview can focus on other things. My advice is to bring your tech lead or a senior developer from your team.

Give the candidate a real ticket from your backlog and ask how they would approach it. Pay attention to the questions that come back. Good developers ask about edge cases, the existing code and what "done" means. That shows you how quickly someone picks up your domain.

You also want to know whether the candidate gets on with the people they will work with every day. We cannot judge that for you.

If you have requirements specific to your situation, such as experience in a regulated sector or with a tool your team relies on, tell us up front. We include it in our screening, so you do not have to check it yourself.

Reasons I turn candidates down

Some signals are enough for me not to put someone forward, even when the assignment went well:

• the candidate cannot explain code from their own assignment;
• the story about previous projects stays vague, even after follow-up questions;
• someone asks no questions about the work during the entire process;
• their English is too weak to explain a problem in a meeting.

The last one weighs heavily. A remote developer who cannot ask for help can be stuck for days without anyone noticing. Remotely, you often only find out when a ticket has been open far too long.

The trial period is the final test

An interview and an assignment remain a snapshot. That is why every developer starts with a two-week trial, and if it does not work out, you pay nothing. Those two weeks show what a screening cannot: how someone handles your codebase and how they respond to review.

Give real tickets during the trial, review the first pull requests thoroughly and check in after one week. Aleksa describes what a new developer needs from you in the post on the first two weeks. The full process, from profile to start date, is described under how we work.