Changing how I interview engineers in 2020

I began interviewing people for jobs about three years in to my career. Over the past decade, I've run hundreds of phone interviews, Skype interviews and in-person interviews.
Over time, my approach, and what I look for has changed. I've always relied a lot on gut feel, looking for people similar to those who already work for the company (safe bets) or looking for red flags if a candidate does not stand out, but recently my quesions have changed to focus more on how someone approaches their work, rather than what they know right now.

I can clearly see that the questions I'm asking lead to a narrow band of people being hired, and that needs to change. To try and diversify my questions, I'm going to write what my questions were, what they will be now, and what I'll be looking for (just in case I ever interview you). I'll update this post as I update the questions, and I'll give reasons as I go.

FYI, these are the questions I ask on the phone. There's more in the in-person interview that isn't covered here.

Introductions

Question: Tell me about yourself and the project you're working on right now

Change to: Tell me about you, and what drives you/gets you out of bed in the morning

I want you to talk to me. I like interviews to feel more like conversations, and talking about yourself is the easiest thing for many people. Beyond that, talking about what you do, and being able to explain how you made something happen is really important - I like chatty engineers, they work better in collaborative environments such as scrum teams.

The change in this question takes the emphasis from your work to you. Being passionate about your work is good, though it doesn't give me much insight in to your motivation. Whether it is money, status, pride or something else, I don't mind - it'll help me fit you in to a team later on.

Cognitive reasoning

Question: You mentioned you worked with [Technology X], what are the advantages of it over [Technology Y]

Change to: No change here

I'm listening to the answer for the first question or looking at your CV to ask this technology question; these days it's something like React or Angular, and I'll ask you to compare it to the other one.

I want to know how well you understand the technology, how it works and why we use it especially at more senior levels. I also want to know that your knowledge expands outside of your current technology bubble, as your current framework-of-the-month won't be around forever. I'm much more probing on this question with seniors rather than juniors.

In the future, I'd like a version of this question that tells me you can compare and contrast things from your experience.

Question: What is good code to you?

Change to: Scenario question - find a DatePicker component for your project

I was first asked this question by my prospective manager in 2013 when interviewing for Yell. I have gleefully modified it over the years, and it has become my most favourite and important question.

The above question is phrased as a task to find a new component for our project, and to go out on to the internet and find one. Can you tell that the code you're going to introduce into the codebase is any good? Will that code solve more problems than it causes? What processes do you go through (or should go through) to find a good component on the internet?

I want to know that you know what good looks like, because the amount of time that engineers spend working with other people's code these days is mind-blowing.

Teamwork

New question: What do you do when you find a bug in some code? What about if it's a bug in an internal library? What about when it's open source?

At a high level, this is a "dealing with adversity" question, and it's also useful to know if the engineer knows how to file a good bug. How do you react when you can't fix a problem? This will tell me how you approach the open source nature of web work, and how you work with your team, peers and community. I also want to know how far you'll go to solve a problem.

New question: Tell me about a time when you disagreed with a colleague on how to do something. How did you resolve it?

I used to save this for the face-to-face interview, but teamwork is too important to wait until you meet to ask this question. It's a standard question, which many engineers will deny ever having a problem with their colleagues. Perhaps I'm not the agreeable type, but if I don't have a week when I disagree with someone then I've probably been on vacation.

Disagreements happen, it's how you handle it that matters.

Questions that I'm not going to ask any more

What's your favourite feature of the JavaScript language - alternatively, tell me about a JS feature that I haven't heard of

When I asked this question, I got a list of features. I got let and const were a dev's favourite features. Rarely did I get what I was looking for, like generators, optional chaining, Intl.

This question is also obsolete for some newer developers, who have never known ES5 - what they have now is just the language, and it evolved.

So, I'll replace it with a technical question that is still useful: What do Promises do, and why do we need them? - here I'm after knowledge of what async functions do and how they can make coding complex data requests easy

What's the hardest thing to do in CSS?

All I get from this is X-browser compatibility, or people who still use floats for layout

What does accessibility mean to you?

People's answers to this are binary - they know it, or they don't. The majority of engineers fall into the latter category. This question isn't useless, but it isn't a phone interview question.

How do you make a website fast?

Similar to the accessibility question, you get engineers who know it or they don't. This question can easily be saved for the face-to-face interview where we can go into more technical depth.

I hope that explains a bit more about my thought process. If you have questions, send them over to me @steveworkman and we'll chat there. I'll update this post as I add more questions

Interviewing