In a recent set of email exchanges with a client, we were tackling the challenges of hiring engineers and technical staff.  I can summarize the most interesting issues as follows:interview

  • How do you deal with the "I want to be involved in a cutting edge, startup environment?"
  • What constitutes valid experience?
  • How do you ensure secrets will be kept?
  • How can you tell if the motivations in the potential hire are in line with the corporate/project need and objectives?

Deliberately, we have not listed the normal hiring checklist items.

The answer to the first question can be summarized in a single word as attitude.  Every engineer dreams of inventing, or being part of a team that creates the cool next generation technology, like a sports athlete dreams of winning a world championship.  The primary difference is that not all engineers seek the glory or public recognition, but many, if not most, want the riches that accompny that type of shooting star success.  Just like is sports, these things definitely happen in technology.  It is a fat carrot.  From my experience, this is the attitude that fosters the desire to be in a startup and reach for the riches of success.  The challenge in the interview process is to determine how much that attitude will help to acheive the project or corporate goals, or how much will be a detrement due to dissatisfaction and early departure.  I personally have often passed on great engineers who I could tell were over the moon with this desire, and I could feel that it would be a detrement to the team.  The ironic and funny thing about this start-up mentallity is that if you have ever worked at a true start-up, you know that first there is no glory, especially in the early development cycles - long hours, total consumption of time and focus, doing things no job description could ever cover - mopping floors and cleaning bathrooms.  I don't know how many eager engineers would trully be willing to do this.  Just research the early days of Google as a prime example.  The hiring manager has to have a conversation about the candidates thoughts, looking for a measure of attitude, not so much Q&A.  

The second question about experience is an important one.  Some managers consider the 10,000 Hour Rule when measuring experience.  If you think the 10,000 hour rule is valid, that means that you need 5 years (10,000/40 hrs/wk divided by 50 weeks in a year) to master a particular craft.  The word master is an important one.  Naturally there are nay-sayers to this rule.  In these types of gray areas I like to apply the 80-20 rule - so let's say that the 10,000 hour rule is off by 20%, that would make it - at best - 8,000 hour rule or 4 years.  Now I think I may have a general measurement stick.  So against this measurement stick I would expect that valid, meaningful prior experience has to be in the rage of 4 years at a given job function.  Accepting less than that amount of time has to be considered against the requirements of the current job.  Said another way, when someone has changed jobs 3 or 4 times in 4 or 6 years, it would be very difficult to constitute that significant experience and mastery of the skills listed in their resumes had actually occurred. Further, with the wide variety of technical knowledge areas, it is better for the hiring manager not to be so worried about particular skills, but rather a clear indicator that the candidate has shown a willingness to learn and to themselves invest in mastery of important skills, not just chase the next highest paying job.  Also keep in mind that there are a lot of people who sincerely believe that they can learn technical skill and mastery by watching 15 minute YouTube videos, especially folks who are new to the job market.  In the technical space, that kind of attitude can be helpful and/or it can be misleading.  So watch out for the person that in less than 10 years has touched 50 different technologies or protocols or methods.  They may be the wrong person compared to someone that has focused on 3 or 4 or 5 and has truly mastered them.

The third question is an extremely difficult one.  With the open source popularity and the high number of strong supporters of open source, there has been a movement away from technology secret keeping to solution sharing.  When hiring, there is no need to open this debate, nor to take sides.  Instead the issue here is one of trust.  Does the candidate clearly communicate trustability, and a great way to judge that is by asking them how much they value the privacy of their prior employer's code or technology.  We see that in certain cutting edge or market leading spaces, some people will hock their knowledge and intellectual knowledge, sometimes even including code they have written, to the highest bidder.  This can happen in run-of-the-mill technology spaces as well.  Usually the shadows of open source are cited as legitimacy for breaches in trust.  During the hiring process a focus on trust is imperative.  Perhaps discuss some scenarios where trust is the key and see how the candidate views the discussion.  Like what do you think about this story with Uber? Again, there is no right or wrong answer, but rather what constitutes the candidates viewpoint will reflect their potential trustworthiness.

The last question is difficult.  The interviewer has no crystal ball that they can view the future through.  Yet this is what the question challenges us with; what will the future hold if we hire this candidate.  The best way to approach this issue is to pose a future scenario (mostly fake of course), to the candidate, with some holes and problems, but with a clear staring point and a clear end point.  Ask the candidate to consider the options, and suggest there are barriers, but that you don't want them to discuss barriers, but rather options to achieve the business goal.  Again, there is no wrong or right answer.  The right candidates will solve the problem and provide technology answers that will either align or not align with the corporate goals.  Be prepared for the unexpected, they may even open new avenues, new technologies, new possibilities based on experience or gut instinct that could be even better!  

It's hard, right?  We know these answers helped our client, and I hope they help you as well.

Comments powered by CComment

Find by Tag

4G Networks 5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Addressing Analysis Ansible Architecture ARP AToM Baseline BGP Bloom's Taxonomy Broadband Cable cat CellStream Cellular Central Office Cheat Sheet Chrome Cisco Cloud CMD Coloring Rules Computer Consulting Customer Support Data Center Data Networking DHCPv6 DNS Docker Documentation Dublin-Traceroute dumpcap ECMP Ethernet Ethics Evaluation Field Operations Fragmentation G-MPLS GeoIP Git GNS3 Google GQUIC Hands-On History Home Network ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 India Interface Control Internet IoT IPsec IPv4 IPv6 IRINN IS-IS L2VPN L3VPN LDP Linux LLN LoL M-BGP MAC Macro Microsoft mininet Monitoring MPLS mtr MTU Multicast Name Resolution Netcat Netmiko NetMon netsh Networking Network Science nmap Npcap NSE Observations Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX OTT Paris-Traceroute Parrot PIM PMTU Policy POTS POTS to Pipes PPP Profile Programming Project Management PW3E Python QoS QUIC Remote Desktop Requirements Resume RIP Routing RPL RSVP Rural SDN Security Service Provider Small Business SONET Speed SS7 SSH SSL Subnetting SYSCTL T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone termshark Testing TLS Tools Traceroute Traffic Engineering Training Travel Tunnel Ubuntu Utility Video Virtualbox Virtualization VoIP VRF VXLAN Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Windows Winpcap Wireless Wireless 5G Wireshark Wireshark Tip WLAN Writing Zenmap ZigBee

Twitter Feed