5 Things You Need To Stop Doing in Interviews

Some guy on the internet tells you some things he’s learned, or something.

5 Things You Need To Stop Doing in Interviews
Photo by Daniel McCullough / Unsplash

Finding the right people is hard. I get it; I’ve done my share of interviewing from both sides of the table. But we’re making it harder on ourselves than it needs to be. We have adopted practices and ideas that are actually hindering our ability to attract top talent and weeding out engineers who would otherwise be incredibly valuable members of our teams. Here’s a few ways that we can shift that mindset.

Degrees don’t mean anything, not really

As a whole we place too much importance on formal education, the reality is that it doesn’t mean anything outside of an academic setting. Even if someone majors in a field that is relevant to their career they lack the one thing that everyone else in the field has: experience. No degree — not even computer science degrees — can make up for a lack of experience; knowledge without the wisdom of how to apply it is worthless. Additionally, using a degree or other educational milestone ignores the socioeconomic impact that formal education has on an individual. Degrees are expensive and not everyone can afford to get one, even with taking on massive amounts of student debt. It’s not just slackers and drug dealers that drop out of school, students discontinue their education for a myriad of reasons. Some drop out because of family obligations, like having to return home to care for a sick parent or work the family farm. Some drop out because they have to work full time in addition to school and don’t have the time, energy, or health to continue doing both, and since work pays the bills it’s the school that gets left behind. Some drop out simply because they hate formal education and thrive in more trade or career-focused environments. There’s an infinite number of valid reasons to not start or finish college, ignoring those reasons is both unfair to your applicants but also shrinks your overall pool of candidates to pull from, ignoring those who could be incredible talents.

Do this instead: Look for self-improvement

What you ultimately want are people who will continue to grow in their roles after you hire them. Hiring people who believe they have “arrived” and have no desire to learn new things or improve themselves will be a detriment to their teams as they lack motivation and self-awareness. Instead of screening candidates based on education, look for those who take the initiative to learn and explore new ideas, concepts, tools, languages, software, etc. in their free time. Engineers who are endlessly curious will push the boundaries of their projects, want to know the “why” of things, and always look for ways to improve whatever they are working on. Those are the kinds of people you want.

Whiteboards exist only in alternate realities

Whiteboard interviews suck. They really do. Why? Because they don’t reflect the reality of software engineering. When was the last time you, as a developer, sat down to write a function or solve a coding problem without a compiler (or interpreter), documentation, linting, code completion, internet access, IDE or text editor, or even a computer? Gone are the days of mainframes and punch cards where code was written out by hand and manually debugged before being fed into a giant machine, then you prayed to whatever deity you worship that your code was bug-free. You should never evaluate candidates in environments where they won’t ultimately be working. Performance in an interview environment has no real bearing on future performance in a real development environment. Just like there’s techniques to testing well, there’s techniques to whiteboarding well. Anyone can memorize 17 different iterations of FizzBuzz or how to invert a binary tree, but not everyone can and does work well in a real development environment with real problems to solve.

The same goes for online coding challenges, too, not just whiteboard interviews. Online code challenges are artificial environments where unreal constraints are placed on the engineer: time limits, available libraries, documentation, etc. With online challenges, too, there is a trend to test on more algorithmic knowledge than problem-solving ability. Being able to find sets of integers that are n-numbers apart that don’t overlap is interesting and all, but how many times are you going to actually run up against a problem where the solution required that kind of a solution? I would argue that most real-world programming challenges revolve more around logic and data transformation rather than number theory. Additionally, if you were to run into a problem similar to it “in the wild”, you’re going to have more than 45 minutes to get it done.

Do this instead: Give take-home tests or one-day internships

Because you want to find engineers who can excel at the job and not just on a whiteboard, try giving take-home tests or challenges or even doing single-day internships. With take-home challenges you give your candidates the opportunity to solves problems at their pace, in their way, with the tooling and environment they’re comfortable with. They also give you more flexibility as to the kinds of problems you can have candidates solve. You don’t have to focus purely on short, relatively simple functions like you would with whiteboard tests, you can have them write an entire application if you wish.

A better solution, one that acknowledges the time commitment that interviewing and doing coding challenges takes, is offering a one-day paid internship to your candidates. Yes, this makes your acquisition cost for each employee higher, but the overall quality of candidates you hire should be higher as well. Allowing candidates to spend a day in your ecosystem, get a feel for the office and culture, as well as solve problems in a real-world environment, allows the candidates to put their best code forward and allows your company to objectively evaluate each candidate.

Standardized interview questions are for losers

Now, don’t get me wrong, some standard questions can be good for getting benchmarks on a candidate. There’s some things you have to ask that are universal, questions like “are you able to reliably get to and from the office” and such. But once you get into the technical part of the interview, asking the same questions to every candidate can cause problems. Every candidate might be able to tell you what a linked list is, or what a pointer is, but what you’re going to get is the textbook answers. Using canned questions for interviews is not only unfair to the candidate but also unfair to the company: you’re looking for people who have the ability to do a job and not answer a set of questions.

Do this instead: Drill down into something they know and see how far down their knowledge goes

Candidates send in their resumes for a reason, you should use them. Too many hiring managers simply ignore the resume assuming that the recruiter or whoever did the phone screen weeded out the “bad” candidates, when in reality what you should be doing is using the candidate’s resume as a point of reference for what you’re going to ask in the interview.

If you walk into an interview and a candidate’s resume says they’re an expert in Docker, drill down into what Docker is, how it works, and the implications of its architecture on things like security, operations, applications, and everything else. If they’re a Python expert, get down into the weeds and talk about the global interpreter locks and multi-threading, what that means to the interpreter, and how to write Python apps that work around its limitations and play to its strengths. You should drill down until you either hit gold or the candidate says “I don’t know”, then use that “I don’t know” as an opportunity to teach the candidate the knowledge they’re missing. Not only does this allow you to find out exactly what they know, but you also get to see how they incorporate new information into their paradigm. If a candidate doesn’t know what Python’s GIL is, teach them, then ask follow up questions that logically follow from that new information. You’re looking for plasticity in their thinking and how they process new information. Good engineers can take new information in real-time and use it to solve whatever problems they’re working on. This is how you find those kinds of people.

Stop being so nice

I’ve garnered a reputation at my day job for being “the mean one” in interviews. It’s not because I’m rude to candidates or choose not to have genial conversations with them, though, it’s because I ask hard questions and I expect answers. I take the time to look at a candidate’s resume and pick out one or two core things they claim to know, then I drill down to see exactly how well they know them. If a candidate claims to know Python then I dive deep on Python, asking about the GIL, threading, list comprehension, and other things that a seasoned Python developer should know.

Do this instead: go hard or go home

Figure out what the position’s core competencies are and hammer those down. Then use those points as a basis for evaluating candidates. If a position calls for Python then get deep into the weeds on Python, if it calls for Docker then get deep into the weeds on Docker — find out how deep their knowledge is. If there’s something that candidate doesn’t know then help them out and fill them in then watch to see how they incorporate that new information. Ask questions based on that new information and make them hard. If you’re not willing to ask the hard questions now you will only be asking them after you’ve already hired someone that might not fit into the role.

Taking notes is a distraction

Interviewing is an important process and you want to make sure you have reliable data on every candidate that you interview, I get it. But taking notes while interviewing a candidate can lead to an interviewer more focused on the notes than the candidate. Alternatively, you might not take notes at all and “go with your gut”. Some people are very very good at this, but I’d be willing to bet that most are not. Speaking from experience, the more you can focus on the candidate and having a conversation with them rather than it feeling like an exam the better your interview is going to be. You get to see more of the candidate’s personality (which is very important!) and hopefully let them relax a bit.

Do this instead: record your interviews**

Every phone and laptop has a built-in audio recorder app, use it. Sit down, hit record, and conduct your interview knowing that you can come back and dissect everything later. If you work somewhere that requires you to submit interview notes as part of a formalized system this can be immensely helpful. However, if you live in a state that requires both parties’ consent to be recorded, always get your interviewee’s consent. The last thing you want to do is illegally record interviews; it’s illegal and its shady, don’t do it.

Have any tips that I missed? Let me know in the comments below!

** Always consult your local laws before doing this, and never illegally record people. I am not a lawyer and this is not legal advice.