|
Let me start with the uncomfortable part.
Your CCNA is impressive to exactly one group of people: recruiters and HR filters. It gets your résumé out of the pile and into the room. Then, somewhere around week two of the actual job, you find out the exam and the work have almost nothing to do with each other.
Certs aren’t worthless — they give you vocabulary, a mental map, and proof you can grind through something hard. But there’s a myth that if you stack enough letters after your name, you become a good engineer. You don’t. You become someone good at passing exams about being one. Those are different skills, and the gap between them is where your actual career gets built.
So you passed. You’re in. Now what?
The exam gives you the answer. The job gives you the question.
On the exam, the problem is already defined. "Given this topology, which command configures OSPF area 0?" You pick C. Clean.
Real problems show up as a Teams message at 4:47 on a Friday: "is the network slow for anyone else?" Now you have to work out what "slow" even means, whether it’s the network at all, and which of forty possible things is actually causing it. No multiple choice. Just a vague symptom, a nervous manager, and a room that assumes you know what you’re doing.
Turning a fuzzy complaint into a precise question is maybe the most valuable thing a network engineer owns. You can’t study for it. You earn it by being wrong a few times first.
The migration that looked easy on paper
Here’s the kind of thing that never shows up on an exam: a firewall migration.
On paper it’s simple. You’ve got the old firewall’s ruleset, you’ve got the new platform, you translate the rules across, cut over, done. The exam-shaped version of your brain says this is a translation exercise. A weekend, tops.
Then you actually open the old ruleset. There are hundreds of rules. Dozens of them haven’t matched a packet in years, but nobody knows which ones are safe to drop, because nobody knows what they were for. Some rules shadow others — the traffic never even reaches them. A handful say things like temp – remove after project and are dated three years ago. And exactly none of it is documented.
So the real job turns out not to be translation at all. It’s archaeology. You have to figure out what’s actually in use, what’s dead weight, what’s load-bearing and undocumented, and what will quietly break at 9 AM Monday if you drop the wrong line. The command syntax on the new box is the easy 10%. The other 90% is judgment nobody can certify you for — and you only build it by having migrated something before and gotten surprised.
The thing that’s broken on purpose
Another one. You’re bringing up access to a new device and it just refuses your connection. Flat out. Looks broken. Feels broken.
It’s not broken. It’s a security control doing exactly its job — you’re coming from somewhere it wasn’t told to trust. And here’s the twist the exam never mentions: the source it sees isn’t always the source you think you’re coming from. Traffic can be routed out an interface you didn’t expect, so the device sees a different address than the one you’d add to the allow-list. Your "obvious" fix fails, because you fixed it for the wrong address.
The certified answer is "check the access rules." The real answer is understanding that a device sees the world from its own vantage point, not yours — a lesson that only sticks after it’s cost you an hour of staring at a config that looked completely correct.
"It works" is the most dangerous phrase you’ll say
Here’s a phrase that should make your neck prickle: "it works."
A green engineer configures something, tests it once, sees traffic flow, closes the ticket. Nine times out of ten that’s fine. The tenth time ends badly — because "it works" and "it works under every condition it’ll actually face" are wildly different claims. The config that’s fine on a quiet Tuesday falls apart the moment the primary link drops, or traffic doubles at month-end, or someone three time zones away makes a change you never heard about.
The exam rewards "it works" — right output, points, move on. The real world punishes it. The engineers who grow fast develop a nagging voice that asks "okay, but what happens when this breaks?" — before it breaks. They test the failover instead of assuming it. That instinct isn’t taught. It’s scar tissue.
And the classic version: the "redundant" pair nobody ever tested. Two firewalls, two of everything, bulletproof on the diagram. Then one dies for real and the partner doesn’t take over — because they shared a power feed, or the standby’s config had drifted months ago, or the failover was assumed, never configured. A cert teaches you how to configure HA. It doesn’t give you the reflex that says a backup you’ve never tested isn’t a backup, it’s a rumor. You get that reflex the expensive way, once.
What actually separates the seniors
Spend time around good engineers and you notice the difference has almost nothing to do with what’s on their wall. Half the time the senior is Googling the exact syntax the junior just memorized. It’s deeper than that:
They know where to look first — not from a memorized flowchart, but from having seen a thousand problems. They start at the bottom of the stack, because the boring physical stuff fails more often than the clever protocol stuff.
They stay calm when it’s on fire. Everyone else gets louder; they get quieter. That composure is worth more than any protocol knowledge, and it only comes from having been in the fire before.
They can explain why. Not that a config works — why it’s built that way, and what it trades off. If you can only recite that something functions but can’t explain the reasoning or the tradeoff, you memorized it, you don’t understand it yet.
They see the time bomb in a working setup. Anything can "run." The senior looks at a healthy-looking config and spots the single point of failure, or the thing that’ll bite in eighteen months. No exam simulates eighteen months of consequences.
So what do you actually do?
Minus the motivational-poster stuff:
Break things on purpose, where it’s safe. Build a lab, blow it up, pull the cable mid-failover, watch how things fail. You want the first time you see a failure mode to be somewhere free, not in production.
Chase the boring layers. Physical, cabling, power, DNS, DHCP, NTP — they cause more outages than the exciting protocols. The exam over-weights the fun stuff; reality doesn’t.
Ask "why" about things that already work. Why was it built this way? What was the alternative? What does it trade off? Every answer becomes pattern recognition later.
When something breaks, understand it, don’t just fix it. Fixing without understanding keeps you junior forever. Treat every incident as a lesson you’re being paid to learn.
Get comfortable being wrong. You will be, constantly, at first. The ones who grow don’t take it personally. The ones who stall are too proud to be beginners.
The bottom line
The certificate says you learned the theory. Genuinely — that’s real, and it opened a door most people never get through.
But the door isn’t the room. Everything that makes you good at this job is on the other side of it, and none of it comes with a passing score. It comes from the 4:47 Friday outage. From the "simple" migration that turned into archaeology. From the connection that was refused on purpose. From the failover that wasn’t. From being confidently, embarrassingly wrong and showing up the next day anyway.
Certs get you in. Getting burned — carefully, and learning every time — makes you an engineer. Nobody can hand you that part.
And that’s the good news: the thing that makes you valuable can’t be bought or crammed over a weekend. It’s yours. You build it one bad Friday at a time.
Read my articles on DEV.to