Making technical interviews better for everyone

Technical interviews are tough for everyone on both sides of the table. Interviewers need to evaluate whether someone has both the technical chops and social skills to fill a particular role on their team. That need often results in mentally taxing puzzles for candidates to work through on a white board, lengthy take-home exams, and a grueling number of interviews with multiple stakeholders. All too often this leaves candidates exhausted before they even start a job—even as hiring managers remain unsure who is, or isn’t, a good fit. 

There must be a better way. I gathered a panel of experts from the developer community with experience both as job seekers and hiring managers to answer your questions about how to make technical interviews work better for everyone. But first, let’s meet our panel of experts:

Dana Lawson is senior vice president of engineering at Netlify. Previously, she led and scaled teams at GitHub, Heptio, InVision, and New Relic. She has more than 20 years of experience leading teams and wearing various hats to complement a product’s lifecycle. With a true passion for people, she brings this mix of technology and fun to her leadership style.

Kathy Korevec is the vice president of product at Vercel. Kathy has specialized in developer experience for over a decade at companies like Google, Heroku, and most recently on the product leadership team at GitHub. She has a passion for the power of open source, perfecting usability of developer tools, and making it possible for anyone to build and ship world-class software.

Ian Douglas is a senior developer advocate at Postman, and live streams free career prep on Twitch. He authored content for techinterview.guide, where he shares 26 years of experience as a contributor and manager in tech. He loves educating and building communities, running workshops, and helping raise awareness of the importance of diversity in tech.

Q: Let’s start with the elephant in the interview room: the whiteboarding exercise. Are there ways to do this well, or is it time to retire whiteboarding entirely?

Ian: I don’t know that whiteboarding will ever go away. It can be a useful tool, not as much for writing out code by hand, but for things like sketching out systems designs. I stopped having people write syntactically correct code long ago, but it can be a handy way for people to explain their thinking on a problem.

Dana: The important thing isn’t whether someone is writing on a whiteboard or typing on a screen or even just talking through a problem. The important thing is what you learn from it. My team tries to make sure the guiding principle is looking for traits, like deep thinking and problem solving. As long as the guiding principles are solid, it doesn’t matter if you give someone a whiteboard exercise or a take-home exam.

Kathy: It’s really important to give people a real problem to solve, regardless of the medium of the exercise. For years, it was trendy to give people complex algorithmic challenges to prove their worth. I’ve always found these arbitrary. They aren’t related to the actual job. When you give people a real problem, you can get a better sense for how their brain works.

Ian: I entirely agree. Technical exercises, whether they’re on a whiteboard or not, should be relevant to the role. I did an interview with a company building a content management system. The technical exercises they gave me involved using APIs to surface data on things like who went to particular pages, how long they spent, or how many times they visited the page. I thought this was an amazing interview, because it was directly related to the work I would have been doing on their analytics team. These sorts of company and team-specific exercises will help candidates demonstrate whether they have skills that are immediately valuable to your team. Otherwise, you’re just testing how well a candidate can regurgitate algorithms.

Klint: What are some of the best ways to evaluate technical skills other than whiteboarding?

Dana: There are a lot of different ways. I think what’s important is to let candidates choose between a few options. Some people think all candidates for a position should be evaluated with the exact same method for the sake of fairness. But it’s more fair to give people the opportunity to do their best work, and what the situation is for that work will vary from person to person. That said, one way to make sure you’re evaluating fundamentals, like technical knowledge and communication, is pair programming. I really like pair programming, because you can get a sense of what it’s actually like to work with someone.

Ian: Pair programming can be good for candidates too, because they get to see what the day-to-day work is actually like. It can work out if candidates honor an NDA, but the last thing you want is a candidate leaking trade secrets.

Kathy: Pair programming is controversial. It can be kind of intrusive, so I shy away from pairing in interviews. One place I interviewed did starter projects. They basically ask you to come into the office and work with the team you’re interviewing with for three days, solve a problem, and present on the third day. I thought it was way overkill, but I loved it as an interviewee, because I got to learn a lot about what the day-to-day would be like. The challenge, and the reason I wouldn’t do this as a hiring manager, is that it’s a really non-inclusive style. Even if you do it remotely, you’re asking people to take three days of their time for an unpaid interview. It’s a lot to take on as a candidate.

Dana: That’s right. That’s why it’s important to give people choices. Just because someone isn’t comfortable with pair programming, doesn’t mean they aren’t a good programmer or aren’t a good fit for the role. You should give them more than one way to shine. And I can say as a working mother, there’s no easy way to find time for a multi-hour take-home test, let alone a three-day “trial run!” You don’t want to test how much spare time someone has. You want to find out whether they’re a fit for your role.

Kathy: I have people walk me through their portfolio and tell me why they made certain decisions, as well as how they solved different problems along the way. 

Dana: Yes! I prefer to have technical conversations, rather than whiteboarding exercises. If the candidate has an open source project, I like to walk through their code with them. Conversations can be just as useful and revealing as exercises, if not more so. And they’re usually less stressful for candidates. Plus, you learn more about their communications skills. 

Klint: Given the wide range of possible exercises, what would you recommend to candidates to prepare for interviews?

Ian: Practice writing pseudocode and breaking problems down into smaller problems. Interviewers are generally looking to get a sense of how you think and solve problems, so it’s good to get comfortable showing your work, so to speak. I typically coach people not to jump right into code during an interview, even if you’re doing a coding exercise. When you show your planning process, it will help the interviewers learn about you, and it will probably lead to writing better code..

Kathy: Try to find people who work at the company, and find out what the interview process is like. Talk to customers who use the company’s product to get an idea of what they like and what they would like to see improved. Read app store reviews. Get a sense of what people are saying about the company and their products. Coming into an interview with data is very impressive to me, because it shows you’re serious about the role. As a candidate, I like reading things that the leadership at a company has written, from blog posts to tweets. It reveals what they value and how they represent themselves, which is a reflection of the work culture.

Klint: What sorts of things do you see as red flags when you’re interviewing a candidate?

Dana: A lack of curiosity. I expect candidates to be asking questions about the role, the company, the technology we use.

Kathy: Yeah, not asking questions is a big one. Candidates should spend time familiarizing themselves with the company’s products and have some specific questions and ideas in mind. Another red flag is when someone gets really defensive about a question.

Dana: A lack of curiosity. I expect candidates to be asking questions about the role, the company, the technology we use..

Klint: Remote interviews seem like they’re here to stay for the foreseeable future. How is that changing interviewing, and what sort of best practices do you recommend for remote interviews?

Kathy: Remote interviews open up some exciting possibilities, like the opportunity for candidates to share their screens with interviewers and show them how they work. As an interviewer you can see their IDE and get a glimpse of how they work and see what’s going to make them successful at your company.

Dana:  Start with the basics. Prepare the area. Ideally interviewers won’t judge you by your surroundings. Having a messy home shouldn’t be a factor. But let’s face it: You probably will be judged for that, so do your best to present well.

Ian: Just like an in-person interview, you should show up early. Don’t wait until the last minute to join the call, join several minutes early. That gives you time to work out any problems or make necessary adjustments, though you should do as much of that in advance as you can. You might want to restart your computer, or your WiFi router, an hour in advance to make sure everything will be stable for the duration of the interview. Close all the applications you don’t need for an interview. Remember that for a remote interview, good audio is more important than video, so be sure to deal with any potential sources of noise. If you can invest in a good microphone, it’s worthwhile. Have a contingency plan: a way to dial into the conference if all else fails, for example.

Klint: Any other thoughts or tips?

Dana:  It’s worth investing in getting better at conducting interviews. You should train your team in interviewing. You can’t expect to be good at doing interviews if you don’t practice. If you are hiring a lot, it is easy to get complacent and not deep dive into all the important areas versus running down a checklist of questions. Role-playing for interviews is a great tool to prepare a person to conduct an interview. Meanwhile, this gives candidates insight into who they will be working with and how people show up at the workplace, and whether they share the same values that are important to you personally.

Ian: This is contentious, but when the interview is over don’t be afraid to give feedback on what candidates did well. Hopefully they can read between the lines and figure out what they didn’t do well. Sometimes interviewers are told “don’t give feedback for any reason.” But it doesn’t feel good to not receive any feedback. It’s especially important for entry-level developers to get feedback, otherwise they’re not going to get better.

The ReadME Project is a GitHub platform dedicated to highlighting the best from the open source software community—the people and tech behind projects you use every day. Sign up for a monthly newsletter to receive new stories, best practices and opinions developed for The ReadME Project, as well as great listens and reads from around the community.

Written by

Klint Finley

@klintron