One in four employer rejection decisions in the hiring processes analyzed mentions insufficient technical depth (25%). It is the most recurring recorded reason, well ahead of a mismatch in a specific technology (6%). One practical reading of this pattern is not that companies simply want resumes with more tools listed, but that they need clearer evidence of a candidate’s level, reasoning, and autonomy.

Seniority below the level sought is another leading recorded reason for interview rejection (14%). This is conceptually related to technical depth: technical skills alone do not make level visible; a candidate also needs to communicate the decisions they made with those skills. Cultural fit and communication (10%), followed by AI use (8%), are also among the more frequent categories.

This report comes from a collaboration between Nothiring and CandyCV. It highlights three recurring themes in the recorded tech interview rejections:

Your technical reasoning is not visible. Reaching a solution is not always enough: you may need to explain how you think, which alternatives you considered, and why you made each decision.
You do not demonstrate the seniority expected. When you describe tasks or projects, your autonomy, the scope of your decisions, your contribution, and the impact you created may not come through clearly.
Your communication does not make your fit for the role clear. Answers that are vague, poorly synthesized, or based on weak examples can make it harder for an employer to connect your experience to what the role needs.

Nothiring contributed operational data and direct observations from hiring processes it managed between September 2025 and June 2026:

24,407 tech candidate profiles located in Spain.
Around 2,000 reasons for not moving forward, across employer- and candidate-side taxonomies.
188 employer rejection decisions in interviews. Those 188 decisions are the basis for the main analysis below.

CandyCV analyzed these records and compared them with academic and market research to address a question that matters to many people working in tech:

Why might companies reject a professional in a job interview?

Key takeaways from CandyCV and Nothiring’s analysis of 188 employer rejection decisions in tech hiring processes in Spain, highlighting recorded reasons and practical limits for candidates.

The ten recorded reasons for rejection in the report

This is the full classification of reasons Nothiring recorded across the 188 employer rejection decisions. The percentages show the share of decisions in which each label appears. A decision can include more than one label, so the percentages must not be added up as if they represented unique candidates.

Recorded reason	Share of rejection decisions	Main reading
Insufficient technical depth	25%	The knowledge or reasoning did not reach the expected level, or did not become visible clearly enough.
No reason communicated	17%	No explanation is on record that would make the rejection easier to understand or use.
Seniority below what was sought	14%	The experience demonstrated did not cover the scope, complexity, or autonomy expected for the role.
Cultural fit	10%	This can include work-relevant signals of collaboration as well as more subjective judgments of affinity.
AI use	8%	The tool, authorship, or judgment involved in using AI to prepare for interviews or technical assessments.
On-site or remote work	7%	The company’s work model and the candidate’s accepted conditions did not align.
Business or product domain	6%	The company sought prior knowledge of the context or someone who could ramp up with a shorter learning curve.
Specific technology mismatch	6%	The required tech stack carried more weight than transferability from related technologies.
Ownership not demonstrated	5%	It was not clear which decisions and results the candidate had taken responsibility for.
English	5%	The observed English level did not match how the company expected the language to be used in the role.

The table does not describe ten personal flaws, even when a rejection feels personal. Some reasons relate to what a person knows and can demonstrate; others relate to the conditions of the role as advertised; and one specifically reflects that there is not enough information to interpret the decision. Treating them as the same thing leads to the least useful reaction: trying to fix everything at once.

Some of these signals can be practiced before an interview, especially explaining reasoning, choosing examples that show level, and making your contribution easier to follow. A good simulation can help you synthesize your experience, answer follow-up questions clearly, and notice where your reasoning is unclear or your answers sound generic. It does not resolve incompatible work arrangements, role requirements, or an unexplained rejection.

To practice the interview signals you can work on, start by understanding what makes a good AI interview simulation.

What the records suggest about tech interview rejections

The ranking shows which reasons appear most often in the tech hiring processes analyzed in Spain. It does not show how labels relate to one another within individual decisions. Taken together, the records support an editorial reading around three themes:

the signals companies use to estimate level;
the communication asymmetries built into the process;
the ways AI and work arrangements introduce new conditions of evaluation and fit.

Talent shortages do not, on their own, explain an individual rejection

The ManpowerGroup report on Spain’s technology sector says that 78% of the companies surveyed have difficulty filling vacancies. That might suggest that any candidate with the relevant technology should move forward. The Nothiring records do not support treating that market context as an explanation for a particular rejection.

A match in a specific technology appears in 6% of recorded decisions, while technical depth appears in 25%, seniority in 14%, and ownership in 5%. Those last three labels account for 44 percentage points of mentions in a multi-label classification. They do not describe the same problem, but they raise a related question: what level of judgment, autonomy, and responsibility was the company able to observe?

The tension is not only between talent supply and demand. It can also exist between someone’s career history and the limited signals a process uses to estimate whether they can do the work. That is why knowing more technologies does not necessarily compensate for a weak explanation of decisions, scope, or impact.

AI and work arrangements can affect selection in different ways

AI use appears in 8% of employer-recorded rejection decisions. In the broader base of 24,407 profiles, Nothiring recorded an AI-use signal in 10.7% of profiles and work with agents in 1.8%. These are different measures, but they suggest that AI is part of how some candidates position themselves and how some companies evaluate work.

Remote and on-site work create another kind of friction. The employer-side category of on-site or remote work appears in 7% of rejection decisions. In the candidate-side reasons for not moving forward, a different location and remote-only preferences also appear at 8% each. The presence of the factor on both sides supports an editorial reading: this may be a condition that prevents fit before or after other aspects of the work are evaluated, rather than a deficient skill.

Candidates are expected to communicate clearly, but explanations are not always recorded

In 17% of cases, no employer rejection reason was recorded. That exposes an asymmetry in the hiring process: candidates are expected to communicate well under evaluation pressure, while the company does not always leave an explanation on record that can help someone learn from the process.

This changes how a rejection should be read. Improving how you explain your experience can reduce ambiguous signals. But trying to infer why a company rejected you when it has not communicated a reason only adds anxiety and uncertainty to an already difficult process.

Demonstrating technical depth in an interview: the result matters less than how you explain it

Insufficient technical depth appears in 25% of the decisions, more than four times as often as a mismatch in a specific technology. Within this corpus, that difference is one of the report’s most useful findings. It suggests that, in the observed processes, reaching a solution was not the only issue: candidates also needed to be able to defend their process and the decisions they made.

An answer can be correct and still leave questions if it does not explain the constraints involved, an alternative that was rejected, what could fail, or how the result would be checked. The reverse can also happen: a capable person may perform worse in an exercise that measures something else, is poorly scoped, or is assessed without consistent criteria.

The meta-analysis by McDaniel et al. on employment interviews found that their ability to predict performance varies by content and degree of structure. The review by Schmidt and Hunter on selection methods placed work samples and structured interviews among the methods with stronger predictive evidence in its analysis.

The combined conclusion is not that an assessment “proves” a person’s full capability. Rather, the signal can improve when an exercise resembles the work, the company knows what it wants to observe, and the candidate makes their reasoning visible. An assessment result emerges from that interaction between capability, evidence, and process design.

How to make technical depth visible in an interview

Before the process, select two or three situations from your experience that let you reconstruct a difficult decision, an incident, or an improvement with meaningful trade-offs. For each one, prepare five elements: the problem, constraints, alternatives, decision, and later check.

During a technical exercise or conversation:

state the assumptions you are using;
prioritize the constraints that change the solution;
compare at least one relevant alternative;
distinguish what you know from what you would need to validate;
explain how you would check performance, security, maintainability, or impact;
if you used AI, identify what the tool proposed and what judgment you applied yourself.

The goal is to leave a chain of reasoning another person can follow. If you need to organize your overall interview preparation before focusing on a technical assessment, start with how to prepare for a job interview without memorizing answers.

Seniority and ownership: level shows in scope, not tenure

Seniority below the level sought appears in 14% of decisions, and ownership not demonstrated in 5%. The difference between the two reasons is useful. Seniority expresses an overall assessment of level; ownership asks whether the person took responsibility for specific decisions and consequences.

The European e-Competence Framework organizes ICT professional competence into proficiency levels and uses dimensions such as context complexity, autonomy, and influence. This helps explain why years of experience are such an incomplete indicator: two people with the same tenure may have worked with very different scope, uncertainty, and responsibility.

The useful question is not “How many years has someone worked?” but “What kinds of problems have they handled?” Signals of level appear in how you prioritize with incomplete information, coordinate dependencies, anticipate consequences, take responsibility for a decision, and change course when the evidence calls for it.

The problem with naming skills without demonstrating them

Words such as leadership, communication, or responsible for compress too much. To turn them into evidence, separate:

the team’s goal;
your decision-making scope;
the dependencies you had to coordinate;
the risk or conflict you managed;
the outcome you followed afterward;
what you would change today.

The European ESCO classification provides shared language for occupations and skills. It can help you name specific competencies, but the strongest evidence of seniority is still a case in which it is clear what changed because of your judgment, not simply that you were present on the project.

Communication and cultural fit: one category can combine two different problems

Cultural fit and communication appear as one category in 10% of decisions. Grouping them matters because it can combine a work-related signal (such as explaining a risk, listening to an objection, or coordinating a dependency) with a much more subjective preference for affinity.

The review by Levashina et al. on structured interviews shows that structuring questions, criteria, and rating scales can reduce sources of variation and make answers more comparable. Meanwhile, Rivera’s qualitative study of cultural matching observed how personal affinities could influence recruiting decisions alongside competence in US firms.

Read together, these sources support two distinctions:

Work-relevant communication can be assessed through specific behaviors.
“Fit” stops being a defensible professional criterion when it means “they are like us” or “I would have a drink with this person.”

You do not need to manufacture a different personality to fit in. Instead, bring examples of disagreement, risks, coordination, and adapting your message, and ask how the team actually works. If the company cannot translate its culture into observable decisions and behaviors, practicing a more likable answer will not solve the underlying problem.

If a specific question is your blocker, review what difficult interview questions may assess and how to answer them.

AI is now part of evaluation: using it does not replace defending your work

AI use appears in 8% of the recorded reasons. Nothiring’s observations identify evaluations in two directions:

insufficient or superficial use;
and dependence that makes authorship and a person’s own reasoning hard to assess.

That makes AI a different category from a conventional technical skill.

The OECD and the ILO analyze exposure to AI at the task level, not as a uniform property of an occupation. That perspective fits the records better: the relevant question is not whether you add “AI” to a tools list, but where it improves the result, what risk it introduces, and what judgment remains yours.

In an assessment or case exercise, traceability becomes part of the evidence. You should be able to explain:

which part you completed with the tool’s help;
what instructions or context you gave it;
which errors or proposals you rejected;
what checks you performed;
which final decision was yours;
how you would proceed if you could not use it.

The conclusion is not “always use AI” or “avoid it to prove you can work.” Use the tool when it helps, and retain the ability to review, explain, and take responsibility for the result.

Work model, domain, stack, and English: when the issue is fit, not talent

Four of the ten categories describe specific role requirements: on-site or remote work (7%), business or product domain (6%), technology (6%), and English (5%). In these cases, interpreting a rejection as a general judgment of capability can lead to the wrong conclusion.

On-site and remote work: a condition to clarify early

Remote work is a form of work organization under Spain’s Law 10/2021, not a professional competency. Clarify the work model early. If a company offers a hybrid arrangement, ask what it means in practice: how many days, from which location, with what exceptions, and whether the conditions could change.

If there is no alignment, the process may have no solution for either side. Finding that out early saves time; it is more useful than trying to demonstrate a capability the company is not questioning.

Domain and technology: transferability needs an explanation

Business domain and specific technology each appear at 6%. An exact match can be essential when the company needs someone to ramp up immediately or when the learning cost is high. In other roles, it may be a shortcut to reduce uncertainty even where transferable skills exist.

When your experience does not match exactly, listing similar tools is not enough. Explain the problem the two contexts share, the constraints you already understand, and a verifiable occasion when you learned a new domain or stack. Then ask which part of the requirement is nonnegotiable and which part can be learned.

Do not confuse “I have not used this tool” with “I cannot solve this type of problem.” Explaining that transfer of skills clearly can be practiced.

English: level only makes sense when tied to a task

English appears in 5% of decisions. “Having English” can mean reading documentation, explaining an architecture, participating in a meeting, writing to clients, or negotiating. The label tells you little unless it is connected to the role’s situation and context.

Ask for an example of how the language is used day to day and prepare in that format. Defending a technical decision in English demonstrates something different from completing a grammar test, and the company should know which of those signals it needs.

No reason communicated: the rejection you cannot learn from

At 17%, “no reason communicated” is the second most common label. Its importance is not in guessing why no explanation was recorded, but in what that absence prevents: distinguishing a one-off incompatibility from a signal that points to something you could improve.

The meta-analysis by Hausknecht, Day, and Thomas on applicant reactions, across 86 independent samples, found that a better perception of the process was associated with more favorable views of the organization and a greater stated intention to accept offers or recommend it. How a process is communicated does not only affect the candidate; it is also part of an employer’s reputation.

When the context allows, ask a question that is easy to answer: “Was there a requirement or piece of evidence I should strengthen for similar roles?” Then record what you can observe and avoid rebuilding your resume around an imagined explanation.

One process produces an anecdote. Several comparable processes may reveal a pattern. Only that pattern justifies a deeper review of your strategy.

What to prepare before your next interview

Not every rejection reason calls for the same response. Before changing your strategy, identify whether you need to demonstrate your level more clearly, explain how you work, check fit with the job posting, or wait for more information:

What may be happening	Related reasons	How to prepare
Your level is not demonstrated clearly enough	Technical depth, seniority, ownership	Practice real cases that show how you analyzed the problem, what you decided, which alternatives you rejected, what responsibility you took, and what consequences your work had.
It is unclear how you work and collaborate	Communication, cultural fit, AI use	Prepare examples of coordination, disagreement, communicating risks, and responsible AI use. Practice explaining them clearly and ask what behaviors the team actually expects.
There is a specific mismatch with the role	Work model, domain, technology, English	Confirm early which requirements are essential, which are negotiable, and which experience or skills can transfer from other contexts.
You do not have enough information to identify the issue	No reason communicated	Ask for feedback with a specific question, record what happened, and avoid changing your application until you see the same pattern across several comparable processes.

Start with two checks:

Can you clearly defend the decisions and responsibilities that best represent your level?
Do the job posting’s nonnegotiable conditions align with yours?

Then work on the specific factor the process is likely to assess. If you notice broader weaknesses while preparing those examples, review common job interview mistakes to avoid and fix first.

The conclusion is more specific: technical depth, level, and ownership need to become evidence; role requirements need to be clarified early; and a missing explanation should not automatically become a judgment of your capability.

How this report was produced

Primary source. Nothiring contributed data from enriched public profiles and operational records in a corpus whose overall window runs from September 2025 to June 2026: 24,407 tech candidate profiles located in Spain, around 2,000 reasons for not moving forward classified under two taxonomies (employer and candidate), and 188 manually coded employer rejection decisions.

Analysis. CandyCV used the 188 decisions as the report’s core, compared the presence of their recorded reasons, identified editorial relationships between level, evidence, communication, AI, and role fit, and compared each section with academic research, European frameworks, and official sources. These editorial readings are not statistical correlations across individual cases.

Scope. This is an operational sample concentrated in product companies, especially startups and scaleups, difficult-to-fill vacancies, and profiles with established experience. It does not represent every company or tech candidate in Spain. The classification is multi-label and does not include overlap between reasons or a breakdown by stage, job family, or company. That is why the report refers to recorded reasons and does not assign a definitive cause to an individual rejection.

Collaboration. Nothiring is the source of the data, taxonomies, coding, and observation of the processes. CandyCV provides the candidate-centered approach, analysis, comparison with secondary research, and editorial recommendations.