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.

Subscribe to our Newsletter!

Our Tag Cloud

4G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Addressing Airlines Analysis Ansible Apple Architecture ARP ATM AToM Bandwidth BGP Billing Bloom's Taxonomy Briefings Cable CellStream Cellular Central Office Cheat Sheet Cisco Click Model Cloud Computer Consulting Crowd Funding Data Center Data Networking Decryption DHCPv6 dig DNS Documentation Early Adopter Ethernet Ethics Filter G-MPLS GNS3 Google Hands-On Hiring History Home Network HTTPS ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 Image Size Internet IoT IPv4 IPv6 IS-IS L2VPN L3VPN LDP Linux LLN M-BGP MAC Macro Management mergecap Microsoft mininet Monitoring MPLS Multicast Netcat NetMon netsh Networking News nmap NMS nslookup Online School OpenFlow OSPF OSX OTT PDF Personnel Policy POTS POTS to Pipes PPP Preview Privacy Profile Project Management PW3E QoS Remote Desktop Requirements RIP Routing RPL RSVP Rural Scanning SDN Security Sensor Service Provider Small Business SONET Spam Speed SS7 SSL Subnetting T-Shark TCP TCP/IP Technology Telco Telecom 101 Telecommunications Terminal TLS Tools TR-069 Traffic Engineering Training TRANSUM Travel Tunnel Ubuntu Utility Video Virtualization VoIP VRF Wi-Fi Windows Wireless Wireless 5G Wireshark WLAN ZigBee

Our Twitter Feed