Reading an API management CV

API management is a narrow speciality in a tight market, and that produces a predictable phenomenon: the line "API management expert" turns up on far more CVs than there are experts. It is not always dishonesty. It is often a sincere confusion between "I worked on a project that had a gateway" and "I know how to run a platform".

On the CV: the words that give it away

"Policy configuration" as a headline skill is a weak signal. It is the most visible and least rare part of the job. Look for what is around it: who deployed, who monitored, who got called at night.

The absence of any operations word. Someone who has really run a platform talks spontaneously about upgrades, monitoring, incidents, certificates. An API management CV with none of those words describes an integration profile, which is a respectable job, but a different job.

The product list that runs too long. Seven gateways in five years means a short assignment on each, so configuration work. Real platform profiles usually have one or two technologies in depth, and the rest under "worked with".

The vendor vocabulary. A CV written in the exact terms of the product brochure, certifications at the top of the page, describes someone who has learned the product. The question stays open: did they learn it in production or in a training room?

The five gateways case

A CV that lines up five products on a single assignment deserves a question, not a rejection. Two explanations exist and they are not equivalent.

The good one: the assignment included a selection phase, the candidate built comparative prototypes, and they did handle all five. That is useful experience, they know what differs between the products, and they probably have a reasoned opinion on the criteria that separate them.

The bad one: all five were in the team's scope and the candidate operated one.

The question that settles it fits in one sentence: which of those five were you on call for? Followed by: what made you rule out the other four? A candidate who has run a selection answers precisely, with criteria and numbers. A candidate who has copied out a scope changes the subject.

The version question, which costs thirty seconds

The highest-yield filter in the whole interview fits into one question: which version, exactly?

An API management product is not a single thing, and generation breaks are the defining event in the life of a platform. Apigee Edge and Apigee X are two different products, with two deployment models and a migration that occupied whole teams for years. Kong 2 and Kong 3 do not have the same router. Azure API Management has its classic tiers and its v2 tiers, which do not carry the same functions.

Someone who has run the platform knows which version they were on, knows the cutover date, and has an opinion on what the migration cost. Someone who was passing through answers with the product name and stops there. No training course prepares you for that question, because the answer is a date and an unpleasant memory.

The two questions that discriminate

Pure knowledge questions do not discriminate, the answers can be learned. What discriminates is the account of experience, because it cannot be invented in detail.

"What saturated first on your platform?" A real platform always has a bottleneck known to the people who run it: backend connections, the identity provider, a persistence component. The one who held the load knows the answer, and also knows at what volume it started to show. The one who "took part in the project" has never asked themselves the question.

"How did you rotate secrets?" Gateway certificates, identity provider signing keys, consumer credentials. Rotation is where a platform breaks in silence, and it is the subject nobody covers in training. A credible answer names a mechanism, a period and at least one incident: the failed rotation is a rite of passage in this job.

That leaves the two classics, "tell me about your worst incident" and "how did a configuration change reach production". They still serve, but they have become expected, and the answers circulate. Ask them second, to check the account holds together.

The practical test, if doubt remains

Two hours on a demonstration instance are enough, provided you test at the right level. Not "write a transformation policy", too close to the tutorial. Rather: "this API answers in 4 seconds instead of 200 ms, find out why" with a cause hidden in the configuration. You watch the method: where they look first, what they measure, what they rule out.

The diagnostic method is the most transferable skill in this job, and the least fakeable in two hours.

Why this is hard from the outside

Without having run a platform, you cannot tell a good answer from a plausible one: both have the same shape and the same vocabulary. That is what this grid is for, and its full version, from the API management core to the operations block, is in the guide.