Good and bad engineering interviews

I’ve had a lot of jobs, which means I’ve had a lot of interviews and interviewed a lot of people. Hiring is SO difficult, so I’m not going to tell you how to do it, but I can tell you about my personal experience with different formats and how other people feel about them.

Some things to keep in mind when choosing an interview format:

• Define the skills you want to evaluate first instead of choosing your interview format. Each format has its limitations; you don’t want to formally establish a process and then Frankenstein it later when you realize you’re not evaluating some skill effectively.
• Set expectations for what makes a successful technical screen. Is it okay for the candidate to trade readability for performance? What kind of comments from the interviewer should be categorized as nitpicks and not negatively affect the candidate’s overall feedback? How will you know if the candidate is struggling? Decide before you start interviewing so you can assess each candidate equally.

No interview format is perfect and you will inevitably miss some good candidates, but what’s important is to be intentional with your interview process and be aware of its pros and cons.

Disclaimer: These are my opinions. And if you don’t want opinions… I don’t know what to tell you. This isn’t AP News.

Whiteboarding

This is a classic engineering interview format, and it means different things to everyone. To me, “whiteboarding” means live-coding an algorithm problem, usually one that’s taken out of Cracking the Coding Interview. You’re doing these in front of an interviewer, on an actual whiteboard or in an editor. The standard dance of being successful in this interview is to first do some kind of brute force-y solution (bonus points if it’s already really good on the first try), then to optimize it for time and memory efficiency.

Whiteboarding may be suitable for companies with internal tools and languages, and the candidate’s knowledge of, say, the latest updates to React hooks is largely irrelevant. It gives candidates from prestigious computer science programs a leg up, since some of the top schools have classes specifically designed to prepare students for whiteboarding interviews.

I’m not a fan of whiteboarding. You’re immediately eliminating people who have not “studied enough,” and when have we ever had to apply memorized knowledge in our real work as software engineers? You’re not evaluating problem-solving skills, which, I would argue, is a core skill that every software engineer should have.

Some tea: I know this person who worked at a FAANG company for over a year. They didn’t know how to code, but studied whiteboarding questions and aced the interview. When it came time to actually work, they couldn’t do it, so they brought their work home to their roommate, who worked at the same company, to do it. This is the big risk with whiteboarding interviews.

Presenting code

Ugh, just stop it with asking candidates to present code in any form. I don’t care if it’s their take-home project or something they’ve worked on at a previous job or as a hobby, just stop it. As an individual contributor, when have any of us ever had to present a 500-line code review? You should be evaluating them on something that actually matters to the job, and presentation skills are very different from communication skills.

Online coding challenges

Not a fan. I’ve often done this in the form of challenges on HackerRank or Hired.com, where you have some specified amount of time to do some number of algorithms. Some employers will just see if your code compiles and passes tests, others will watch the recording, so commenting your code is really important.

One time, I had a job in the bag (I had great meetings with the hiring managers, product managers and other ICs) until I had to do a really dumb problem where they ask you to create a program to calculate soccer scores in SQL. As an extremely frontend-y, CSS person I was like, are you kidding me. I struggled on it for 45 minutes, it didn’t compile, and I didn’t get the job. I’m over it now, but at the time I was devastated and cried like Sarah Paulson.

Online coding challenges have all the same cons as whiteboarding, with the added con that you can’t even communicate with your interviewers. There’s also the rule that you should not cheat, which, duh, but when you focus out of your current tab to look up some syntax, there’s a warning to please do not navigate out of this window. And I don’t know about you, but I can’t remember any array methods under pressure. It’s incredibly limiting in what you can evaluate, but it is relatively quick and convenient. You’re able to make fast decisions on candidates, but are these the right decisions? Who knows?

Take-home project

This is when I take out my inclusivity megaphone. Grab a snack and take a bathroom break before you continue.

The take-home project usually involves a set of instructions on what the candidate should implement, with or without boilerplate (most companies I’ve interviewed with do not give boilerplate, so setup time is also a factor) and a suggestion of how much time the candidate should spend on the project. I’ve only done unpaid take-homes, although I have seen some companies pay their candidates for this work.

The big flaw with a take-home project is that it heavily favors candidates who have unlimited free time and access to a computer. Anecdotally, take-homes take 2–3 times more time to complete and polish than the employer recommends. I’ve been in interview discussions where we’ve asked the candidate to not spend more than 4–6 hours on a project, they spend well over 10 hours, and the hiring managers wonder, will scope-creep be a problem for this person? Well, news flash, if a project sucks after six hours, they’re not going to submit it.

So, why is favoring the unlimited free time and access to a computer a problem? You’re potentially excluding people such as:

• Caregivers. If you care for someone else in any capacity, self care (which often includes eating and showering), rest and SLEEP become top priorities for the little free time you have in the day.
• People who are experiencing financial hardship. You may not own your own computer, and accessing a public computer may be very difficult.
• People who work multiple jobs or non-9 to 5 jobs.
• New grads, bootcamp students or those who are self-taught. We often pursue a career in tech because it’s a promise of a better financial future, so see above. For about a year after I finished my bootcamp, I worked a holdover job, worked a second job for six months and took classes online.

As the employer, reassuring your candidates that they will not be punished for “only” spending the recommended amount of time doesn’t really do anything. As candidates, we all know that there are going to be others who can do more, so we have to compete with them.

There’s also the issue of people spending entirely way too much time on the project and being really proud of that. I’m wary of those candidates, because they celebrate the idea that working overtime is a badge of honor, and that can lead to some serious burnout (not the candidate’s fault and more of a reflection of how work life is glorified in the U.S.). I would rather hire someone who can set boundaries for themselves, takes breaks when they need to and has the self-awareness to build a good work-life balance. Those are valuable, scalable skills and establishes good culture in a team.

So yeah, I have lots of thoughts on take-home projects. They can be a slippery slope. Online coding challenges definitely wins in terms of time commitment for both the employer and candidate, so pick your battles.

Pair programming

I’ve had debates about what pair programming is with people. Some people conflate it with whiteboarding, and to some people, coding in front of other people in any form is whiteboarding. I think the key difference is how the interviewer makes you feel; whiteboarding tends to feel more like a test, while pair programming feels more like working together, and if you’re able to make a candidate feel comfortable, they’re more likely to do better and be more communicative with you because nerves are less in the way. This is pretty vague and subjective and I would hate to be the recruiter who tries to describe this to the candidate, but it’s like when you spend time with someone you really like and you walk away thinking, “omg I think that was a date!”

A few years ago I had a pair programming screen with the hiring manager and the exercise had a simple premise: I will tell you what the code is doing, and you tell me how to write a test for that. The HM is the one writing code, not the candidate, and the candidate just needs to tell the HM in simple terms how to write the test. It evaluates the candidate with the notion that previous knowledge of the language is not important, because that can be learned, and focuses on a core skill that the organization finds important: empathy. By “empathy” they mean, if I communicate something to you, do you know what I’m trying to say? This quality is so important for team chemistry, and informs how this person will work with existing employees. This is a principle I’ve taken to other jobs because it’s so important. Instead of “culture fit,” evaluate “communication fit.”

I find that pair programming is the most direct way to evaluate the skills I find most important in software engineers, which are problem-solving and communication. But not every company needs engineers who are strongest in these skills, and it is a very time-intensive way to screen candidates and probably not the way to go if your goal is to grow your company quickly. YMVV.

Interviewing is one of my favorite things to talk about (like literally, ask my husband how excited I am by it) and I’ll always strive to perfect it. I hope you learned something! Like and subscribe!