Most developers are open and honest about their careers and skills. Some, however, are less than truthful and a few will simply outright lie during the interview. It’s difficult for non-technical interviewers to properly assess answers and figure out if they are telling the truth. There are ways however that you can judge a person’s overall truthfulness in the interview. Once you’ve got your candidates lined up, one of these ways is to come into the interview with questions to ask that do not have technical answers.
Asking questions and listening closely to the answers is not a trick, nor is its usefulness limited to interviewing developers.
Now that you know you are going to conduct the interview, it is time to do your prep work. For each candidate, you need to have a list of questions you want to ask before you get into the interview process.
Start by reviewing the person’s resume. What questions do you have about the jobs they have worked on? Write them down.
- Ask them about the technologies they worked with.
- Ask them about the composition of the teams they have worked on.
- Ask them about the projects they have worked on and what they learned.
- If there are large gaps in their employment you may want to ask about that, but then again, you may not.
Asking Technical Questions
When it comes to technical questions, you will want to ask about the technologies that your team works with, but be prepared that you are probably not qualified to judge the answers. If you have the option, bring one of your current developers into the meeting with you. They can help you evaluate the technical answers after the interview.
Non-Technical Questions to Ask in Technical Interviews
For questions that will help you talk about technology without asking about specific technologies, I asked a few friends of mine to give me some questions you can ask.
“What brings you joy about the work you do?”– Matthew Trask
This will help you get a feel for the types of projects they like, the technologies they like working with, and the way they interact with the teams they work on. The way they talk about the project (I/me, vs we/us) will give you clues about how they think about teams.
“Tell me something you are really proud of accomplishing.”– Duane Gran
This builds on the previous question but gives them a chance to really showcase something that they got to work on and was a success.
“What is the next thing you want to learn, tech or otherwise?”– Josh Butts
This will give you some insight into where their head is. The answer to this question doesn’t have to be a new technology or the next shiny. Telling you that the next thing they want to learn is a musical instrument is just as important of an answer as “Machine Learning”. Neither answer is good or bad, they just help you understand the person more.
“What’s something you can teach us in 5 minutes that’s not tech related? I like it, it changes gears, shows communication and ability to think quickly.”– Guy Warner
As Guy points out, this one can help you assess a candidate’s ability to switch gears and their ability to instruct. Personally, I would limit this question to senior-level candidates as I don’t really expect juniors to be able to instruct.
“I always set aside about 15 minutes towards the end of the interview for two specific things:
1. Any questions for me?
2. An opening to highlight/discuss/brag anything about yourself that I didn’t ask about. Doesn’t necessarily have to be code-related.”– Colin Lord
This is a great way to transition an interview to the end. Allow the interviewer to answer the question you didn’t ask but they want you to know.
There are hundreds of other questions you can ask. In the past Google was famous for asking “Fermi Problems”. For example, when I interviewed with them, my “Fermi Problem” was “How would you update 10,000 servers located on the moon.” The interviewer did not consider it humorous in the least when I answered “slowly.”
I dislike Fermi Problems because unless you regularly practice asking yourself these types of questions, the method for estimating an answer isn’t always clear. Also, I’ve never seen a Fermi Problem that led to any insight into a candidate. For the most part they exist to make the interviewer feel superior.
Asking questions gives the interviewer a chance to talk about things in which they are interested. If you are asking about previous projects, you should feel their energy about the project.
Most interviewers aren’t going to be able to “catch someone in a lie”, so don’t try. If you find yourself interviewing someone who you feel is lying to you, that says more about your selection process than anything else.
If the answers don’t sound genuine to you, then you need to decide what the next steps are. Either you want to dismiss the candidate as viable based on your gut feeling, or schedule them with someone else who can double-check your gut. Preferably someone without your exact same background and biases, if that’s an option. If you don’t have the option of a second person to double check you, I have always found that “going with your gut” to be the best alternative to doing nothing.
Want to get great devs hired on without the hassle? Let Gun.io help you get the best freelance developers in the universe, leaving you with more free time to grow your business.