What are some good interview questions that you have asked or have been asked?
What resources do you use to come up with good questions?
I am not asking for take home work, or whiteboarding questions. I am looking to distinguish between someone who knows their stuff, willing to learn, and adopt good practice versus someone who is can word vomit hot tech terms in an interview.
Top comments (13)
Here are a few from our lists based on a recent process....
A few about communication, adaptability, working styles.
About JavaScript.
Those are great suggestions @ben ! For my exact use case we have a set of good behavior based questions, we lack any technical questions. I think historically this is because we let their credentials (degree/experience) stand for that.
I Like the JavaScript questions, its dipping a toe into the technical side still much from the behavior perspective. I can definitely work from those!
@ben I love that you emphasize async communication. Not nearly enough bosses do.
It's hard to talk about your job when you don't have a support for it.
Something I have found very good is to propose a pull request where you intentionally wrote lots of bugs and bad practice, and ask the candidate to review it.
This is a very interesting idea. I quite like it.
Agreed, this is a great way to get some insight into how the candidate thinks, and it’s also arguably a better way to be sure that they understand the language than all these coding tests people do (it’s not hard to learn to write code in a language, but it’s often quite challenging to learn to recognize good code in a language and understand how to improve upon bad code to make it better).
One of my all time favorites:
"Anger gets a bad rap, but it can be a window into what we value. What's something that upset or frustrated you at work recently?"
That is an interesting one. I can say that if something work related it is something that I am passionate about, and I generally get fired up because something that I am passionate about the others involved have little care.
"What have you done outside of [role applying for], and how would you say it makes you a better [role]?"
For example, I'm dead serious when I say that I use more of what I learned at Starbucks or waiting tables than in two relevant degree programs (IT and development, both completely worthless).
"If you could launch any product you want, what would it be?"
Now that I'm "recruiting" or forming partnerships with co-founders (technical and non-technical) rather than hiring specific dev roles, this is at the forefront of my mind; however, it offers great insight into dev candidates' creativity (and opportunities to maximize their motivation) as well. Especially useful if you offer anything like "20% time," which can drive incredible innovation. Also, I want to encourage my devs to have a voice in product.
I used to recruit for Oracle practitioners, mostly for data warehousing/BI roles, and had two open ended questions that I'd regularly use.
deleteandtruncate?Both of these could be the subject of a considerable article - in fact the latter could be an entire book - and I'd usually ask prospective applicants to write something up before an interview and send it over, and it was a very good applicant sieve.
After I stopped working primarily on databases I wrote up the truncate vs delete as a Stackoverflow Q/A. stackoverflow.com/questions/139630...
For the query performance question, I was always hoping for something that mentioned indexing, clustering factors, table size, partitioning, query rewrite, correct use of data types, caching, hardware issues, parallel query, optimiser goals etc.. I was usually disappointed, though.
My questions for candidates are designed explicitly to show me how they think.
They are often open-ended and highly subjective. My goal is not to determine what the correct answer is, but to evaluate how they arrive at any answer.
Most recently, that might mean asking them how they would prepare for a new freelance project with no background information.
I'd be looking for things like how they read documentation, how they test and scale, how they interact with clients, and how they keep themselves organized.
I mostly just want to hear them talk. I want to measure their confidence in themselves and what they know.
Every now and then I'll throw a curveball, but the idea is to never force a "gotcha" moment, but to instead work through with them how they might rectify their mistake.
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.
Open the HTML source of {Twitter, Facebook, Reddit, dev.to} and explain what each of the first 10 lines means.