50 Great Job Interview Questions
What questions should you ask a candidate as you are interviewing to fill a software development position? How can you truly asses his abilities as a developer?
Join the DZone community and get the full member experience.Join For Free
This is a follow up article of my previous article, where I ranted about irrelevant job interview questions, where the idea was that technical job interviews today related to software development positions are fundamentally flawed. Sure, some very few positions requires the candidate to know every algorithm and data structure in the book, but these jobs are long and far apart. Hence, I will propose questions in this article that are much more relevant for most jobs. These are the types of questions I would ask myself, and I personally believe they are much better suited for assessing a candidate than most job interview questions I have ever seen.
Do not automate the questions
The idea that you can automate the job interview, by giving the candidate tasks through some website or app is simply ridiculous. First of all you are losing a golden opportunity to talk to the candidate. Which allows you to see how his social makeup is, and how he would fit with your existing team. Pick a couple of developers that are already on the team the candidate should be working on, and have them hop in on the interview, and help out with the assessment. And only if these developers tells you the candidate seems OK you move onwards. This ensures the candidate is able to work with your existing team members.
Ask the candidate to talk about his favourite project. If the candidate has a GitHub profile, have him talk about one of his Open Source projects if you can. First of all a job interview is a stressful situation, and you want the candidate to feel relaxed. Our ability to think shuts down the more stress we're given, and throwing 20 questions at the candidate, giving him 20 seconds to answer each, only serves to freak out the candidate, making it impossible to assess his abilities.
If you allow for the candidate to talk loosely about his own projects, and have him show you some code from some open source repositories he's created, he calms down, becomes more relaxed and self assured - And it's easier for you to assess his true abilities. If you can get him to show you code, then try to find some flaw in his code, and ask him about this. This creates a golden opportunity to asses whether or not the candidate is willing to openly accept and discuss his weaknesses, or if he becomes protective. Although you want the candidate in a relaxed state of mind, you still want to make sure he's able to talk constructively about his own code, and if he is able to handle constructive feedback. This is only possible if he is relaxed first. This reduces the chances of that you hire a person with a "quarrelling nature."
Ask the candidate to explain to you high level concepts, such as for instance "What is the purpose of the singleton pattern? Where have you used it yourself? What is its drawbacks?" This ensures the candidate knows his theory, and (bonus points) is able to talk about his own code, explain it, and understand its concerns. Some example are given below.
- What is SOLID programming?
- What are design patterns?
- What is the purpose of async programming, and how does it work?
- What is an SQL join, and where would you use joins?
- What is the main difference between a document based database such as Mongo and an SQL database such as MySQL? (bonus points if the candidate starts talking about the CAP theorem)
- Explain what Micro Service architecture is and where you would use it, and where you would not use it?
- When did you use Micro Services architecture? Was it a good choice? (Bonus points if the candidate mentions a project where he should not have used it, due to that the project became unnecessary complex because of using it)
- What types of caching exists for Web APIs?
- What does this method do? (Show him a method that does something, not too complex though. This ensures the candidate is able to read code, which is probably more important if he'e supposed to be working in a DevOps team than being able to actually write code)
- What is DevOps? Mention some elements in a successful DevOps environment?
- What is Dependency Injection, and what is its purpose?
- How would you setup a DevOps environment using for instance Azure? Explain the steps.
- Etc, etc, etc
The above are the types of problems a developer is actually facing in his job, and much more relevant than whether or not the candidate knows how to implement Quick Sort. Personally, I haven't implemented Quick Sort for a couple of decades, and I'd have to read up about it before I'd be able to implement it. Simply because for me sorting is "List.Sort", and believing I could outperform 20 years of innovation in C# and .Net by implementing my own sorting algorithm is simply delusional, and only demonstrates I am willing to spend my time doing unnecessary things, and that I am suffering from the "Not invented here syndrome" if anything.
Notice - If the candidate doesn't remember what every single letter in SOLID means, this is not relevant. Allow the candidate to search for what the acronym means if he needs to, and explicitly tell him he's allowed to, to reduce stress, allowing him to speak more freely. In fact, this is not even a negative thing, since a part of our job is to search for things, find answers, and rapidly translate them into something useful. However, if he's allowed to search for SOLID, and still needs 5 minutes before being able to explain what Single Responsibility implies, he has flunked!
Did he prepare for the job, or did he prepare for the job interview?
The LAST question
Then, finally, you can give the candidate some tasks such as "Could you show me an example of how to implement a palindrome method in your favourite programming language?" However, these are just bonus points, and not intended to make a big change in regards to your existing perception of the candidate. These questions should not be more than 5% of your evaluation of the candidate, simply because a candidate can easily have taught himself these questions by watching YouTube for 2 hours, and exercising questions for a weekend. If this is what you assess the candidate from, you're setting yourself up for failure. However, it allows you to observe how the candidate is using his IDE, and if he's comfortable writing code, also under stress, in a "pair programming" type of environment. But really, these are bonus questions!
If you follow the above, you reduce the likelihood of hiring the wrong candidate by at least 10x. Simply because if you wanted a machine, capable of answering "20 questions", you don't even need a human being, you're looking for Magic.
Opinions expressed by DZone contributors are their own.