X5 Tech adds AI skills check to developer interviews

X5 Tech has built an AI skills check into its technical interviews and stopped pretending that developers work without such tools. The company wants to see not a sterile solution to a task but the real process: how the candidate uses the model, checks it and takes responsibility for the result.

How X5 is changing the interview

The pilot is already running for senior Python developers and QA engineers. At the screening stage, candidates are told that the interview will include a separate AI block. The company provides the tool itself, so candidates don't need to bring their own stack or subscriptions.

During the session, the candidate shares their screen and solves a task together with the model. For interviewers, the final answer matters less than the trajectory of thinking: how quickly the person formulates a request, clarifies the inputs, spots weak points and changes approach if the model drifts off course.

The logic is simple: if engineers use AI in their daily work anyway, it makes no sense to ban it in an interview. X5 Tech says outright that it does not expect the image of a "developer from the past" who keeps everything in their head and on principle works without assistants. At the same time, limited AI experience is not counted as an automatic minus. If a candidate is strong in core engineering, the company is ready to hire them and bring them up to speed on tools, guides and internal courses once they join.

What now counts as a strong signal

Interviewers look not at the mere fact of using AI but at the quality of the work with it. A candidate may be asked which tools they use and what they understand by context window, tokens, model temperature, the agentic approach and MCP. Another type of task is to hand over a file such as CLAUDE.md or .cursorrules and ask whether it will help an agent, where it is ambiguous, where it contains excess context and potential triggers for hallucinations. In other words, what is tested is no longer memory but engineering thinking around AI.

• which AI tools the person actually uses and in which scenarios
• whether they can write prompts with a role, context and expected response format
• whether they understand model limitations, including hallucinations and context size
• whether they notice security risks and avoid sending secrets to public services
• whether they can critically review AI-generated code rather than simply paste it into a project

For juniors, the bar is for now basic: they need to understand the fundamentals of prompt engineering, recognize hallucinations and not confuse quickly generated code with real understanding of a system. In its article, X5 Tech separately highlights the problem of AI dependence among beginner developers: they assemble a solution faster but are worse at explaining why it works, how to debug it and where its limits lie. So a good signal is not a set of random pet projects but a few carefully documented works with a README, the author's role, the decisions made and an explanation of where the model's advice had to be rejected.

"Whoever merged the code is responsible for it."

Requirements are higher for mids and seniors. A mid-level developer should already be able to build their own AI workflow, check plausible but wrong answers and catch errors in complex business logic, large codebases, production incidents and security questions. A senior is responsible for the next level: how to build agents and code generation into the team process without growing tech debt. What matters here are rules for using the tools, tuning context to the project, review of AI-generated code and a clear division of responsibility, because the phrase "the model suggested it" doesn't work in production.

What this means

X5 Tech's approach shows a shift in hiring: the market increasingly tests not the ability to work "in a vacuum" but how an engineer acts alongside AI. Such tools speed up strong specialists, while weak ones expose gaps in understanding, architecture and accountability faster. For candidates the takeaway is direct: it is not enough to simply use models; you must be able to explain your process, the limits and the decisions you keep for yourself.