Preparing to Hire: Lessons from the Other Side of the Table

Three months into my first management role, I have yet to hire anyone. However, inevitably, I'll be responsible for bringing new network engineers onto the team.

The thing is, I've been on the other side of this table dozens of times as a contributor. I've sat in interviews, liked candidates, watched them get hired, and then discovered their actual technical skills didn't match what we saw during the process. The personable person who interviewed great, but struggled with real-world troubleshooting. The one with impressive certifications who couldn't think through complex problems systematically.

Now that I'll be making these hiring decisions myself, I'm thinking hard about what actually matters and how to avoid the common trap: hiring someone who interviews well but can't perform when it counts.

This post is about what I'll be looking for when I hire my first network engineer - informed by years of watching this process from the contributor side and thinking critically about what actually predicts success.

The Resume Screening Reality: 100+ Resumes, 10 Minutes Each

When you post a network engineering position, you're not getting 5 carefully selected candidates. You're getting 100+ resumes, and you have maybe 10 minutes per resume to make an initial decision.

What Actually Catches My Attention

Red Flags That Get Resumes Discarded Immediately:

Generic, template-driven resumes with no specific details
Job hopping with no clear career progression (6 jobs in 3 years)
Buzzword bingo without substance ("Leveraged synergies to optimize network paradigms")
Typos and poor formatting in technical documentation
Claiming expertise in every technology ever invented

Green Flags That Get You to the Next Round:

Specific technical accomplishments with measurable outcomes
Clear progression in responsibility and complexity
Evidence of continuous learning and skill development
Contributions beyond just job duties (mentoring, documentation, process improvement)
Appropriate certifications for experience level

The Resume Details That Matter

Instead of: "Responsible for network infrastructure" Write: "Managed SD-WAN migration across 45 retail locations, reducing WAN costs by 35% while improving application performance"

Instead of: "Skilled in routing protocols" Write: "Designed and implemented BGP architecture supporting 200+ store locations with multi-homed internet connectivity"

Instead of: "Certifications: CCNA, CCNP" Write: "CCNP Enterprise (2024) - implemented skills immediately in production environment for [specific project]"

The difference is specificity and impact. I'm looking for evidence that you've actually done the work, not just that you know the concepts.

If you're wondering which certifications actually matter, I covered the technical certifications landscape in detail in my network engineering certification guide

The Phone Screen: Separating Technical Knowledge from Technical Ability

Once you make it past the resume screen, the phone interview is where I start probing for real technical understanding versus memorized answers.

Questions That Reveal Technical Depth

Surface-Level Question: "Tell me about OSPF"

Better Question: "Walk me through how you'd troubleshoot OSPF neighbor relationships that won't form"

The first question gets you textbook answers. The second reveals whether someone has actually troubleshooted real problems or is just reciting theory.

Surface-Level Question: "What experience do you have with SD-WAN?"

Better Question: "Describe a challenging SD-WAN implementation you worked on. What went wrong, and how did you fix it?"

I'm listening for:

Systematic troubleshooting approach
Understanding of where to look for problems
Ability to explain technical concepts clearly
Honest acknowledgment of challenges and learning experiences

The Dead Giveaway: Question Deflection

When candidates deflect specific technical questions, it's usually a sign they don't have real experience:

Question: "Tell me about a time BGP routing went wrong. How did you troubleshoot it?"

Strong Answer: "We had asymmetric routing causing packet loss. I used traceroute from both directions, checked BGP path attributes, found one ISP was advertising more specific routes. We adjusted local preference to fix it."

Weak Answer: "BGP is complex; lots of things can go wrong. I'd start by checking configurations and working with the team to identify the issue."

The weak answer sounds reasonable but lacks specificity. It's what someone says when they've read about BGP but haven't actually troubleshot it.

The Technical Interview: Beyond Trivia Questions

Here's where I've learned the hard way that interview performance doesn't always predict job performance.

What Doesn't Work: Networking Trivia

These Questions Are Useless:

"What's the administrative distance of EIGRP?"
"How many bits in an IPv6 address?"
"What OSI layer does a router operate at?"

You can memorize these answers in a day. They tell me nothing about your ability to actually do the job.

What Actually Works: Scenario-Based Assessment

Present Real Problems: "You get a call at 2 AM - 15 stores can't process credit card transactions. Walk me through your troubleshooting approach."

I'm evaluating:

Systematic thinking vs. random guessing
Understanding of dependencies and impact
Communication during crisis situations
Knowing when to escalate vs. trying to solve everything alone

Architecture Design Questions: "We're opening 10 new retail locations. How would you approach the network design?"

I'm looking for:

Consideration of business requirements, not just technical specs
Understanding of cost vs. performance trade-offs
Questions about constraints and priorities
Scalability and future growth planning

This connects to the strategic thinking I discuss in making the business case for network modernization - technical decisions need business context.

The Practical Technical Test

This is the framework I give after seeing folks get hired based on interview skills only:

Give Them Real Configuration Scenarios:

Provide sanitized network configs with intentional issues
Ask them to identify problems and suggest fixes
Give them time to research if needed (that's what they'd do on the job)
Discuss their reasoning and approach

Example:

Here's a BGP configuration that's not working as expected. Take 15 minutes to review it, then walk me through what you'd check and why.

This reveals:

Whether they can read and understand configurations
If they have a systematic troubleshooting methodology
How they approach unknown problems
Their comfort level with actual technical work

Home Lab or Portfolio Projects: Ask about their home lab, GitHub contributions, or side projects. Someone genuinely interested in networking usually has something they're tinkering with.

The candidate who says "I built a home lab to practice SD-WAN" and can show me what they learned is infinitely more valuable than someone who just lists certs with no practical application.

Personality and Team Fit: The Overlooked Critical Factor

Technical skills can be developed. Personality issues are much harder to fix.

What I'm Looking For

Collaboration Over Hero Mentality:

Do they talk about "we" or always "I" when discussing past projects?
Can they give credit to teammates?
Do they show interest in learning from others?

Communication Skills:

Can they explain complex technical concepts clearly?
Do they listen and ask clarifying questions?
Are they comfortable saying "I don't know"?

Growth Mindset:

Do they talk about what they're learning or just what they know?
Can they discuss failures and what they learned from them?
Are they curious about technologies they haven't worked with?

Professional Maturity:

How do they talk about previous employers and colleagues?
Can they handle constructive feedback during the interview?
Do they take ownership or blame others for past problems?

Red Flags in Personality

The Know-It-All: Claims expertise in everything, never admits uncertainty. These people are unteachable and cause team friction.

The Blamer: Every problem at their previous job was someone else's fault - bad management, incompetent coworkers, unrealistic expectations.

The Lone Wolf: Only wants to work independently, dismisses the value of documentation or knowledge sharing, sees collaboration as a burden.

The Clock Watcher: Fixated on work hours, remote work policies, and what they won't do rather than focusing on the work itself.

The Fit Assessment: Will They Actually Succeed Here?

Even technically strong candidates with great personalities can be wrong for your specific environment.

Environment Match Questions

Our Reality Check Questions:

"Our retail environment means weekend and after-hours work during peak seasons. How do you feel about that?"
"We're transitioning from legacy MPLS to SD-WAN. How comfortable are you learning new technologies on the job?"
"Our team is small, so you'll wear multiple hats. Is that appealing or concerning?"

Candidates who succeed in structured enterprise environments with defined roles might struggle in a scrappy retail environment where you're doing everything from design to cable management.

The Honest Conversation

I'm learning to be more direct about what the job actually entails rather than selling a idealized version:

What I Say Now: "This role will be challenging. We're modernizing our network infrastructure while supporting daily operations. Some days you'll be designing architectures, other days you'll be troubleshooting point-of-sale connectivity at 2 AM. If that sounds frustrating rather than exciting, this might not be the right fit."

Better to lose a candidate who's not right than hire someone who'll be unhappy and leave in six months.

The Reference Check: Actually Do It Properly

I used to view reference checks as a formality. Now I understand they're critical validation.

Questions That Get Real Answers

Don't Ask: "Was this person a good employee?"

Ask: "If you had an open position, would you hire them again?"

Don't Ask: "How were their technical skills?"

Ask: "Give me an example of a complex technical problem they solved. What was their approach?"

Don't Ask: "Did they work well with others?"

Ask: "How did they handle disagreements or conflicting opinions on the team?"

The specific questions get specific answers. Generic questions get generic, useless responses.

The Back-Channel Reference

If you have contacts at the candidate's previous employers (not listed references), those conversations can be incredibly revealing. Always professional and appropriate, but often more honest. The IT world is huge, but small at the same time.

What I Wish Candidates Knew

After being on both sides of the hiring process, here's what would make candidates stand out:

Show, Don't Just Tell

Weak: "I'm experienced with network automation."

Strong: "Here's my GitHub with Python scripts I've written for network automation. This one parses configs and identifies security issues."

Weak: "I'm good at documentation."

Strong: "I created our team's troubleshooting runbook. Here's an example page showing how I structure technical documentation."

Be Honest About Experience Gaps

Bad Response: (Claiming expertise you don't have)

Good Response: "I haven't worked with that specific technology, but I'm a fast learner. Here's an example of how I recently learned [similar technology]."

I'd rather hire someone honest about gaps who shows learning ability than someone who oversells and underdelivers.

Ask Intelligent Questions

The questions candidates ask tell me whether they're seriously evaluating the opportunity or just looking for any job.

Generic Questions: "What's the salary range?" "How much PTO?" Better Questions: "What's your biggest network engineering challenge right now?" "How does the team handle knowledge sharing and learning?"

Demonstrate Cultural Awareness

Research the company and show you understand our industry and challenges:

Generic: "I'm interested in network engineering roles."

Specific: "I see you're a retail chain. I'm curious how you handle network reliability during peak shopping seasons and how that's evolved with e-commerce growth."

The Hiring Decision: Balancing Multiple Factors

After all the interviews, technical tests, and reference checks, you still have to make a decision.

My Framework

Must-Haves (Deal Breakers):

Core technical competency for the role
Clear communication skills
Professional maturity and reliability
Cultural fit with team values
Evidence of continuous learning

Nice-to-Haves (Development Opportunities):

Experience with every technology in our stack
Specific vendor certifications
Management or mentoring experience
Specialized skills like automation or security

The 80% Rule: If a candidate meets 80% of requirements, demonstrates learning ability, and fits the team culture, they're probably worth hiring. Nobody checks every box.

The Red Line: If there's a personality concern, hesitation about honesty, or fundamental technical gap, it's better to keep looking. Desperation hiring always creates bigger problems later.

What I'm Changing in My Hiring Process

Based on my recent experience, here's what I'm implementing:

More Rigorous Technical Validation:

Practical configuration review exercises
Scenario-based troubleshooting with actual outputs
Home lab or portfolio discussion
Longer technical interviews with deeper probing

Better Behavioral Assessment:

Structured questions about past challenges and failures
Team interaction scenarios
More reference checks with specific questions
Trial period expectations clearly defined

Clearer Reality Presentation:

Honest discussion of challenges and expectations
Day-in-the-life descriptions from team members
Clear communication about environment and culture
Setting realistic expectations for learning curve

For Job Seekers: How to Stand Out

If you're applying for network engineering positions, here's how to increase your chances:

1. Make Your Resume Specific and Results-Focused Show impact, not just responsibilities. Quantify accomplishments where possible.

2. Build a Portfolio of Real Work GitHub repos, home lab documentation, technical blog posts, or side projects that demonstrate actual capability.

3. Prepare Real Stories, Not Textbook Answers Have specific examples of problems you've solved, challenges you've overcome, and things you've learned.

4. Be Honest About Your Experience Level It's better to be upfront about gaps and show learning ability than to oversell and underdeliver.

5. Research the Company and Role Understand the business, the industry challenges, and how the network engineering role supports business objectives.

6. Ask Thoughtful Questions Show you're evaluating the opportunity seriously and thinking about long-term fit.

7. Follow Up Professionally Thank you notes, timely responses, and professional communication throughout the process.

The Long-Term Perspective

Hiring is one of the most important responsibilities I have as a manager. A good hire multiplies team effectiveness. A bad hire creates months of problems, impacts team morale, and wastes resources.

I'm still learning how to do this well. The gap between interview performance and job performance is real, and closing that gap requires better assessment techniques, more rigorous technical validation, and honest evaluation of both technical skills and personality fit.

The goal isn't to hire perfect candidates - they don't exist. The goal is to hire people who have the core competencies, the right attitude, and the ability to grow into the role while fitting the team culture.

After one hiring mistake, I'm determined to get better at this. Your next job interview with me will probably include configuration reviews, scenario troubleshooting, and some uncomfortable questions about past failures. But it'll also include honest conversation about what the job really entails and whether we're the right fit for each other.

Because ultimately, hiring well is about creating situations where both the person and the organization succeed.

What I Look for When Hiring Network Engineers: Beyond the Resume

Preparing to Hire: Lessons from the Other Side of the Table