Every engineer iSofer places with a client works inside that client’s team from the first week. They join the stand-ups, open pull requests in the client’s repositories and make architecture calls that someone else will have to live with. That only works if “senior” means something real, so we put a lot of care into how we hire. This post explains the process: what we test, how each stage works, and the signals that tell us someone is ready.
Why “senior” is hard to verify from a CV
A CV tells you where someone has been, not what they did there. “Built a RAG pipeline” can mean that the candidate designed the retrieval strategy, evaluated it and ran it in production, or that they followed a tutorial over a weekend. “Migrated to AWS” can mean leading the migration or watching it from the next desk. Years of experience are not a reliable proxy either: some engineers do the same year ten times, while others learn more in three years than most do in ten.
So we treat the CV as a list of topics to explore, not as evidence. The evidence comes from conversations and from hands-on work.
What we assess
We look at five things, and every stage touches more than one of them:
- Technical depth. Does the candidate understand why their tools behave the way they do, or only how to use them?
- Hands-on ability. Can they actually build working software, at a senior level, in a realistic setting?
- AI-tool fluency. Do they use AI assistants and frameworks effectively in their daily work, and do they know where these tools fail?
- Cloud and architecture judgement. Can they design a system that fits the problem, the budget and the team, and explain the trade-offs they made?
- Communication. Can they explain their thinking, listen, disagree constructively and work with people they have just met?
The last point matters as much as the first four. Our engineers work inside other companies’ teams, often alongside people who did not choose to bring in outside help. A brilliant engineer who cannot build trust with a new team will not succeed in that role.
Stage by stage
1. Introduction call
The first conversation is about the candidate’s story. We ask them to walk us through their experience at a high level and to pick a few moments they are proud of, or that taught them something. We listen for ownership: what they decided, what they built themselves and what they would do differently today.
This is also where we assess communication most directly. We want people who enjoy working with people. Do they explain technical work clearly to someone who was not there? How do they describe working in a team: how the work was shared, how disagreements were settled and how they got things done together? Are they curious about us and about the kind of work we do?
2. Hands-on exercise
Next, the candidate builds something. Talking about engineering and doing engineering are different skills, and this stage shows us how someone actually works: how they break down a problem, how they structure their code, how they test it, and how they use AI tools along the way.
We care about the approach as much as the result. A partial solution with clear reasoning and sensible next steps tells us more than a finished one that the candidate cannot explain.
3. Project and architecture discussion
In the third stage, the candidate takes us through a real project they were deeply involved in, and we go into depth together. We discuss the architecture, the problems they hit and how they approached them, and the cloud infrastructure it ran on.
For AI work, this is where the details come out: how a retrieval-augmented generation (RAG) system chose and chunked its sources, why they used a framework such as LangChain or decided against one, and how they traced and evaluated model behaviour with tools such as LangSmith. For cloud work, we talk about how the system was deployed, how it scaled, what it cost and what broke.
We keep asking “why”. Senior engineers can explain the alternatives they rejected and the constraints that drove each decision.
4. Offer
When a candidate has shown depth, hands-on skill, sound judgement and the ability to work well with others, we make an offer.
Senior signals in AI engineering
The candidates who stand out in AI work tend to show the same habits:
- They talk about evaluation before they talk about models. They know how they measured whether the system was good enough, and how they noticed when it got worse.
- They understand retrieval as an engineering problem: data quality, chunking, ranking and freshness, not just “we added a vector database”.
- They use frameworks such as LangChain where they help, and can explain where they got in the way.
- They treat observability as part of the system, using tracing tools such as LangSmith to understand why a model answered the way it did.
- They use AI coding assistants every day, and they review the output as critically as they would review a colleague’s code.
Senior signals in cloud and DevOps
In cloud and infrastructure work, seniority shows up as judgement:
- They choose the simplest architecture that solves the problem, and they can say what would make them change it.
- They think about cost, security and operations from the start, not after launch.
- They automate infrastructure and deployments so that the next person can understand and repeat them.
- They have operated what they built: they have been paged, debugged a production incident and changed the design because of it.
Red flags
Some signals end a process early, however strong the CV looks:
- Lack of cooperation. Engineers who dismiss other people’s ideas, or who treat questions as an attack, struggle inside a client’s team.
- Weak communication. If we cannot follow a candidate’s explanation of their own project, a client’s team will not be able to either.
- No passion for the work. We look for people who are genuinely curious about engineering and keep learning, because the tools change every few months.
- Experience that does not survive questions. When a candidate describes a project and cannot explain the architecture, the decisions behind it or their own part in it, the experience on the CV is usually thinner than it looks.
What this means for our clients
Every engineer we embed with a client has been through these stages. That is why we can ask clients to judge us by results from the first weeks rather than after a long ramp-up: the people who join their team have already shown that they can build, explain their decisions and work well with others.
Using this in your own hiring
You do not need our exact process to hire better. Three habits make the biggest difference:
- Treat the CV as a list of topics, not as evidence.
- Always include hands-on work, and pay attention to how the candidate gets to the result, not just the result.
- Spend real time on a project the candidate knows deeply, and keep asking why.
