Hiring the right network engineer is one of those decisions that quietly determines whether an infrastructure project succeeds or becomes a recurring source of problems. The job market is full of candidates and contractors who list Cisco certifications on their CVs, quote competitive day rates, and sound credible in a first conversation. Distinguishing genuine capability from a well-presented CV is where most hiring decisions go wrong.
Having delivered enterprise network projects across the UK for over five years, the same hiring mistakes come up repeatedly. Here is what actually matters when evaluating a network engineer — and the warning signs that predict problems before they happen.
Certifications Are a Filter, Not a Guarantee
Cisco’s certification structure — CCNA, then CCNP, then CCIE — is designed to validate progressively deeper technical knowledge. CCNA confirms foundational networking competence. CCNP demonstrates the ability to plan and troubleshoot enterprise-grade networks. CCIE, requiring an eight-hour hands-on lab exam with a notoriously low pass rate, represents expert-level mastery.
These certifications matter as a baseline filter. What they do not guarantee is real-world delivery experience. It is entirely possible to hold a CCNP and have limited hands-on experience delivering enterprise projects under genuine operational pressure — managing a live cutover, making a decision when something unexpected happens during a maintenance window, or navigating a client environment with poor documentation and undiscovered dependencies.
A certification confirms someone passed an exam. It does not confirm they can deliver a project. When evaluating candidates, treat the certification as the entry requirement, then spend the majority of the interview on real delivery history — specific projects, specific outcomes, specific problems encountered and how they were resolved.
Platform-Specific Experience Matters More Than General Cisco Experience
“Cisco experience” is not a single, uniform skill set. An engineer who has spent years working with traditional Catalyst switching is not automatically competent on Cisco Nexus data centre switching or Cisco ACI — these platforms operate on fundamentally different architectural models, with different configuration approaches and different failure modes.
We have seen engagements where a contractor accepted a project on a platform they had only theoretical familiarity with. The work was technically completed, but the configuration approach did not follow platform-specific best practice — creating operational risk that wasn’t apparent until the client’s internal team attempted to make changes months later and discovered the implementation didn’t match documented standards for that platform.
Before engaging anyone, ask directly: have you delivered projects on this exact platform — not “Cisco” generally, but this specific product line — before? The answer reveals far more than years of experience or certification level alone.
Rollback Procedures Are Non-Negotiable
Any engineer or contractor making changes to live production infrastructure should, as standard practice, take a configuration backup before the change and have a tested rollback procedure ready if something goes wrong.
This sounds obvious. It is not always practised. We have encountered a project where a previous contractor made configuration changes to production switching infrastructure with no backup of the prior configuration and no documented plan for reverting if the change caused a problem. When the change did cause an issue, recovery took considerably longer than it should have, and elements of the original configuration were never fully restored.
This is a question worth asking explicitly before any engagement begins: what is your standard practice for configuration backups and rollback procedures on production changes? A candidate who treats this as an obvious, non-negotiable standard is signalling real operational discipline. A candidate who hasn’t considered the question is signalling risk.
Contract vs Consultancy: Know What You’re Actually Buying
UK businesses typically engage network engineers under one of two models, and the distinction has significant implications for how a project actually gets delivered.
A contract engagement provides day-rate technical execution under the direction of an internal project manager or architect. This model works well when the organisation already has strong internal project leadership and simply needs additional hands-on technical capacity.
A consultancy engagement provides ownership of the full project lifecycle — discovery, design, planning, delivery, and documented handover. This model suits organisations without dedicated internal network design expertise, where the specialist needs to own the outcome, not just execute a task list.
A significant source of project problems stems from ambiguity here — engaging a contractor under a day-rate model while expecting them to make design decisions that were never scoped into the engagement, or engaging a consultancy and treating it as simple labour hire. Before any engagement begins, both parties should be explicitly clear about which model is being bought.
IR35 Status Should Be Determined Properly, Not Assumed
For UK organisations engaging contractors operating through their own limited company, IR35 status determines the tax treatment of the engagement — and since April 2021, medium and large private sector businesses carry the responsibility for making this determination, not the contractor.
The assessment depends on factors including the degree of control exercised over how and when the work is performed, whether the contractor has genuine autonomy over delivery methodology, and whether the contractor could substitute another engineer to deliver the work. Engagements that closely resemble employment — fixed hours, direct day-to-day supervision — are more likely to fall inside IR35. Engagements where the specialist operates with genuine independence over delivery approach are more likely to sit outside it.
Conducting a proper status determination for each engagement, rather than applying a blanket assumption, protects the engaging organisation from both tax liability and compliance risk.
The Practical Checklist
Before engaging any network engineer or consultancy in the UK, these questions separate qualified specialists from generalists with a strong CV:
What certification level do you hold, and what specific projects have you delivered using it? Have you worked on this exact platform before — not “Cisco” broadly, but this specific product line? What is your standard practice for configuration backups and rollback procedures on production changes? Are we engaging you for execution under our direction, or for full ownership of the project outcome? What does your handover documentation typically include?
The answers to these questions reveal considerably more than a CV or a day rate.
For UK businesses evaluating their options for a network engineering engagement, our detailed guide on how to hire a Cisco network engineer in the UK covers certification tiers, engagement models, IR35 considerations, and the red flags to watch for in full detail.
