June 27, 2013 1456 views
Written by: Bryan Healey
I truly believe, from the very depths of my soul, that the most important thing that any manager can do is hire, and hire well. A team that is composed of motivated and complimentary talent is a team that will produce efficiently and consistently, and require minimal guidance. I have personally observed a lot of (easily preventable) turnover from only poor hiring practices, and it saddens me. A bad hire is one of those few management acts that is universally bad at every level; it's bad for the engineer, bad for the manager, bad for the company and bad for the product. No one is happy when a manager does a poor job evaluating a candidate, and so it must be given the greatest focus.
Part of the problem is that no one really knows how to best evaluate a technical candidate (not even the technologists themselves). Everyone thinks that they know the best approach, but when put to the fire almost everyone defaults to the same unreliable and inconsistent methods that have been used for decades. The most common pitfalls of the technical interview are:
1. Focusing on memorization.
2. Not letting the candidate do the talking.
3. Requiring a college degree, certification or fancy internship.
4. Having poor conversational skills.
5. Falling in love / out of love too fast.
Fortunately, each of these problems is easily solved!
The most important thing you need to do is stop focusing on memory-dependent questions. If a question is easily answered with a quick Google search, then it is a wrong question. It is an industry rule that no technologist should be willing to waste precious brain space memorizing every little tidbit about any specific technology. We have the internet nowadays, and it is remarkably good at helping us solve common problems in no time at all. A good technologist is not made by how many different regular expressions they have memorized; rather, a good technologist is made by having a well-developed ability to think critically and logically and quickly... And I should continue here by saying that logic puzzles and word problems are not the solution, either! It became fashionable in the last few years to substitute technical questions for New York Times style brain teasers (such as "How many golf balls would fit inside an airplane"). These questions are useless; a good engineer wouldn't waste time conceptualizing the issue, but would write a program that fills a mock airplane with golf balls and maintain an accurate count!
The second most important thing you need to do is stop worrying about college degrees! The same goes for certifications, that Google internship, or any other flashy resume tidbit. Why, you ask? Because such trophies are often, in practice, terrible indicators of success. Some of the most talented and respected technologists I've ever worked with have never finished college (and some didn't even bother starting), while some of the worst I've ever worked with have had advanced degrees and a resume a mile long. The ability to study diligently and prepare for tests might demonstrate good organizational skills, but it is not an incubator for successful engineering. Software development is all about thinking logically and creatively, responding to adversity with mettle and gumption, and finding pragmatic ways to solve non-obvious problems, and those skills are learned in the fires, not in the classroom.
Is education important? Of course! And given two candidates of equal practical talent and personality, the educated candidate will get the nod. But it isn't the most important thing, and it gets far too much focus. Even at Google, the tech giant with an infamous penchant for academics, has recently recanted their philosophy. The evidence is clear and becoming increasingly obvious to a larger number of companies: education, while valuable, is not the best marker for employment success.
So, given the above, what should you do?
The first thing you need to do is hone your conversational skills. Learn to be friendly and inviting. Don't dominate the conversation, of course, and don't let the candidate rule the meeting, either. Make the individual comfortable, be open, and get them to spill their guts. Get to know their technical background, how they got into technology, how they learned their skills, the companies they've worked for and why they left; ask about past projects and what they're most proud of, and what they are working on now, and what difficult problem was most fun to solve. Learn what technologies they like to work with and why; find out what is their favorite baseball team. What do they do for fun? Get to know the candidate as thoroughly as you can, both professionally and personally, and take diligent notes. That is the only way you can expect to make reasonable assumptions about how best their skills and personality might fit with your team. This is the first step...
The second thing you need to do is make the candidate write some code. And don't waste their time with some stupid recursive loop function taken from a 1994 textbook that anyone could do in five minutes with half a brain; make them really code. Give them some minor, but very real problem and ask them to solve it. Keep instruction to a minimum and let them do their thing (while aware that they can ask questions freely). Give them some time away from the interview to complete it (consider paying them a small contract fee) and scrutinize the result. You can learn an awful lot about a programmer just from reading a little original code.
Finally, don't be afraid to let them go. I don't care how amazing a resume may seem, or how great of a talent you think they are; if they are not the right fit, then they are not the right fit. Don't try to force someone into your organization just because they seem to be a good technologist. That is a recipe for a very bored programmer and an unhappy team. Similarly, don't dismiss a candidate out of hand just because you don't like their resume; have a conversation with everyone. At worst, you will waste 15 minutes of your day, and at best you might find a diamond in the rough. Also, (and this is the part that requires just a little bit of intuition) don't be too strict on position requirements. You don't need the perfect candidate (titans of technology are rare finds), you need the right candidate that fits with the team at the right time. For example, don't be afraid to hire a junior Ruby developer for a mid-level PHP position if you truly believe that they can do the job; hell, I wouldn't be afraid to hire a junior Ruby developer for a senior leadership position if I truly believed they had the personal and professional chops to do it. Every person is different, every skillset is unique, and a good manager has to apply a little judgement.
If you work hard and pay attention, hiring a quality team will become the greatest thing a manager ever does. It will lower stress levels, raise productivity and keep everyone happy. It is truly the most important thing.
