The role asks for five years of Kafka and I do not see much of it on your CV. Talk me through that.

The screen is a filter, and this is the filter working

A recruiter screen is a short call with a narrow purpose: confirm that you exist as described, that the basic logistics work, and that you are close enough to the requirements to justify an engineer's time. When a recruiter raises a gap, they are usually not trying to reject you. They have a scorecard with a must-have on it, they cannot assess technical depth themselves, and they need a sentence they can put in the notes that will convince a hiring manager to take the call.

That reframes what a good answer does. You are not defending yourself; you are writing that sentence for them. It needs to be honest enough that the engineer who reads it does not feel misled, and specific enough that it survives being repeated by somebody who does not understand the technology.

Calibrate before you argue

The instinct is to move immediately to why the gap does not matter. Do the calibration first, because a claim of transferability that comes before an honest statement of depth sounds like avoidance, and recruiters have heard it many times.

Locate yourself plainly on the scale from "I have read about it" through "I have used it in a side project", "I have used it in production but somebody else operated it", "I have operated it in production", to "I have designed with it and debugged it under load". Then say the nearest real thing you have done. The pairing of a modest, accurate self-assessment with a substantial adjacent achievement is what makes the answer credible.

An answer that fails later	An answer a recruiter can pass on
"Yes, I have plenty of Kafka experience."	"About eighteen months, as a consumer rather than as the person who ran the cluster. I have built the exactly-once handling on top of it."
"It is basically the same as any queue."	"I have four years on RabbitMQ, including redelivery and poison-message handling. Partitioning and consumer-group rebalancing are the parts I would be new to."
"I could pick it up in a week."	"I have not run it in production. I learned Postgres replication from scratch in my last role in about a month because we had to, and I would expect something similar here."
"It is not on my CV but I have used it."	"It is not on my CV because it was a small part of one project. That is worth knowing before you send me to the technical round."

Every right-hand version contains a limit the candidate volunteered. That is deliberate, and it is what makes the rest of the sentence trustworthy to whoever reads the notes.

What the recruiter can do with a clear answer that they cannot do with a vague one

Recruiters have more latitude than candidates assume. Requirement lists are frequently assembled by copying an old posting, and the number of years attached to a technology is often not the hiring manager's actual bar. A recruiter who understands exactly where you sit can go and ask, can put you forward for an adjacent opening they are also filling, or can flag that the technical interviewer should focus on the transferable ground rather than the specific tool.

None of that is possible when the answer is a confident generality. If you say you have plenty of experience, the recruiter passes you through, the technical round examines you as somebody with plenty of experience, and the round goes badly in a way that follows you: the debrief will not say the requirement was unclear, it will say the candidate overstated their background. That note is worse than a rejection at the screen, because it can close the company to you for a considerable time.

It is also worth asking one question back. How central is this to the role, and is it something the team is building on now or maintaining? The answer tells you whether the gap is genuinely fatal, and it lets you aim the rest of the call at whatever matters most.

Two ways this goes wrong

The first is the apologetic spiral. A candidate who is missing one item on a list of nine spends four minutes on it, mentions it again later, and leaves the recruiter with the impression that the gap is the defining feature of their profile. One question about a requirement is not a verdict. Answer it in two sentences, then redirect to the requirement you are strongest on, because that is the part the recruiter still has to establish and has less time for than they think.

The second is the transferable-skills essay with nothing underneath it. "The fundamentals are the same, tools are just tools" is true in the abstract and useless as evidence, and an experienced screener treats it as a signal that there is nothing concrete behind it. If you want the transfer to count, name the specific problem you solved elsewhere and the specific property it shares with the requirement — the ordering guarantee, the at-least-once delivery, the rebalancing behaviour, the backpressure. That is a claim an engineer can test, which means it is a claim worth making.

Deciding what to do about your own CV

If this question keeps arriving, treat it as feedback about the document rather than about your ability. A technology you have used substantially but buried in a paragraph is invisible to keyword screening, and adding it accurately where it belongs is not embellishment. What you should not do is add it to a skills list at a level you cannot support, because the moment that gets you is the technical round, not the screen.

Where the gap is genuine and the role's core, you are permitted to be direct about it. Saying that you are not the right candidate for the Kafka-heavy version of this role but would be for the platform side of the team is a professional thing to say, and recruiters remember the candidates who have saved them a wasted loop. That memory is worth more than one interview.

Give the recruiter one honest sentence about your depth and one concrete sentence about what transfers. An overstatement at the screen does not buy you a chance, it buys you a rejection with a note attached.