DEV Community

Cover image for What are some good Interview questions?
Waylon Walker
Waylon Walker

Posted on

What are some good Interview questions?

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)

Collapse
 
ben profile image
Ben Halpern

Here are a few from our lists based on a recent process....

A few about communication, adaptability, working styles.

  • Your priorities are not always going to be cleanly described to you. How do discover priorities and communicate your workflow to your manager?
  • How do you handle asynchronous working styles and the communication concerns that can be introduced?
  • Tell us how one of your projects suffered a setback due to an unexpected change in circumstances.

About JavaScript.

  • Could you talk about a recent accessibility issue you worked on and what you learned from it? It can be any aspect of accessibility.
  • Could you explain asynchronous programming in JavaScript? What are some ways you can make things perform better in JavaScript?
  • Do you think code style linting tools are important and why?
  • What is the most common npm package you add to most of your code and why?
Collapse
 
waylonwalker profile image
Waylon Walker

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!

Collapse
 
stereoplegic profile image
Mike Bybee

@ben I love that you emphasize async communication. Not nearly enough bosses do.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

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.

Collapse
 
waylonwalker profile image
Waylon Walker

propose a pull request ... ask the candidate to review it.

This is a very interesting idea. I quite like it.

Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn

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).

Collapse
 
q0rban profile image
James Sansbury

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?"

Collapse
 
waylonwalker profile image
Waylon Walker

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.

Collapse
 
stereoplegic profile image
Mike Bybee

"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.

Collapse
 
slimdave profile image
David Aldridge • Edited

I used to recruit for Oracle practitioners, mostly for data warehousing/BI roles, and had two open ended questions that I'd regularly use.

  • What are the differences between delete and truncate?
  • What factors affect whether a query runs quickly or slowly?

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.

Collapse
 
brandinchiu profile image
Brandin Chiu

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.

Collapse
 
bloodgain profile image
Cliff • Edited

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.

Collapse
 
maxart2501 profile image
Massimo Artizzu

Open the HTML source of {Twitter, Facebook, Reddit, dev.to} and explain what each of the first 10 lines means.