An Interesting Interview Story
We’ve been looking for a new Network Engineer for quite a while but are having no luck at all. There is plenty of talent out there, but finding a high-end Juniper guy is almost impossible around here. We’ve loosened up our requirement for Juniper experience just to get someone in for interviews. This led us to one prospect and an interesting story.
This guy’s resume was very impressive. For the last 5 years, he’s been the Network Architect at a very large company. His experiences were off the chart. Large-scale Enterprise deployments. Monster PCI environments. Years of Juniper experience. Years of Cisco experience. I had to talk to this guy, so I got a phone interview with him.
His phone interview was great. We talked about all of the different models of Juniper gear. All the different Cisco routers. Checkpoint. F5. He even had experience with the FWSM and CSM (I’m the only other guy I know who’s dealt with those modules!). This guy was dead on target with what we needed. Before I knew it, it was 2 hours later, and I had to stop the call before we went too late into the night. We hung up, and the other engineer and I huddled to talk about this guy. There was no doubt about it; it was time to get this guy in for a face-to-face. My Director and I met him for dinner the next week. He was well prepared for everything we had for him. He knew about the company. He knew about each of us. He had all the answers we wanted. All thumbs up, so we moved on to the technical lab the next week.
I told him to be prepared for a BGP and an OSPF lab that would be on both Cisco 1800s and Juniper SRX 240s. When he showed up, he had a notebook full of notes and configurations. He had his laptop full of examples and implementation notes. Wonderfully prepared this guy was, so I drew the lab on the whiteboards for him. An routed VPN tunnel with BGP between a couple routers. Some OSPF and redistribution here. Some VRF/RI there. Not very complicated, but not very easy either.
I expected him to be done in about 3 hours or so. After 20 minutes, I asked him how we was doing. He was still configuring IP addresses on interfaces. After an hour, he was still working on getting OSPF working. After two hours of struggling, I helped him get the VPN tunnel up and running. Hour four was spent working through the VRFs and leaking. I finally just called it done to give him a chance at the Juniper stuff in hopes that he was faster in Junos than IOS. Nope. At the 7 total hour mark, I finally just told him he had to go.
I was ready to hire this guy after the phone interview. My Director’s loved him after the face-to-face and actually said he was worried that this guy would be bored in our environments. The obvious moral of the story is that you have to actually challenge a potential coworkers before making a hiring decision.
And I will never think about hiring anyone without putting them through the paces.
https://masto.ai/@aconaway
- Netbox Upgrade Play-by-play - April 25, 2023
- Sending Slack Messages with Python - March 15, 2023
- Using Python Logging to Figure Out What You Did Wrong - February 26, 2023
[…] recently read Aaron Conway’s post about interviewing a candidate that seemed like a great fit for his environment, only to find out […]
So who was that man before? Perfect presales engineer?
It is strange, when you can talk about all the products in every detail, but couldn’t configure things at console? May be he had a bad day?
But yes, I agree, real world testlab helps a lot, even more, when potential hire is shy during initial interviews.
Thats the scary thing in our industry, someone on paper can look likes gods gift to us however as soon as you get them in the bull pen then you end up regretting the decision to take them onboard 🙁
Hey Aaron,
Thanks for sharing your interview experiences. The idea of a hands on lab is great, but requires a significant time investment. Do you think it would have been possible to catch the candidates hands-on skills gap earlier in the interview process? I know that configuration tasks are hard to do over the phone. However I often ask the candidate to configure OSPF on a single router, and manage to weed out a lot of candidates at this stage (especially when I get the impression they’re reading from a textbook :-).
Hey Aaron,
Great story – I’ve seen the same benefit in hiring at the company I work for – I’ve put together Windows & Linux labs and the it’s been a huge gain in discerning between a great resume & little practical skills and great resume & excellent practical skills. 3-7 hours seems really long though – in Australia, you’d be hard-pressed to expect anyone to give that much of their free-time to prove their skills. I imagine a CCNP-TSHOOT style lab that has an existing topology & some planted misconfigs would reduce the lab time & allow you to identify a less-practically-skilled candidate more quickly. And the talented candidates should fly through it.
It’d be great to hear more of your interviewing stories in the future.
Regards,
Chris
Your mistake was interviewing a Network Architect for a Network Engineer position. I am a Network Architect. My day revolves around gathering requirements (really working hard to drag requirements out of people as they generally don’t have a clue what they really need), researching solutions, digging through device manuals looking for necessary features in order to meet requirements, keeping up-to-date on developing technologies, creating BOMs, creating high-level designs in order to create a design document (like a blueprint), innovating methods in order to provide solutions, and working on proposals. I spend very little of my time actually logged into devices and when I do it is to make sure I understand the infrastructure that I’m designing for (as the documentation of existing environments is usually quite poor) or to test out new technology and new configurations in order to respond to the requirements. I must understand the necessary elements in order to validate that my design is going to work after some further problem solving and configuration by the network engineers. You wouldn’t ask a skyscraper architect to actually build a skyscraper. The architect you interviewed could step down and do engineer work. It’s not like he is incapable of doing so. It’s just that he doesn’t do engineer work on a daily basis. Basically, he has moved past the position you had open. It would have been a step down for him in challenge and compensation.
@Previous poster: I agree with much of your comment except the last part about “step down for him in challenge and compensation” I see that as a problem these days… obviously, he wasn’t up to Aaron’s challenge! Too many people pigeon hole themselves as this or that when flexibility is many times what is needed (within reason). My company recently let go of a long time employee “data architect” who probably had OK db admin skills at one time but was unwilling to do the work and stay relevant so we hired a second dba and he was gone.
@Aaron: you need a good code name for your technical lab for candidates. May I suggest Kobayashi Maru?
Ive had lab interviews which, to be frank I prefer because I do better demonstrating my skills than I come off in an interview. I think it should be the default method when ever possible.
Also Kevin has a good point because as an Architect I barely touch equipment now. Months go by but, it wouldn’t take me more than a few minutes or less to out IPs on that’s just a little much I pain my opinion.
I agree with @KevinGray.
In this scenario, there are two types of network engineers. One is doing high level architecture and deployment himself. Usually this can come from smaller company.
The other one is doing only architecture/design work and leaving the deployment area for years.
I have a CCIE colleague with 2XXX number here and doesn’t know much into detail how to configure stuff. What he knows how things work and how to put things together.
Implicitly, you won’t ask a $200 per hour engineer to do deployment work, will you?
I’ve also went to an interview and explained that I have pre-sales and deployment experience. But, surprisingly, they called it off and said that I was only a box mover 🙂
Thanks for sharing that Aaron. Kevin has a good point but depending on the scale of the org often the arch also has to double as the end of the line on trouble. Also think an architect needs to be able to develop reusable frameworks, blueprints just as a programmer develops classes, modules etc that should involve proofing in a lab with quantitative reproducible results. I have gotten to the point where I am more concerned in capacity to learn and high social IQ. We can teach most people how to juggle protocols but how to deliver services internally and externally to stakeholders and just as important (and rare in my exp) to work in teams with peers is a much harder thing to bring in.
Nice read and great comments, got me thinking. Love non-tech posts like this. Cheers.
What I dont understand is: what is an Network architect
doing applying for a Network Engineer position?
CCDE is way too different than CCIE, the first one is about the why’s and the second one about the how’s
B you and the candidate were hiring/applying the incorrec guy/job
Very interesting post, It happens a lot in our industry.
Not sure, why the person was moving from Architect position to Engineering position BUT the work scope is very different.
I started with TAC & I my current job, I deal with HLD’s. Initially, It was great pain to just create the documentation for some one else to implement. I always thought, Why dont theygive me the console & I’ll do it in xyz time 🙂
As far as I know we need to compromise at times to get someone onboard, simply because we don’t have much options.
Nice to see this Experience Sharing Post!
This scenario is unfortunately all to common and makes finding good people very challenging. Originull Networks is currently looking for two Junior and Senior Cisco Voice Engineers http://originullnetworks.com/jobs/ if anyone is interested. Telecommuting is possible.
I’m also an architect with an operations background. I don’t believe you can be completely hands on or hands off. I spend a lot of my time writing HLDs and LLDs but the majority of my time is spent in the lab actually putting designs through their paces. I think if you can’t prove something then writing about it is pointless, you need to be able to access the impact of what you are doing.