Designing a Software Engineer Interviewing Strategy
Parker Phinney
JAN 21, 2016 15:36 PM
A+ A A-

Designing a Software Engineer Interviewing Strategy

by Parker Phinney

Hiring software engineers is hard. A poor hire can easily drag down an entire team. But an excellent hire can be an order of magnitude more effective than everyone else--a “10xer.” How do you know if a given candidate is a 10xer or a total dud? You need a carefully designed interview strategy that lets you learn as much as possible as quickly as possible.


Despite what you might read online, there’s no “one size fits all” strategy for interviewing effectively. Different companies have different engineering challenges, communication styles, and cultures. So we’re going to treat designing a software engineer interviewing strategy as two distinct steps:

  1. Rank the skills you’re looking for in order of importance.

  2. Choose the types of questions that most effectively probe the skills that are most important to you.


Step 1: What skills are you looking for?


Here are the skills you might be looking for in your software engineering hires. This list isn’t exhaustive--you may want to add your own. But keep this in mind: you can’t have it all. People who are amazing at everything are sometimes called “unicorns” … and they’re called unicorns because they don’t exist.


So take some time to carefully rank these skills by importance to you. Know the difference between needs and wants. Identify your top 1 or 2 skills you need in the engineers you hire.


Communication. When the candidate explains a technical design, can you understand them? When you explain a technical design, can they understand you? If you had a tricky problem to solve, would you find it helpful to chat with them about it?


Knowledge. Are they intimately familiar with the programming language(s) and/or framework(s) they’d need to use on the job? Do they know the best practices for the problem space they’ll be working in? For some companies this type of knowledge is essential, especially for a more senior engineer who’ll be leading other engineers. Other companies think these things can easily be taught.


Problem solving. Can they apply their knowledge to solving new problems they’ve never seen before? If the team faces a new kind of technical challenge, can you trust this person to come up with a good solution?


Resourcefulness. Do they know how to research to learn what they need to know to solve a problem? If you give them a problem that involves using a new technology, new API, etc, will they be able to figure it out themselves or will they ask lots of questions and drain other engineers’ time?


Teamwork and Cultural Fit. Will they make work fun and elevate the spirits of the whole team, or will they cause friction and make people dread coming to work? Will they be helpful or hurtful in meetings?


Step 2: What questions test for the skills you’re looking for?


Once you know what skills you’re looking for, it’s much easier to design interview questions that test for those skills. Here’s a sampling of common types of interview questions, along with some notes about which skills each one is good or bad for.


Algorithmic coding interview questions. This is how Google, Facebook, Amazon, etc like to run most of their interviews. These are “case-based” interviews where the candidate is asked to write an algorithm (and, usually, code) that solves a given problem. These interviews are generally heavy on data structures and algorithms, with special attention devoted to time and space complexity (big O notation).


These interviews are great for testing communication and problem solving. Questions should be carefully chosen to be quite difficult. This gives the candidate ample opportunity to “think out loud,” explaining their thought process and receiving and reacting to hints. This affords lots of visibility into their communication skills.


Technology-specific coding interview questions. Here are some example Java interview questions, and some examples in JavaScript. The idea behind these questions is to see if the candidate has an intimate knowledge of the language.


Most technologies have quirks, and knowledge of these quirks can be a strong signal for how familiar a person is with the technology. But these questions can also get at something more subtle: whether the candidate is someone who simply throws code at the wall until things work, or if they really understand how things operate. Take string literals vs. string objects in Java for example--both will usually “work” just fine, but they have differences that become more significant as performance and reliability become more important for an application.


Ultimately, these questions mostly test knowledge. If your engineering management structure already allocates time and resources for educating new hires on the technologies they’ll be using (through formal training or more casual things like mentorship and code reviews), this question type might not be for you.


System design and scalability. These questions are especially popular for interviewing senior engineers and engineering managers, who may have to do more system design work. Here are some example system design questions.
 

These interviews can test specific knowledge of technologies and best practices relating to scaling. They can also test problem solving if the requirements of the problem are sufficiently novel. Like algorithmic coding interview questions, these give some strong insights into communication as well, in the course of the design discussion.


And because these questions can be somewhat open-ended, with several good answers and no perfect best answer, they can help weed out folks with teamwork issues--in other words, it’ll usually become obvious in the course of a design discussion if someone is argumentative or defensive.


Coding “homework” or on-site project. With these interviews, you give the candidate a project to do either at home on their own time, or in your company’s office space for a few hours. There are several software tools for assembling take-home challenges, like HackerRank. These interviews are sometimes thought of as a reaction to the algorithmic coding interview, which some people see as unnecessarily high-stress.


The biggest strength of this type of interview is it closely mirrors the real day-to-day of being an engineer. You’ll spend less time talking with the candidate, so you’ll learn less about their communication skills. But you might learn more about their resourcefulness--when you leave them alone to work and tell them to come to you if they have any questions, you’ll get a real sense for how much support this person will require based on how many questions they ask and how well-researched their questions are.


These interviewers save your engineers’ time, because they don’t have to be with the candidate while the candidate is doing the interview. But for this reason, some candidates find these interviews off-putting and will choose not to interview when you send them homework or ask them to come onsite and “do work for free.”


Discussing past experiences. Many companies like to start with this, because it’s usually more relaxing for the candidate to talk about things they’ve done before. But this kind of question is good for more than just relaxing the candidate.


You’re likely to get some insight into communication no matter what you ask. But in particular, consider asking questions that get the candidate to focus on a time they solved a problem they initially didn’t know how to solve. This should give you some insight into problem solving and resourcefulness.


The number of options for how to interview can seem overwhelming. That’s why it’s essential to start with deciding on the skills you’re looking for. Remember: you can’t have it all! Pick the top 1 or 2 things your engineers must have. From there it’s much easier to evaluate the effectiveness of each interviewing strategy. Good luck!


Parker Phinney is founder and CEO of Interview Cake--a study tool for software engineers preparing for programming interviews.

 
FIRST
PREV
NEXT
LAST
Page(s):
[%= name %]
[%= createDate %]
[%= comment %]
Share this:
RESET