What a CCIE Number Does Not Tell You

A number I have carried since 2003 sits on my business card, in my email signature, and for years it was the first line of my website. It gets me a hearing. It has never got me a job on its own. The distance between those two things is what this piece is about, because that distance is where hiring managers and candidates both waste time.

I hold CCIE #13192 in Routing and Switching (2003), Security (2005) and Service Provider (2009). I have also sat on the other side of the table: interviewing for carrier backbone teams in East Africa, for a bank building a dual-site data centre in Shanghai, and more recently for a global retail estate with several thousand sites. The pattern is consistent enough that I have stopped being polite about it.

What the lab measures, and what it cannot

The CCIE lab is a timed, closed-book exercise in building and repairing a network from a specification. You get a topology, a set of requirements and a clock. You are judged on whether the thing converges and whether it does what the requirements said. That environment is artificial in one important way: nobody files a change request, nobody calls you at 3 a.m., and no revenue depends on your decision. It is also brutally realistic in another way: the network does not care how confident you sound.

What the lab tests is real. It tests whether you can read a topology and turn it into working configuration under pressure. It tests whether you know a protocol deeply enough to predict what it will do rather than copying a template. It tests whether you debug systematically after your first hypothesis turns out to be wrong. It also tests perseverance, which is an underrated engineering trait: the difference between the engineer who stops when the lab is not converging and the one who keeps eliminating until one cause is left.

What it does not test is everything that happens after convergence. A lab does not ask what a design costs, what happens when the vendor code misbehaves in a corner case, how you roll back a change that went wrong at 2 a.m., or how you explain to a business owner why their store is offline and what you are doing about it. Those are not lab skills. They are operational skills, and they are learned by owning something that can break.

The practical consequence: the certification is a strong signal for some roles and a weak one for others. It is strong where the work is protocol mechanics under time pressure and where a partner or tender requires a certified engineer on staff. It is weaker where the job is judgement under uncertainty, because the exam cannot see judgement and does not try to.

The number is a timestamp, not a rank

CCIE #13192 is a low five-digit number. It was issued in 2003. Someone who earned number 65000 last month did well on a different exam, with a different blueprint, on different equipment, and probably with a stronger grounding in EVPN, automation and cloud connectivity than I had in 2003. The number tells you roughly when someone sat the lab. It does not tell you how good they are now, and it certainly does not rank two engineers against each other.

The same number covers all three of my tracks, which surprises people in interviews. That is how the programme works: one number per person, however many active certifications. So a number can tell you that someone has been around for two decades, and that is worth something, because longevity in this field usually implies a survivor's instinct for change control. But longevity is not the same as current depth. I have met CCIEs who had not touched a data centre fabric in ten years and were weaker on VXLAN than a CCNP who ran one daily, and I have met engineers with no certification who could read a packet capture better than most of the room.

Where the timestamp argument does not hold: in environments where the certificate is scarce, it is often the only cheap filter available. A carrier NOC hiring twenty people cannot run a two-hour design interview with each one. In that setting the number does useful work as a floor, even though it is a poor ceiling. Judge it as a filter, not as a measurement.

The tiers I actually see in interviews

After enough interviews, a rough ladder emerges. It is not a ladder of certification levels, and it has little to do with years served. It is a ladder of what a person can be trusted with.

Level	What you can observe	What it predicts	Where it stops
Configuration	Produces a working configuration from a written specification	Can execute a work order without supervision	Novel failures, design trade-offs, ambiguity
Troubleshooting	Forms hypotheses, eliminates them, documents what was ruled out	On-call competence and incident ownership	Multi-team incidents, change risk, prevention
Design	Names the failure domains and the cost of a choice before anything is built	Architecture that survives its first bad day	Execution against production and budget constraints
Ownership	Changes how the organisation changes the network	Stability measured in years, not tickets	Organisational politics and budgets, which are often the real constraint

Certification correlates reasonably well with the first two levels, weakly with the third, and almost not at all with the fourth. The reason is structural rather than personal: design judgement comes from having lived with a bad decision and being blamed for it, and ownership comes from being in the room when priorities are set. Neither is available inside a lab window. A certified engineer can still be a configuration-level engineer at forty-five, and an uncertified one can be an owner. I have worked with both.

The failure mode of this ladder is that interviewers often test the top of it with questions that only probe the bottom. Asking a candidate to recite BGP best-path order tells you they can memorise. Asking them how they would design a migration that must be reversible tells you something the lab never could.

What I ask instead, and the checks I run

I try to spend interview time on questions where the answer cannot be recited. The questions below are the ones that have been most useful to me, in the order I usually ask them.

First: describe a change you made that broke something. What was the first signal that something was wrong, and what did you do in the first ten minutes? This tests whether they have actually caused an incident, whether they admit it, and whether they have an incident discipline rather than a hero story. A candidate who says nothing has ever broken has either been very junior or is not telling me the truth.

Second: here is a topology on the whiteboard. Where are the failure domains, and what breaks when this one link goes? This tests design vocabulary. You can tell within a minute whether someone has seen a real failure domain or only read about redundancy.

Third: what would you monitor to know this was degrading before users called? This is the single best predictor of operational maturity I have found, because it forces the candidate to think in time, not just in state.

Fourth: tell me about a time you were wrong about a root cause. The answer matters less than the way it is told. Engineers who can describe their own wrong hypothesis calmly are worth more than engineers who cannot.

Fifth: show me how you would verify that this change is reversible, and who you would call if it is not. This tests change management, which is the skill that most distinguishes a network that stays up from one that does not.

None of these are free. They cost interview time and they depend on the interviewer's own judgement, which is why they do not scale to a high-volume hiring pipeline and why the certificate still exists as a cheap approximation. That is an honest limit, not a defect of the certificate.

The checks I actually run before trusting a CV:

• Treat the certificate as a floor for roles where it is scarce, and never as a ceiling.
• Read the issue year next to the track. A 2003 R&S is a different signal from a recent data centre or automation certification.
• Ask for one design story and one incident story, and listen for the failure domains and the first signal.
• Ask what the candidate refuses to do, or what they would escalate. Good engineers have boundaries and know them.
• Check whether the CV describes what the person owned or what their team did. The difference is usually visible in one sentence.
• Do not confuse interview fluency with operational reliability. The lab does not test it, and neither does a good conversation.
• If the role involves an existing network, ask what they would change first and what they would leave alone. Restraint is a design skill.
• When hiring for a senior role, make the reference check about judgement, not about knowledge. Knowledge is already on the certificate.