scribble

Oasis

About     Blog     LinkedIn     GitHub    

24 Jul 2015
How to Interview Tech Candidates
Or, What Should Be Common Sense

The Audition

Tech interviews are broken. Startups are popping up left and right, like Hacker Rank, TripleByte, and interviewing.io, just to name a few. They're all approaching the interviewing angle slightly differently, but they're also focused on the top of the funnel. This is a good place to start, since that's going to bring the most ROI!

I come from a theatre background. I went to Jacksonville State University -- don't worry, you've never heard of it. I started off as a Computer Science major, but quickly gained interest in the theatrical arts. There isn't much more that gets my adrenaline pumping than being on stage re-enacting a masterpiece by old Willy Shakespeare.

The theatre world also has what you might consider a large top of the funnel. There are thousands and thousands of actors out there -- some real professionals, but most are amateurs. When a casting call is put up, you could get dozens or hundreds of aspiring Broadway stars at your audition, ready to recite their constrasting monologues and do their cold readings. And who knows if they're any good? You don't! And you've got dozens or hundreds to sift through for just a handful of roles!

It doesn't work very well.. The casting director and team must decide within 2 minutes whether a candidate can act or not. Resumes are often not even a consideration -- it's the audition that counts.

Casting directors and tech hiring managers have a similar problem: how do you determine the technical competency of the candidate in a short period of time?

The Secret

Actually, I don't know the answer to this question. What I do know is that those decision makers must have some sort of filtering mechanism. It simply isn't feasible to interview hundreds of candidates for the same position. You'd never get anything done!

The startups I mentioned above are making great strides toward finding a better way. I don't have the time or inclination to really dig into what I think that better way is, but what I can do is tell you what the results should be.

The funnel looks like this:

  1. Candidate applies (they're interested)
  2. Phone screen with recruiter (ensure they're still interested)
  3. Tech screen to evaluate technical competency (optional: code challege, whether with shared screen or take-home variety)
  4. Onsite interview (possibly more than one)
  5. Offer made

The candidate can be rejected at any point on this list -- and indeed, many don't make it to the onsite portion. Each step acts as a filter, and should theoretically reject poor candidates as early as possible. TripleByte, HackerRank, and interviewing.io all focus on the first three steps: candidate interest, phone screen, and tech screen.

I want to talk about number four.

Onsite Interviews

Here's my thing: by the time the candidate walk into your office, you should know whether she's technically competent. Through the use of some combination of phone screens, tech screens, and code challenges, you should know whether she can code.

Let me put it another way: if the candidate gets to the onsite interview, and you're not sure if she can code or if you determine that she CANNOT code, your top-of-the-funnel filters FAILED.

You should never bring a candidate onsite, unless you are sure they are technically competent. Simple, right?

Well, that's hard to do. In fact, it's so hard, nobody has quite solved it yet. That's what those startups are trying to help solve. I think they're on the right track in many ways, but it's still a huge domain to tackle. Good luck to them.

That said, I'm more interested in the onsite interview portion of the funnel. Here's how an onsite interview should go down:

  1. Introduction by Interviewer (2-3 minutes)
  2. Quick introduction of company, team, and position, then set expectations (5 minutes)
  3. Very quickly verify the candidate's technical competence (10 minutes)
  4. Strive to answer the "Do I want to work with this person?" question (whatever that means) (30 minutes)
  5. Allow the candidate to ask questions. If they have none, answer unasked questions (10 minutes)
  6. Thank them for their time and exit gracefully (2-3 minutes)

One thing you'll notice right off the bat here is that the four out of six points are for the benefit of the candidate. Remember, an interview is a two way street -- it is just as important for them to learn about the company/team as it is for you to learn about the candidate!

Let's tackle each one in order.

Number One: Introduction by Interviewer

This one is pretty straightforward, but so many people screw this one up that I'm going to provide you with a little script to help you out next time you go interview someone. Just say something like the following:

Hi! I'm Jen. Nice to meet you. I'm the hiring manager, so if you have any questions at any time, please let me know. Is there anything you need before we begin?

What you do NOT want to do is this:

Hi, I'm Joe. Okay, so you have N trains and M stations... (then start writing on whiteboard)

Introduce yourself! The candidate is nervous as hell to be there, at least have the integrity to treat them with respect! Say something nice, introduce yourself, give them a firm handshake, welcome them to the team. There are a million things you can do to put them at ease -- and you should do whatever you can to make sure they're comfortable. They'll be stuck with you for an hour!

Don't forget to tell them who you are and why you're there. I can't tell you how many interviews I've had where I didn't find out who the person was that was until the end of the interview. Were they the hiring manager? A potential coworker? A manager for a different team that's there for a second opinion? Are they HR or Marketing or Sales?

It sounds so obvious, but you would be astonished at how many people fail to do this simple step.

Summary: Tell the candidate who you are and why you're the one talking to them right now!

Number Two: Quick Intro of Company and/or Team

Instead of just telling you what to do for this one, I'm going to give an example. I went to interview with a company fairly recently. They were all super nice. They catered lunch, I talked with the hiring manager. They're all incredibly smart.

But when it came to telling me what they did, they fumbled around a bit. The conversation went something like this:

Hiring Manager: Do you have any questions before we begin?

Me: Sure. What is your title and what do you do?

HM: I'm the Head of Growth.

Me: Growth?

HM: Yep. The team at headquarters writes all of the feature code. We're the Growth team.

Me: You said that again. What's a Growth Team? Marketing or engineering?

HM: Well, by growth I mean our goal is to get more users.

It went on for a bit, but his answers were never quite clear to me. What does "get more users" mean? Is it a marketing strategy? Is it A/B testing sign-up pages and landing pages? Is it streamlining the onboarding process? If that's what it is, why do you need four designers and 10 engineers? What position are you hiring me for?

(Note: I was eventually rejected by this company, with part of their reasoning being "You didn't seem excited to work for us" which, to be fair, was true. It's hard to get excited when you don't even know WTF you'll be doing! Don't make this mistake with your candidates!)

At this point a lot of people would stop me and say, "Brian, you should have done your research before you walked in the door." But that's the thing. I went to their website, and I used their product. Their product was one thing -- but this was the Growth team, a team without a website! There was literally no research to do about what that particular team did!

Similarly, when I worked for a real estate company. I worked in the Rentals division. When candidates came in, they almost unanimously went to the homepage of the website, which deals with for sale listings. Almost 100% of their research would have been for the wrong product! My team worked on rentals -- and more specifically, rental pro tools.

What are "rental pro tools", you ask? Well, that's a great question, and one that I, as an interviewer, should explain as clearly as I can to potential candidates.

Summary: Quickly describe the mission of the team -- and the position -- to the candidate, assuming they have no prior knowledge. Avoid buzzwords and industry jargon. Don't say "growth", say "we build software to get more users to sign up." Don't say "rental pro tools," say "the software that property managers and brokers use to manage their listings."

Number Three: Quickly Validating Technical Competency

This is the hard part that's so, so easy to screw up. Hopefully by this point, you've evaluated their technical competency remotely. You've given them a tech screen and possibly a code challenge. These should have given you a pretty good idea about whether the candidate can code or not.

The most common complaint to this is: how do we know the candidate wasn't cheating somehow?

It's possible that if you send a code challenge to them, a friend of theirs could complete it for them. Or maybe they looked it all up on StackOverflow. Or maybe they took 48 hours to do it but told you it only took them 3 hours. The scenario doesn't matter -- what matters is that it's possible they're lying.

And so sadly we have this requirement of the onsite interview that you must verify the authenticity of the code challenge. You must give them some quick test that gives you confidence that the person who was on the phone in the tech screen and the person who completed the code challenge is the same person that is in the room with you right now.

How do you do that? Well, there are a million ways, but the key here is to do it quickly.

If your candidate gets to spend an hour with you, and you take up the whole hour on whiteboard exercises, then you've wasted their time. They didn't get a chance to learn about you, and you only evaluated their technical competency, and not anything else. In short, it's a failure.

Recently I interviewed with another company. They asked me to come in for a 5-hour interview. They had excelled on the top-of-the-funnel interactions, so I was excited to show up. Each of my interviewers came in, said their name, and then immediately started writing on the whiteboard. By the time we were done with the whiteboarding exercises, our time was up. They didn't get to learn more about me (see #4), and I didn't get to learn about them (see #5). In short, it was a complete waste of both of our time.

This was bad, because their tech screens were some of the best I'd ever encountered. By completing the tasks set before me, I had completely and totally demonstrated that I know how to code. But instead of trusting those filters and quickly verifying them in person, they wasted all five hours of the interview trying to answer questions to which they already had complete information!

Needless to say, it was a terrible experience for me, and I no longer wanted to work there.

Summary: Don't waste time on testing technical competency in onsite interviews. If you spend more than 5-10 minutes, you're wasting your time and the candidate's time. Do it as quickly as possible, then move on.

Number Four: "Do I Want to Work with this Person?"

As I've mentioned ad nauseum so far, you should be 100% confident that this person can code by the time you're 15-20 minutes into your interview. Your next step is to determine everything else. I usually describe this as "Do I want to sit next to this person for the next six months?"

But that's a little misleading. What I really mean is that I'm looking for certain soft skills. Here's just a small sample of things I want to know:

  • Professionalism (e.g., hard-working, task completion, etc)
  • Communication
  • Enthusiasm (i.e., do they want to work here?)
  • Proper hygiene
  • Cooperativeness
  • Seniority (i.e., are they the proper seniority? Too senior/junior?)
  • Relevant past experience (e.g., growth, API development, unit tests)
  • and many, many other so-called "soft skills"

Think about the people you work with every day. They can code -- that's a given, hopefully. But what else is it about them that you like? Are your coworkers awesome people you enjoy hanging out with, or are they the type to argue about every little thing? Do they curse a lot? Do they take initiative? Are they assertive or meek? Can they work as a team, or are they loners that do better on smaller, independent features?

There are no right and wrong answers here. Figure out what's best for your team, and look for those qualities!

Finally, you should expect basic technical competency. Simply being able to code SHOULD NOT be enough to get the job!

With that in mind, these are the BIG questions -- what ELSE does this candidate bring to the table that you need or don't already have on your team?

Summary: Answer the "What else do they bring to the table?" question. Take your time -- this is the real meat of the interview!

Number Five: Q & A

Set your watch or phone before you walk into the interview. Make it beep when there are 10 minutes left. No matter what you're saying or doing at that time, stop -- just stop. Look at the candidate, smile, and say something like:

Hey, so we have about 10 minutes left. This interview is just as much for you as it is for me, so I want to make sure we have some time to answer any questions you may have. Give me your best shot.

And then answer their questions! If possible, anticipate questions as you go along and answer them. For instance, if the candidate asks you "What's the culture like here?" then perhaps you can also add the perks and benefits that come along with working there, like weekly board game nights and catered lunches.

If the person doesn't have any good questions, or no questions at all, don't let that happen! Ask some rhetorical questions, then give the answers as if the candidate asked them. Remember, they could just be really nervous and drawing blanks!

You do not want to pass over a great candidate simply because they were nervous in a stressful environment! (Although, arguably, that could be a bad quality -- but I tend to give people the benefit of the doubt here.)

Aline Lerner, founder of interviewing.io, wrote a blog post titled How to Interview your Interviewer. Take a look-see at this, and see if you can utilize some of those questions in your own Q&A with the candidate. Answering even their unasked questions will help you in the long run!

Summary: Make it clear that the interview goes both ways -- you are making yourself available to them for anything they need to know!

Number Six: Goodbye, and Thanks for all the Fish!

The ten minutes remaining are up. You've introduced yourself, set expectations, and made sure your candidate is comfortable. You've quickly verified their technical competency, and you've figured out whether or not you want to work with them. You opened yourself up to questions and provided enthusiastic, transparent answers. You've probably already made a decision!

Now it's time to say goodbye. Thank the candidate for her time. She probably took time off work from her current job to come talk to you -- that's a big commitment, so be grateful! Shake her hand, thank her for her time, and explain next steps.

If you're just one of several interviewers, this might be as simple as, "I think John is next. Let me go get him."

If you're the hiring manager, this might be a more in-depth conversation, such as collecting references, follow-up emails, and "we'll call you when we've made a decision."

And finally, crucially, send a follow-up email, no matter what. I'd rather get a "thanks, but no thanks" email than just never hear from you again. If you do decide to reject a candidate, let them know!

Summary: Be polite, grateful, and humble. Thank the candidate for her time, and explain next steps.

Conclusion

I'll be the first to admit it. I've never been a great interviewer. The last few weeks, however, have given me a fresh perspective on what makes a good interview and what doesn't. I've had nearly 30 phone screens, two dozen tech screens and code challenges, and almost a dozen onsite interviews in the last two months.

And let me tell you, we as an industry are awful at this. Some companies did a great job. Others... not so much.

The guidelines I described above are not hard and fast rules, but if you follow them, you will wind up with much more enthusiastic, happy candidates than you did before. I know I would be ecstatic to interview with a company that followed the guidelines above. Give it a try, and let me know how it works out!

Godspeed, and good luck.


-B

scribble

About     Blog     LinkedIn     GitHub