Conducting the Technical Interview

I vividly remember my first interview as a manager. My hands were shaking as I led the candidate up the stairs to the conference room I had booked. When we got there, I went into a panic. What if I don’t ask a vital question? How do I even know what the vital questions are? What if I hire him and he’s completely unprofessional? How can I tell if he really knows JavaScript? Wait a second—does he have a prosthetic leg? Did I just take a candidate with a prosthetic leg up the stairs? Oh no, I’m failing this interview already!

Even if you’re familiar with the basics of interviewing, technical interviews can be nerve-wracking. Whether you’re a new team lead or you’ve been in leadership for years, concerns and insecurities like the ones I had in my first interview can haunt you, and even well-established interview processes can fail to adequately screen candidates.

Interviewing for technical positions is, in many ways, a balancing act. You look at past, present, and future; you look at soft skills and hard skills; you have to think as both a buyer and a seller; you even have to worry about company image and reputation management. There are some basic things you can do to keep that balance and best represent your company.

Define the ideal role#section2

I’ll admit, for my first round of interviews, all I was looking for was someone who could tick off all the technical skills on a checklist. As I progressed in my management career, I started to learn that I never looked for the same person twice—each time I had an opening, the team had different needs, and I had to take those into account when hiring someone. Even though the job description for a front-end developer didn’t change much each time, my expectations for the ideal candidate did. That gap between the job description and the ideal role tripped me up for a long time.

Before you start interviewing, you’ll need a solid written description of what you’re looking for in an ideal candidate, beyond what job postings typically go into. The job posting may say Senior Front End Developer, but if you need someone to be your CSS animation specialist and help define standards and best practices—whether now or in eight months—you’ll need to take that into account when hiring.

Be future-oriented with your description: ask yourself what happens when the employee outgrows his or her role. Could this person be a supervisor, or would they even want to be? Is there an opportunity to be a technical leader or architect at your company, if that’s the route this person chooses? Could this person one day replace you? (Remember, you’re probably not getting promoted until there’s someone to take your place.) If you have no answer to the question of what happens when an employee outgrows the role, the answer is usually found at another company.

Also ask what happens if the team continues to grow. Does this person have the aptitude to pick up new skills and responsibilities as needed? How will this person respond to change? What if you have to put this person in front of a client? At a healthy company, growth is inevitable, both in size and scope. Your definition should describe someone who can grow with you and not get left behind.

Define not only the technical skills, but also the soft skills needed for the role you have in mind. If you need someone to take the lead on collaborating with the Creative team, you’ll need to define what would make an employee successful in that role and hire for that. This can actually be more important than the technical skill requirements. Technical skills can be easily trained—soft skills cannot.

When you do all of this, you’ll have a list of expectations for a role that probably won’t fit in a job posting. When appropriate (don’t make promises of growth), test those waters with the people you’re interviewing. Even if you determine a person would be good as a trainer, they may not want to do that, which can be a nasty surprise if you hired the person with the intent of them growing into the role a year down the road.

Once you know what you’re looking for, the next step is getting them to want to work for you.

Sell the job#section3

The saddest interviews for me are the ones where I find that ideal candidate I envisioned and they get away. Sometimes, they just get a higher salary somewhere else; but sometimes, they decide that they don’t like the company and want to keep looking. Both are sad, but either way, getting candidates to like your company is always in your best interest.

Remember, when you’re interviewing someone, they’re also interviewing you. Don’t ever assume that your company is the only place a candidate is interviewing. It’s true that some people walk in the door with their minds made up, but many are still deciding whether they want to work for your company—and the better the candidate, the more options they’re going to have, so the more you’re going to have to sell to win them over.

So how do you sell a job? A salesman will tell you it starts with knowing three things really well: the product, the competition, and the customer. The product is your company: benefits, compensation, culture, type of work, amount of work, and even location. The competition is any local business that hires similar types of people, and you’ll need to know the same things about them that you do about your own company. The customer is the job applicant. Knowing each of these things well and being able to compare them is key to winning the best candidates.

Do your research not only into your own company, but your local competitors. What are your competitive advantages? What are theirs? (If you think a ping pong table is a competitive advantage, you’ll probably need to dig a little deeper.) Sometimes it’s not about what you have so much as what the competition doesn’t. If you’re seeing a lot of interviewees from a competitor, find out why and see if you can use that factor to sell your company.

Learn what prospective employees are looking for in a job. There will likely be some commonalities. If you’re losing top talent because you don’t offer a benefit or they don’t like your processes, you’d be wise to revisit those. Just like the technology in our industry is constantly changing, the expectations and needs of our employees are also changing. Don’t fall behind with what you offer to your employees.

Almost every candidate will have questions about what the work environment is like. You should have a little elevator speech to sum up your answer and sell your company in a minute or less. You may actually want to lead the interview with that speech to get those questions out of the way and get the candidate excited for the position before you start finding out about them.

Lastly, be authentic with your interviewees. Don’t try to spin a weakness as a strength, because most people will see right through that. If you don’t believe in your company enough to be totally honest about it, why should they believe in it enough to work for you? You don’t need to hand them a comprehensive list of everything that’s wrong with your company, but don’t shy away from questions along those lines, and don’t try to reframe a shortcoming as a strength. As an example, if your company has a reputation for burning some people out, that’s important, but you can talk about the type of people who do well there rather than the people who don’t. It’s better that people find that out in the interview than after three months of training.

Hire a person, not a code machine#section4

In my five years as a supervisor, I only had to fire two people. Want to guess how many of those were because they lacked technical skills? Zero. In both cases, the employees didn’t work out for non-technical reasons.

There are a number of non-technical factors to look for in a candidate: personality, fit with the team, communication skills, openness to change, leadership potential, and a host of others. (That’s the real reason you’re conducting an interview and not just asking for test results.) These details don’t magically reveal themselves in the technical portion of the interview—you need to ask about them.

Create a list of standard questions for candidates. Questions should be open-ended and answered with a story. Examples include:

• Tell us about a time when your good communication helped to solve a problem.
• Tell us about a time when you disagreed with your supervisor and what you did about it.
• Tell us about a time you successfully described a technical concept to a non-technical person.
• How would you explain inheritance to a junior developer?
• Tell us about a recent time you learned from a mistake.

Order is important: ask the non-technical questions first. The technical portion of the interview can make some people nervous, and you won’t get a good gauge of who the candidate is if their thoughts are fixated on the technical questions they missed.

Putting thought into screening for soft skills is vital. But remember that this is a technical interview—you have to put just as much thought into screening for technical talent.

Stick to the standards#section5

And I’m not talking about web standards. If you’re not asking all developers the same questions, there’s a good chance you won’t get a fair comparison, which means a greater likelihood that you’ll fall back on biases like similarity or likeability.

Develop a standard set of technical questions, and a written test. The questions should allow for some discussion, but have a clearly-defined right answer. Examples of these questions are everywhere. You’ll probably want to customize your list so that people can’t just look up the answers online before the interview, but lists like those will get you most of the way there.

(And don’t feel like you need to come up with this list on your own. If you have technical experts at your disposal, utilize them. You’ll probably want one in the interview, too.)

The written test can make or break an interview. It should not be easy, nor should it be mandatory to get every question right. When an applicant is writing out code by hand from memory, leniencies must be given for syntax—give points for partial answers and ideas. Remember what Stephen Wolfram, creator of the Wolfram Alpha answer engine, said on the subject: “One thing I’ve noticed is that in almost every area, the people who go furthest are not the ones with the best technical skills, but the ones who have the best strategy for figuring out what to do.” You’re trying to get a feel for the candidate’s problem-solving strategy, not their ability to memorize every minutia of coding syntax.

There should be at least a few “fix this code” sections to see how sharp their debugging skills are. Again, you shouldn’t focus on trick questions or ridiculously obscure syntax problems—you just want to measure the candidate’s ability to think through and solve a technical problem.

Questions should be relevant to what the job entails—if they’ll be expected to create custom CSS animations, make sure to ask about that—but they should avoid niche- or process-specific knowledge unless it’s vital to the position. Rule of thumb: if your company does something differently than the rest of the industry, don’t quiz them on it.

Once you have the questions and test prepared, run the questions by some of your existing team members to see how they fare. If your entry-level developers get all of the questions right—probably a bad sign; if your senior developers all bomb the test—also a bad sign.

In the questions, there should be some clear delineation between roles. What are the must-answer questions for mid-level developers? For seniors? There can be some flexibility here, but you should have a pretty good idea what a senior test looks like and what a mid-level test looks like.

If a candidate aces your standard interview questions, you can hire them with confidence. But when the technical portion of the interview doesn’t go well, you need to know how to handle that too.

Know when to move on#section6

The most awkward interview I ever conducted was with a PHP developer who freelanced and was looking for his first agency job. When we began the technical questions, I quickly realized he didn’t know as much as he thought he did. Of the 22 technical questions, he got about 2 correct. He got more and more distressed with every tough question—especially when I corrected his wrong answers—and by the end of the technical portion, he looked like he’d been punched in the stomach.

That guy was not qualified for the job, and both of us knew it from question 3. This was pretty early on in my management career, so I just plowed through the entire list of questions, knowing he would fail them. Learn from my mistake: don’t do that.

Let interviewees fail gracefully. Don’t interrupt them with the right answer to the question they’re struggling with, and don’t correct them if they get the answer partially right. If they get the question wrong, just move on without showing judgment. If they really can’t get a question, just tell them you’re moving on.

If a person bombs the verbal questions, don’t make them sit through the written test (which will probably be much harder). Feel free to tell them right then and there that they’re not a good fit for your particular position and wish them well in their quest for work. If you think they could be a good fit for another position in your company, or if you’d like to see them back once they get a better grasp on the fundamentals, go ahead and let them know. But there’s no point in leading them on with a vague non-answer if the answer is definitely no.

Conclusion#section7

Screening for technical talent can be tricky. Having a holistic view of both the role and the candidate is key to making the right hiring decision. Remember to take careful notes, even if you don’t think you’ll need them. And good luck!