I almost exclusively pull from my own knowledge-base for questions, as those are the easiest for me to evaluate fairly. The exception to that might be if I'm interviewing an expert in an area I don't know that well. In those cases, I will ask them to explain a concept to me, or better yet, explain a project they did in terms that an experienced software developer without their specialty will grasp. A true expert should be able to explain something at multiple levels, even simplifying the concepts down to the level of "explain it like I'm 5".
I am looking for 2 things. First, and most importantly, I want to see how they think about problems or even concepts. I'm less interested in whether they can solve a problem than I am that they will start thinking about it, and also that they have some idea about resources available to problem solve. They should be willing to ask questions and/or admit they don't know enough at the moment to solve something. Second, I'm trying to gauge their level of expertise in specific areas. That means I'm going to ask questions and raise or lower the difficulty and specificity until I figure out about where their failure point is (I try to make sure they know that so they don't think they're doing poorly). I am usually pulling from their resume or their own statements about areas they are strong in for that, so I'm not asking hard C++ questions to a recent grad who was trained on Java.
Some examples:
Compare and contrast C++ and Python. How are they similar, how are they different?
From here, I may get more specific, like asking them to contrast how parameters are passed in the languages, nudge them toward pointing out compiled vs. interpreted, get into references and pointers, etc.
If they mention high-level vs. low-level language, I will push them to explain what that means. I will often follow up with "say I gave you two programs in languages you didn't know at all. You can read them enough to sort of work out what they do, and both give identical results. What are some things that might tell you which one is the more high-level language". This is especially helpful if they struggle to explain the difference.
This is more of a recent grad or "poor experience level" candidate question.
How would I define a function in Python that takes a list with a default value of an empty list?
The answer here is "= None", not "= []". Using the latter will result in an empty list being defined at function definition time, and every caller to that method will get the same list. The correct method is to check for None and create the list every time.
This is trivia, however, it is important Python trivia. It's my go-to for someone who claims expertise in Python, as they should have encountered it already, and it's a common bug. I would never ask it of someone who doesn't claim Python expertise. It would also never be my only way to gauge their expertise. This is just an example of the level of trivia that's meaningful for someone who claims expertise.
Tell me about [this project] on your resume and what your contribution was.
This is somewhat obvious, but it's HUGE. They should be able to summarize the project, and they should be able to describe some meaningful part they performed, even if they were just an integrator/tester, or did research or support.
Tell me about some problem on [major project they supported] that your team encountered. What did you do to minimize or eliminate the impact, or how did you suggest solving it?
What I'm looking for here is whether they maintain awareness of more than just mechanical project execution and try to help make the whole team successful. I'm looking for things like open communication and not just ignoring problems. Other than this being generally important, a dev who ignores process failures is also likely to ignore bugs they find unless they were assigned to find them.
I actually hope they volunteer this for the previous question, but if not, I will prompt them.
I'm looking for a problem with process/efficiency that they noticed or a recurring issue (e.g. reappearing bugs, new team member orientation, etc.) rather than how they solved a particular implementation issue.
If the project was somewhat toxic and the problem wasn't solved, that's fine. I will have them describe how they would go about fixing it. Solutions that failed are also fine; this is about whether or not they do more than just process Jira tickets.
What is your strongest language or technology? (and/or) What are some technical areas you are less strong in or where you feel like you could use improvement?
At some point, we have to trust the candidate to self-evaluate. This is also an important skill to check for.
With a weakness, I will often ask them what they would do in a situation where there was a need and they were the only person on the team who could work on the project. I'm looking for whether they can find resources, are willing to learn and improve, and aren't afraid to admit the weakness and communicate openly (i.e. "I'll do my best here, but this is not a strong area for me."). Bonus points if they talk about using good process to protect from lack of expertise (e.g. TDD, good validation process, etc.).
If you could work on any project, money wasn't an issue, what would the project be? What language/technology would you use? What's your "dream project" right now?
Interviewing a candidate is just as much about finding a good role fit for them as it is judging their suitability for us. I want them to be happy working with us. We can always move them around later, but we want to aim somewhere in the ballpark so we have the opportunity to tune the fit before they get frustrated and leave.
I'm not looking for whether they have all the right terminology for everything, especially for less experienced candidates. More experienced candidates should really speak using dev jargon relatively comfortably, or at least be able to explain themselves clearly. I'm not really listening for it, though, it should just be more noticeable if they can't. I'm going to be pretty forgiving of junior devs, but senior devs and leads would be expected to write/edit documentation and review code regularly, and the ability to communicate clearly is critical.
What I don't ask are open-ended questions like "tell me about a time when...". That's too open-ended and puts the candidate on the spot to search their own history. Inexperienced candidates are likely to freeze up, and experienced candidates have too much history to mentally search. It's also completely overwhelming for some candidates with certain disabilities, like say someone on the autism spectrum, which isn't at all uncommon in our industry. The only people who answer those questions well are those who rehearsed them, and rehearsed answers are boring and rarely tell me anything. I want the interview to be more of a conversation and keep them talking freely. By being more specific, like asking about a project they spent significant time on, I can get at the same concepts while keeping their mental search space to a manageable size. "Tell me about a time..." is one step short of the awful "what's your greatest weakness?", and I wouldn't blame a candidate for walking out of that interview right then.
I also interview management- or lead-level engineers sometimes. For them, I will ask some questions to see if they understand the concepts and skills of a good leader. I want to make sure they know they are there to make the project and the engineers successful, not to be "the boss". They should understand the importance of communication and being the type of manager/lead that the engineers will come to with problems, including not being happy or feeling like they aren't contributing. I also want to see that they will communicate issues up the chain quickly, hopefully with some ideas or solutions in mind, but especially if they don't know what to do. If I can't get at some personal experiences, I'll pose hypotheticals like "what would you do if you found yourself managing a project that had a lot of turnover, to the point that it seems like no one wants to work on it?" Because we are a small company that is very contract-based, I may also ask, "At what point should we consider cancelling or not renewing a contract that we have trouble keeping engineers on?" I don't expect them to have THE answer for that. It's a hard problem, but it's a real-life problem. What I want to see is that they recognize when they are out of their depth and can bring bad news and concerns to the company leadership, and moreover that they wouldn't try to cover the problem up or cause undue suffering for our engineers. We have extremely low turnover for our industry, and I want to keep it that way.
Bottom line, interviewing is HARD. Some companies have standardized their format to try to eliminate bias, like Google's almost exclusively whiteboard-coding interviews, but I think that's worse in some ways (and still doesn't eliminate bias). It's somewhat subjective, and sometimes a good candidate is just going to have a bad interview with you. All you can do is practice and find what style and what sort of questions get you the type of information that you feel is helpful in making a hiring decision. Also maybe find out if you can do tandem interviews where you and another interviewer team up and combine your time (e.g. 1 hour instead of 30 minutes each). We've recently switched to doing this, and I think it's much better, as long as you make sure to set the candidate at ease. It also saves the candidate from answering the same questions 3-4 times.
That's a lot, I know. It would probably be easier to write it up as an article to share, but I hope it was helpful.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I almost exclusively pull from my own knowledge-base for questions, as those are the easiest for me to evaluate fairly. The exception to that might be if I'm interviewing an expert in an area I don't know that well. In those cases, I will ask them to explain a concept to me, or better yet, explain a project they did in terms that an experienced software developer without their specialty will grasp. A true expert should be able to explain something at multiple levels, even simplifying the concepts down to the level of "explain it like I'm 5".
I am looking for 2 things. First, and most importantly, I want to see how they think about problems or even concepts. I'm less interested in whether they can solve a problem than I am that they will start thinking about it, and also that they have some idea about resources available to problem solve. They should be willing to ask questions and/or admit they don't know enough at the moment to solve something. Second, I'm trying to gauge their level of expertise in specific areas. That means I'm going to ask questions and raise or lower the difficulty and specificity until I figure out about where their failure point is (I try to make sure they know that so they don't think they're doing poorly). I am usually pulling from their resume or their own statements about areas they are strong in for that, so I'm not asking hard C++ questions to a recent grad who was trained on Java.
Some examples:
I'm not looking for whether they have all the right terminology for everything, especially for less experienced candidates. More experienced candidates should really speak using dev jargon relatively comfortably, or at least be able to explain themselves clearly. I'm not really listening for it, though, it should just be more noticeable if they can't. I'm going to be pretty forgiving of junior devs, but senior devs and leads would be expected to write/edit documentation and review code regularly, and the ability to communicate clearly is critical.
What I don't ask are open-ended questions like "tell me about a time when...". That's too open-ended and puts the candidate on the spot to search their own history. Inexperienced candidates are likely to freeze up, and experienced candidates have too much history to mentally search. It's also completely overwhelming for some candidates with certain disabilities, like say someone on the autism spectrum, which isn't at all uncommon in our industry. The only people who answer those questions well are those who rehearsed them, and rehearsed answers are boring and rarely tell me anything. I want the interview to be more of a conversation and keep them talking freely. By being more specific, like asking about a project they spent significant time on, I can get at the same concepts while keeping their mental search space to a manageable size. "Tell me about a time..." is one step short of the awful "what's your greatest weakness?", and I wouldn't blame a candidate for walking out of that interview right then.
I also interview management- or lead-level engineers sometimes. For them, I will ask some questions to see if they understand the concepts and skills of a good leader. I want to make sure they know they are there to make the project and the engineers successful, not to be "the boss". They should understand the importance of communication and being the type of manager/lead that the engineers will come to with problems, including not being happy or feeling like they aren't contributing. I also want to see that they will communicate issues up the chain quickly, hopefully with some ideas or solutions in mind, but especially if they don't know what to do. If I can't get at some personal experiences, I'll pose hypotheticals like "what would you do if you found yourself managing a project that had a lot of turnover, to the point that it seems like no one wants to work on it?" Because we are a small company that is very contract-based, I may also ask, "At what point should we consider cancelling or not renewing a contract that we have trouble keeping engineers on?" I don't expect them to have THE answer for that. It's a hard problem, but it's a real-life problem. What I want to see is that they recognize when they are out of their depth and can bring bad news and concerns to the company leadership, and moreover that they wouldn't try to cover the problem up or cause undue suffering for our engineers. We have extremely low turnover for our industry, and I want to keep it that way.
Bottom line, interviewing is HARD. Some companies have standardized their format to try to eliminate bias, like Google's almost exclusively whiteboard-coding interviews, but I think that's worse in some ways (and still doesn't eliminate bias). It's somewhat subjective, and sometimes a good candidate is just going to have a bad interview with you. All you can do is practice and find what style and what sort of questions get you the type of information that you feel is helpful in making a hiring decision. Also maybe find out if you can do tandem interviews where you and another interviewer team up and combine your time (e.g. 1 hour instead of 30 minutes each). We've recently switched to doing this, and I think it's much better, as long as you make sure to set the candidate at ease. It also saves the candidate from answering the same questions 3-4 times.
That's a lot, I know. It would probably be easier to write it up as an article to share, but I hope it was helpful.