Having worked as a contractor quite a bit, I’ve interviewed at a bunch of companies and have participated in quite a few interviews. When I cofounded a high tech startup in Silicon Valley and helped grow it into a successful profitable business, I was “the guy” who made the decision to hire and fire several employees. There’s one thing I learned through all of this: most people aren’t very good at hiring. Most people are trying to hire robots.
In this article I focus on the engineering field, but most principles apply to all careers.
How did I come to this realization? Well, here are some good metrics: If a company has an open position for several weeks or months and there are lots of good candidates out there, that’s a red flag. If your company has a lot of turnover, that’s a red flag. If you don’t have a good company culture where employees love to work, that’s a red flag. If you are not consistently meeting deadlines (without overworking your employees), that’s a red flag.
Here are some clues that you might not being taking the right approach: If your “senior engineer” who has never been trained in hiring or management is making the hiring decision, that’s a red flag. Anyone conducting an interview should know which questions are legal to ask, and which are not. For example, you can’t ask “so do you have kids?”. Someone who has managed employees and projects, not just technical tasks, should be involved in the interviewing. These people know the consequences of a bad hire. Your senior engineer may be technically brilliant, but may not have the right big picture company perspective in mind (and all the points I bring up in this article).
If you grab your “junior engineer”, shove a resume at her, and tell her to “interview this guy” today, that’s a red flag. Not only do you run the risk of her asking the “no no” questions, she has no experience in interviewing and this can be very awkward for both parties. You should have a script that can be followed (if necessary), and each interviewer should have adequate time to read the resume and think about what to discuss well in advance.
If the CEO speaks to each candidate for an hour before there is any filtering or technical evaluation, that’s a red flag. That is an incredible waste of a valuable resource, probably the most expensive resource in the company. I do think a CEO of a small company (or senior manager) should meet each candidate sometime during the process, but if basic filtering can’t be delegated to someone less expensive, then that’s a sign of bad management.
If only one person participates in the technical evaluation, that’s a red flag. Putting all that responsibility on someone who is most likely poorly trained in how to do it properly is not smart. It’s good to get more than one technical opinion. I have personally been deemed under qualified and over qualified by the same interview team at the same company! On the other hand, being placed in front of a tribunal of 5 engineers grilling you on esoteric technical questions is also the wrong approach. Subjecting a candidate to such stress is not a sign of good company culture.
If your technical questions consist of things that can be answered by Google in less than 30 seconds, that’s a terrible interview. Gone are the days when you needed to memorize as much as possible to do engineering. Today, you need to be able to find information quickly, not memorize syntax or algorithms. If you are aware of certain concepts and features in a language or framework, you should be able to find sample code almost instantly. Being able to recognize good solid sample code vs crappy sample code is the skill you need today. Modern IDE’s autocomplete and fix your syntax errors so you just need to get close. I have personally been deemed technically unqualified after failing to answer a question that later I found on stackoverflow.com in 30 seconds (yes, I timed it!). Common technical interview questions I’ve seen are things like “code up the fibonacci sequence recursively”. Really? Why? I can find some very good sample code to do this in seconds. A better question is “look at this code and tell me how you could improve it”.
Of course, engineers do need to product new and unique code, and do need to construct good algorithms. The better way to evaluate this is to ask for a flow chart or high level description of the modules needed for a bigger more complex problem.
When it comes to formulating a good technical interview, remember how engineers actually do real work. We spend some time thinking about a problem, we peruse the internet for ideas and sample code, we optimize and customize, we test and fix our silly bugs, we refine what is working and make it work better — all of this without anyone looking over our shoulders. If you expect someone to regurgitate perfect syntax and memorize every API call while being timed in front of several engineers, then you are trying to hire a robot. Do you want to work with a robot?
One thing is undeniable: hiring the wrong person is worse than hiring nobody. Interviewing and training new employees is a very costly process. If you are not tracking this “cost”, then you should be. Once you decide somebody is not right for the job, then the process of trying to correct the behavior or remediate is also very costly. Having fired several people myself, I know it’s a very heavy drain emotionally and the hardest thing I’ve ever been paid to do. It is to be avoided at all costs!
On the other hand, you don’t want to be in analysis paralysis. I know of a company that is understaffed and has had a engineering position open for two years, in a job market that is filled with qualified engineers. Their “senior engineer” (with no training in hiring or management) has been spending approximately 6 hours per candidate, plus additional man-hours from the candidates and other employees who get pulled in, only to determine that every candidate (dozens of them) is not technically qualified for the job. There is a real measurable cost in the time spent by the senior engineer here, and an additional cost in being understaffed for so long.
If you can’t seem to find anyone who is technically competent, then perhaps your bar is way to high. It’s not really that hard to stump an engineer, if that is your goal. Perhaps you don’t have the proper company infrastructure in place. It is very difficult to find a “Jack of all trades” — those people are rare gems. If your engineering structure depends on everyone being an expert in everything, then you are doomed to failure. That is unsustainable. What you usually end up with is understaffing, over worked employees, and the engineers are “masters of nothing”. Instead of the robot who is a “full stack engineer who can write iOS, android, and web apps, with extensive experience in back end server code”, perhaps you need to break that apart in to 2, 3, or even 4 job positions. Yes, it’s more expensive, but that might be what it takes for long term success. If you can’t afford to do it right, it is time to rethink your plan.
Another mistake is looking for a specific skill, and if you don’t find it, you move on until you find someone with only that specific skill. You are looking for the ability to learn new things quickly, not the ability to reproduce the past. Imagine asking Michelangelo “Have you ever painted the ceiling of a large building?”. He says “No”. The hiring manager say “Sorry, you are not qualified to paint the Sistine Chapel”. What you end up with is a house painter, and you just passed up on one of the greatest artists of all time.
Here are some skills or qualities that hiring folks rarely evaluate. To me, these are all “technical” skills because they are all needed to perform a technical job, or are qualities that are desirable in the long term as an employees moves up the ladder:
—Can you write effectively? Engineers need to communicate clearly and effectively. We write several emails every day, need to comment our code, need to comment our source code commits, and may even need to communicate with clients.
—Do you act professionally? i.e. Will you embarrass the company if you speak or meet directly with a client? You want engineers that can represent your company well, and instinctively know how to avoid sticking a foot in the mouth, don’t make promises that can’t be kept, and don’t piss off the customers.
—Do you play well with others? Do you work well with others? These are really two different points. Knowing the technical aspects of working in a team environment is one thing, such as good source code management, good code documentation, communicating with the team. The other part is getting along, being well liked, not pissing off your colleagues. One bad apple really does spoil the whole bunch!
—Can you think outside of the box? Some engineers are great at doing what they are told, even if the instructions or requirements are faulty. These are robots. You need engineers who can question a bad design, propose better solutions, and add value to the engineering process.
—Do you get your work done on time? This is really crucial, and some technical interviews attempt to measure this by giving a timed coding test, thinking that the amount of time you spend typing code is equal to your productivity. That’s nonsense that only a robot excels at. A good engineer spends more time thinking about the problem, asking questions, and exploring solutions at a high level than coding. Someone who gets tasks done on time is the guy who doesn’t take a long lunch and works a little later when a deadline is approaching. He’s the guy who fully understands a problem before diving in to it. He’s the guy who comes up with the right approach. He’s the guy who stays focused on the highest priority of the moment.
—What is the quality of your work? Is it readable? Sometimes I am asked for a code sample, but most often I am not. Sometimes the only code that is reviewed is the code which was written in haste and under pressure — not my typical code. You should ask for some sample code that the candidate is proud of. You shouldn’t look for the most clever algorithm or feature implementation, but the code should be easy to follow, clear and readable, and just enough comments where needed.
—Can you think on your feet (work without close supervision)? Supervisors are not around all the time. Sometimes you are given vague instructions, or incorrect instructions, or something happens that suddenly changes the priorities. You need an engineer who can see the big picture and stay on target, and an engineer who can fill in the blanks without grinding to a halt.
—Can you multitask well? Before starting any set of tasks, you should always know the priorities and deadlines. Always ask “which should I do first?” and “when do you expect this to be done?”. And after that, guess what? Constantly reprioritize and reevaluate. In the real world, especially in small companies, things change quickly and priorities can change daily. Each time you get handed a new task, you should ask “OK, but I’m also doing these other things, which should I do first?”. If an engineer has a good grasp of the big picture, that engineer instinctively knows how to reprioritize any new set of tasks.
—Do you have experience leading others? Ideally if you hire a good engineer, they will eventually be needed to lead others, at least at the technical level. Find out what the experience and potential is of your candidates.
—Do you have experience managing projects? Some engineers most definitely want to stay technical and not manage projects. Others find it rewarding and enjoyable. It’s nice to hire an engineer who can fill in when the boss goes on vacation or is too sick to come to work.
In closing, I find that most hiring managers and interviewers do an awesome job of finding robots, but a terrible job of finding good workers who have the necessary technical background but also secondary skills needed for the long term. If you hire well, then you reduce employee turnover and consistently get things done on time without overworking your employees. Don’t ask questions that can be answered by an internet search; do ask questions that reveal all the things you really want in a new employee.