My Interview Mistakes and What I've Learned From Them

I’ve been in the networking industry for about 11 years now and interviewed for a number of positions over the years that I didn’t end up getting and some that I did. I’ve learned a lot from them and I feel that I’m a much better interviewee now than I was at the start of my career.

This is in no way a full list of interviews that I’ve taken over the past couple of years but a couple of the interviews that stand out in my mind and what I’ve learned from them.


Interview with TAC

This first interview was for a position in Cisco TAC. I was fairly early in my career and to be honest, I probably wasn’t mature enough for this position at the time anyways. At this point in my career, I had just earned my CCNA less than 6 months before and this was for an entry position. I don’t remember too much about the specifics but what I do remember though was how damn tough it was.

The interview was as I remember is a manager and two engineers that just grilled the hell out of me. There we’re a couple of the standard “how does this technology work” questions that I remember being okay at but the bit of the interview that really stands out in my mind was a troubleshooting scenario written out on a whiteboard.

I don’t remember the exact details of the scenario but it was along the lines of “the client here can’t reach this server” and there were a number of routers between the two endpoints and one of them was performing NAT. What I didn’t really realize at the time was there wasn’t really a “right” answer but more of them gauging what my level of troubleshooting skills were by seeing what path I would take to eliminate possible issues.

I’d say something along the lines of “I would check out the routing table” and the engineer would write out the routing table right on the board! Because I was still relatively green to all of this, I just didn’t have a deep enough understanding of how all of the pieces fit together to come up with a coherent plan to troubleshoot this scenario and failed pretty miserably.

What I learned from this was that I really needed to understand how to interpret show commands and that I couldn’t rely on looking at the running-configuration to figure out my problems like I had done for simpler issues I’d ran across in the past.


Interview with a University

This interview occurred a few years after the previous interview, I had been working for Cisco for close to two years but found that I was looking for a different path in my career than I was finding at Cisco. I ended up talking with the manager of the network team at Duke University and despite me warning him that I was in fact an NC State fan, I was invited in for an interview.

While this interview could have gone a little better, it did result in me being hired on. I messed up pretty badly on a basic subnetting question that I should have nailed. What put me above some of the other candidates though was how I performed on the lab that they had set up. This was a pretty simple lab to test the practical skills of potential hires. It was a fairly simple lab that had two switches and three routers. You simply had to correct a trunking mismatch, configure a pretty simple OSPF peering and then configure BGP. It turned out that this was a pretty good way to weed out candidates without the experience they claimed to have.

What this taught me was that before every interview, I needed to review the basics because no matter what level you’re at, you can still make simple mistakes under pressure.


Tempted by Money

This interview was with a security focused professional services company which I can’t seem to remember the name of anymore. This is less of a mistake I made in the interview but more of the interview itself was a mistake.

The mistake was that I was a little blinded by the potential salary which would have been a significant raise from what I was making at the time. I was asked multiple times throughout the process why I was interested and if the work would be interesting to me. I lied. I wanted them to want me.

The problem was that while I do like some aspects of security focused work, I would have hated not doing any route/switch work. The money wouldn’t have kept me happy for very long.

The company contacted me asking to go forward, and I’m very confident I would have been offered the position. However, after quite of bit of internal conflict I sent one of the hard emails I’ve sent in my professional career. I turned down the second interview.

It wasn’t an easily packaged lesson that I learned from this experience. It was something that I learned about myself. It made me realize that I have to be honest with myself about my career path in order to be happy. Money shouldn’t dictate your career.

The good news is that a few months after turning down this position, I started interviewing for my current position that offered both fulfilling work AND the money that had tempted me before.

Ryan Harris

I’m Ryan and I’m a Senior Network Engineer for BlueAlly (formerly NetCraftsmen) in North Carolina doing routing, switching, and security. I’m very interested in IPv6 adoption, SD-Access, and Network Optimization. Multi-vendor with the majority of my work being with Cisco and Palo Alto.

Previous
Previous

Lessons Learned from a “Simple” Firewall Change

Next
Next

Testing cables from a Cisco IOS-XE Switch