Debug the Way You Hire Software Engineers

Countless blog posts and reddit threads describe how major tech companies conduct frustrating and painful software development interviews. I like to call the unproductive interview habits of big companies “anti-patterns” because they don’t represent actual work or give a full picture of a candidate’s skills and potential.

The common anti-patterns I’ve seen include coding by hand, asking brain teaser questions, having too many interviews, creating a high-pressure environment, and testing candidates with an unfamiliar code base or editor. Each of these common interview tactics are ineffective and risks being highly counterproductive. The good news is that you can debug the way you hire software engineers by learning to represent the way your company and candidates work throughout the interview process.

Anti-pattern #1: Coding by Hand

Many big companies have candidates write out code on whiteboards. I’ve done this before and it can be extremely frustrating,because in a real world work environment nobody codes by hand. Instead, we have candidates code on their own computer which lets us see how the candidate can perform on a daily basis. If you expect pair programming, you should make sure to ask them to demonstrate that skill in the interview. If your internal philosophy is that all new code should be written with test driven development (TDD), make sure you are screening for people who like to use it. By matching the interview to actual working conditions you can clearly evaluate the candidate’s potential and give them accurate expectations for a day in the life as your employee.

Anti-pattern #2: Brain Teaser Questions

Brain teaser questions such as “How many golf balls do you think it would take to fill up Yankee Stadium?” have been popularized by some high-profile tech companies. The goal is to see how people take a problem, think through it, break it down, and reach a conclusion. The problem with brain teasers is that they don’t reflect an issue that a software developer would deal with on a daily basis. Figuring out the number of golf balls needed to fill the stadium is never something they would be asked to do for work. Instead, the problem should be something they might encounter on the job. Instead, ask questions like, “How would you go about getting a list of customer requirements and implementing those features in the code?”

Anti-pattern #3: Multiple Interviews

The three main questions you are looking to answer during the interview process are:

• Can the candidate do the job?
• Can they do it well and in the way that you need?
• Are they a good fit for your company?

These are all things that can be figured out during a one-hour technical interview so why conduct a long series of interviews that add pressure and don’t positively influence the outcome? If you’re a small to medium-sized company, it probably doesn’t make sense for you to fly candidates to your main office and run an interview gauntlet. If your web developers work remotely and communicate on Slack, your interview process should reflect this so that you can fully judge the candidate’s capability to perform the job you’re hiring them to do.

Anti-pattern #4: High Pressure Environment

You’re not hiring sales people who need to perform in high-pressure situations on a day-to-day basis. The vast majority of software developers spend their time working on their computer in an environment where they are comfortable. Since the interview should mimic the real working environment as closely as possible, you should be aware of the pressure a candidate will naturally feel and try to structure your interview process in a way that puts them at ease. For example, conducting the interview over video call will allow the candidate to set up in an environment they are comfortable working in with the added benefit of allowing you to make sure they are able to use technology to work and communicate effectively.

Anti-pattern #5: Unfamiliar Development Environment

Whether or not a candidate can do the job you need them to do at the level you need them to do it isn’t dependent on which editor they use. Having somebody work with an unfamiliar editor or code base during the interview is counterproductive — it’s simply not a situation they will be dealing with frequently on the job. Once hired, they may be introduced to a new one and have to learn it but, they will have time to adjust and it won’t be an everyday occurrence. A candidate’s ability to write code and deliver it to you is much more important than which editor they are using so let them interview with their editor of choice.

Ultimately, we all want hire software developers who can write good code, collaborate successfully with a team, and deliver features that are valuable to stakeholders. The ways these things are accomplished vary from company to company, which is why your interview process should reflect the unique way you work. When you’re reviewing your process, considering what works and what doesn’t, keep whatever represents the work a candidate would be doing continuously at your company and throw away the anti-patterns that don’t.