It may sound preposterous to you, but most of the candidates can’t even write basic code. Let’s not even get into the world of Fizz Buzz questions. Some interviewers dismiss these tests, while some, knowing how many candidates can’t write accomplish the simplest programming tests, find the famous FizzBuzz tests immensely suitable.
Ultimately, the idea is to help people quickly filter out technically inept candidates by asking some basic technical questions to not waste time and effort interviewing them. The best way to do this is by using an automated online tool. (Here’s a comprehensive post about using online coding tests for hiring programmers.)
Though the first round of screening eliminates many irrelevant candidates, it forms a very small part of the entire interview process. It’s after this step that the interviewing process is largely broken. The “getting the candidates into a room, asking them riddles and brainteasers and making them write code for bubble sort on a white board” is not only an inaccurate way of determining if they are good software engineers, but also an unfair method to test them.
This method of technical interviewing was common because it was popular even with behemoths such as Microsoft and Google. But things have changed. Laszlo Bock, Google's Former SVP of People Operations, admitted that “Brainteasers are a complete waste of time.” He added that Google had concluded from one of its studies that there is a zero relationship between how a candidate fared in their interview and how they performed in the job. More people have been speaking about how horribly broken this process is.
Typical tech hiring process
How to do it right
What kind of developers do you need for your company? You need people with excellent technical ability, who can work well with a team and can get results (the end does justify the means sometime). Rorie Devine, interim CEO, says he does a resume screen, an “attitude” phone screen, and an “aptitude” phone screen before he calls candidates for a face-to-face stage. Although many people are now moving away from resumes being any sort of indicator of a person’s skills, some people go the traditional way.
According to Stack Overflow
- 35% of developers want to be better prepared for the interview, and be informed of who they will be speaking with.
- 20% of developers say flexibility about interview scheduling is important to them;
- 47% of developers want to be introduced to the team during the interview
- 37% of developers would like the opportunity to see the workspace during their interview.
- Developers will appreciate you being honest about expectations (salary!) up front, being on time, and being organized.
- Developers want the company to communicate the decision after the interview soon.
No one really likes an interview. And developers aren’t any different. So, add a dash of creativity and lots of logic while designing your interviewing process.
Posts written by Jeff Atwood, Udo Schroeter, Nelly Yusupova, and Treehouse on how to hire developers offer some useful insights on how to interview better. If you read these, you’ll notice that most of them have given minor variations of the following process for technical interviews:
Talk to people: Ask them about their field of interest, what they have done in the past, technical challenges they have faced, best practices they follow, their pet peeves, etc. You need to put the candidate at ease before you go for them with all guns blazing. Note that the intention of this exercise is not to technically grill them but to understand their behavioral pattern.
“Questions are meant to get real value, and they’re are not supposed to be confrontational. They’re just supposed to see how people think and if they’re ready for that type of position,” says Robert Schumann from Leoma Inc. Refrain from asking them silly whiteboard questions that might make you feel smart and them stupid. Ask really relevant questions to gauge their technical prowess.
Projects and real-world problems: Ask them about the project they did at university or in their previous company. Pick up their work on GitHub and ask them a design question around that or give them a real-world problem. Touch upon concepts such as optimization, large-scale thinking, practical implementations, etc. Break down one question to multiple conceptual questions. The idea is to see how they reach a solution and how, and if, they optimize it in the process.
Ask them about their programming practices. You can ask about application architecture decisions, testing, source control, or naming class/variable, etc. Look for self-awareness and honesty in their answers.
Look for intent: Many people stay on the surface and are reluctant to dive deep. Look for a passion to code and a passion to learn. Ask them questions about their career history. Find out if they contribute to open source. They could be mad about their craft, making them quite trustworthy.
These are your potential star performers. They might not exactly have the skill set you are looking for, but if given a chance, they will make sure they learn it and maybe even do it better than you! Ask them if they go to hackathons or catch up on the latest in the world of development.
Establish “Cultural Fit”: Understand that interviewing is a two-way process - not only are the candidates trying to sell themselves, but you are also selling your company to them. The best way to identify a “cultural fit” is to sell your company, with the same passion as you would do in a sales meeting and see if it excites them. (It’s quite possible that tons of awesome developers would have been put off by Google/Microsoft’s illogical and, at times, even denigrated the interviewing process.).
However, while establishing cultural fit, be wary of the fact that you don’t start excluding people who are not like you. You might be pretty keen on the social aspects of your company’s culture but putting too much emphasis on it can drive away unique, brilliant candidates who enjoy different things. Remember to ensure that they understand that cultural fit is not the top priority, writing good code and satisfying client requirements is. A workforce that is rich in diversity has many good things to bring to the table. Talk to the candidates about what values matter to them and what organizational culture excites them.
Give them an audition project: If they have come so far, as the last step, give them a small bite-sized project, which could be something independent, off of the critical path, but something that’s real, and something that would go into production. Some developers might get offended that you are getting work done for free, so don’t do that; pay them for the week, but closely observe them, how they code, and how they solve the problem. Additionally, they could also do pair programming with your team member.
Test them. Developers with some experience may be peeved but like Jeff Atwood says, “The goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it’s sad and kind of depressing that this is even necessary, but if you don’t perform this sanity check, trust me – you’ll be sorry.”
This process is far better than doing multiple rounds of mindless brain-numbing brain-teaser interviews. The only problem with this process is that it’s difficult to scale. This kind of process requires a lot of pro-active involvement of the interviewer. It’s not something you could lay down as an interviewing methodology and expect everyone to follow. The process must be internalized with all those who conduct interviews in your company.
In one of his articles from a while ago, Bill Venners, Artima, Inc. President, said, “Finding good programmers is hard because good programming is dependent on much more than just knowledge of programming language syntax. You need someone who is creative enough to find innovative solutions to problems, yet anal retentive enough to always line up their curly braces. You need someone who is humble enough to be open to suggestions for improvement, but arrogant enough to stand firm and provide leadership when they are the best person to provide it.” (Read the article for tips on how you can manage to find this superior being in 30 minutes.)
The purpose of interviews is to serve as a proxy for actual work performance. But the current process of technical interviewing couldn't be more off. Conduct your technical interview to identify what the candidate can actually do while keeping the process interesting enough for them.
At the end of the day you need empathetic skilled developers, who have the requisite emotional intelligence and people skills to inspire and lead by example. You can find them all right, just follow these tips and you should be set for success.
Looking to conduct online coding tests to hire developers for your organization? Try HackerEarth Recruit free for 14 days to start creating tests for your candidates right away.
A couple of interesting reads: