Why a Recruiting Team Needs a CTO

See more details

Clients are used to seeing dozens of recruiters in an agency, but not a developer. A CTO next to a recruiter looks strange, at least until you experience the effect on your own hiring. It’s a technical expertise that turns a chaotic search into a clear process: fewer wasted interviews, faster offers, and more relevant candidates. And thousands of dollars saved.

In this interview, Nick Kliestov, CTO of ITExpert, shares how the idea of adding developer expertise to the recruiting team grew out of his own experience and how this role changes the speed and quality of hiring for international IT businesses.

How did this role appear in a recruiting agency?

The story began long before ITExpert. Back then, we were doing internal hiring for our own product — and quickly realized how difficult it was to find people not just by title but by specific tasks. For entrepreneurs at the MVP stage, recruiting often feels like chaos: vague requirements, random candidates, and a process that drains both the team and the business.

When we later launched the agency, that experience helped shape our approach. Under the title Java Developer, there can be dozens of completely different profiles. The recruiting company’s job is to show clients only the most relevant specialists, not spam them with CVs. 

Naturally, we came to the point where, as a developer, I could be useful beyond just writing code. We had many vacancies, all quite different. To fill them quickly and effectively, I started creating internal guides for recruiters — explaining stack nuances, alternative technologies, and how different tools connect. This eliminated unnecessary back-and-forth with clients and allowed the team to work efficiently, even when ten directions were “on fire” at once.

Did clients immediately realize the “feature”?

Honestly, at first, client reactions were mixed. Some were surprised: “Why do you need a tech person in recruiting if they don’t do interviews?” But after the first successful cases, the skepticism disappeared. Vacancies became clearer, irrelevant candidates were filtered out at the screening stage, and offers were made after 5–6 interviews instead of dozens.

Of course, at the agency, I am not only a technical expert but also a recruiting consultant. My hiring experience helps me dig deeper into each vacancy and ask the right questions — the ones that often stay out of focus. I call it an engineering approach: defining the exact problem the person should solve, identifying what really matters among dozens of lines in a CV, and finding a match with the business’s expectations.

This one works even when the role isn’t a developer but a marketer, support specialist, or designer. A typical job description is just a flat projection hiding the real dimensions of a role. The CTO helps reveal those dimensions.

What once seemed unusual has become a clear advantage, and today, clients actually expect this level of service from ITExpert.

What exactly does a developer do in a recruiting team?

Among my main tasks:

• Requirements analysis

The developer can decode a vacancy and immediately see critical nuances.

👉 For example, in QA Manual roles, job posts often mention API tests, while what’s really needed is full-scale backend testing with Linux and log analysis. Sometimes there’s no web interface at all, so traditional manual testing practices barely apply — and most candidates don’t understand what’s truly expected of them. The business ends up with downtime. A CTO can quickly identify who’s actually needed.

I also often highlight things the client forgot to mention, even though they critically affect the search. It can be a specific development platform or dependency on a particular cloud provider or database, which drastically narrows the candidate pool.

👉 A typical case: a small company with a microservices-based product in PHP or Python. They forget to mention microservices in the description, as it seems obvious to them (but only to those already on the team). In practice, database or framework experience alone isn’t enough. Those who’ve only worked with monoliths won’t fit. It’s a completely different level of requirements, both in skill set and budget. It’s crucial to highlight this at the start of the search so as not to waste the client’s time, and that’s what a CTO does.

• Technical screening

No, I don’t conduct technical interviews. That would require hands-on coding skills in far more programming languages than any sane person could handle 😉 But one engineer’s look at a CV can save dozens of interview hours.

👉 Case: DevOps vacancy. The CV looks solid — DevOps with 5 years of experience, Ansible, Terraform, CI/CD, and a cloud background. But a deeper tech screening reveals that, instead of a powerful Kubernetes stack for orchestrating hundreds of microservices, which is required for the job, the candidate used only Amazon ECS and had almost no Kubernetes experience. That’s an apparent mismatch — learning would take too long. Here, I save clients hours spent on tech interviews by sending only the most relevant candidates.

• Client сonsulting

The most interesting part begins when the client doesn’t yet know what they need. For instance, when the product is still forming and the stack hasn’t been chosen. Or when the market can no longer supply new candidates, and the requirements must be revised.

👉 One case involved a startup that wanted to build a service using modern Blazor (.NET + WebAssembly for the frontend). It sounds promising, but once you start looking at the market, the number of candidates with commercial experience is another story. We explained that the search could drag on for months, and maintenance and scalability might become serious issues. Instead, the .NET + Angular stack solved the same problems while offering a much broader talent pool to collaborate with. This saved the client both time and budget.

In such cases, the external consultant acts as an architect-level advisor, helping align product goals with market realities.

• Training and Coordinating Recruiters

Even our extensive training program (4+ months for every recruiter) doesn’t cover absolutely everything. It’s crucial to have someone who can “translate” the tech, whether it’s your team member or an external consultant with a strong IT background.

👉 Case: A Java role without Spring can look unappealing to candidates, since Spring is a mainstream and time-tested technology. But this is exactly where the client’s technical context made all the difference. In microservices, Spring Boot can cause resource-usage issues, so the company intentionally shifted to Quarkus / Micronaut. The recruiters framed this not as a drawback, but as an advantage: a chance to work with modern approaches that solve real pain points and add meaningful weight to a candidate’s experience. As a result, we attracted more talent for consideration.

In fact, the better a recruiter understands the role and brings in relevant candidates, the less money you spend. Imagine this: a position stays open for two months, and the team interviews 20 candidates (with three stages each). That alone can swallow over 100 hours of your technical specialists’ time. In financial terms, that’s up to several thousand dollars spent just on talking to candidates who weren’t the right fit. Add to that the lost revenue caused by the slowdown in development.

That’s why every feature we build is designed to improve relevance and create a smoother experience for our clients.

What surprised you personally in this work?

Probably the biggest surprise was how many things in recruiting are treated like “secret techniques,” while for a developer, they’re completely obvious. For example, understanding that certain technologies always come in pairs or that some tools are the baseline rather than an add-on. In books or courses for recruiters, these things are often presented as sacred insights — but for me, they were just everyday knowledge.

For an engineer, it’s like knowing a car has a steering wheel and pedals. In recruiting, that same knowledge can sound like a whole chapter in a training manual.

Also, recruiters are not junior developers. They don’t need to code. But many courses include way too much noise, turning learning into a chaotic mix of technical specifics. They just confuse people instead of explaining what really matters, i.e. how to communicate with candidates, understand context, and see the connections.

That’s where the desire to share comes from: to explain in simple terms what techies consider “obvious” and therefore never articulate. These slight hints help recruiters work faster, write better job descriptions, and better understand candidates. And they help businesses fill roles quicker and cheaper.

What is the biggest challenge in your role?

The hardest part is constantly keeping up with what’s happening in tech. New technologies appear and evolve so quickly that you have to update your knowledge daily — from industry news to client requests.

Fun fact: our team has a technology handbook for recruiters. During the last update, which took almost a month, some pages had to be rewritten twice because the market kept shifting.

See more details

Of course, I can’t code equally well in Go, Java, and .NET, but I do need to clearly distinguish which requirements are truly essential and which are just nice-to-have — even for rare roles like DevSecOps. And most importantly, I need to be able to explain to the client when their expectations are unrealistic and candidates with that “perfect” profile simply don’t exist.

Another challenge is to combine this with an understanding of how recruiters work and what tools they use. Candidates may skip certain details in their CV or LinkedIn profile, and job boards may not have filters for the exact tech you need. So I have to translate technical requirements into actual search criteria — otherwise the perfect candidate stays invisible. That’s something an in-house developer usually can’t do.

Often, the nuances of the role need to be translated into the right clarifying questions. For example, there is a request for backend development in C++. But is it about a server for smart things or for games? Based on the candidate’s answers, the recruiter must distinguish one from the other so as not to confuse completely different profiles. With 10+ years of experience in hiring, I have learned how to add the right questions to select specialists.

My core challenge has always been understanding the technical details while recognizing the limitations of recruiting tools. Effective results emerge precisely at the intersection of these two perspectives.