The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

zdfs

Before joining Sonos (I guess now is a good time to state that my opinions are my own), I interviewed at a lot of different companies. Companies that were looking for rock star developers or unicorns or full-stack developers, whatever. Every company I interviewed with was a little different, had a slightly different twist to whatever it was they were looking for, except for one common thread. You had to be a rock star.

Most companies wanted extroverts. Some wanted a human calculator. Others wanted specialists. Still others wanted a general jack-of-all-trades, master-of-none, sort of thing. Recruiters didn't care if my skills actuallylined up against what the company needed, only that I had some word comprised of the Java- prefix in my LinkedIn profile. Recruiters, I've discovered, are mostly horrible at their jobs. There are exceptions, but I haven't met many.

It was, to be honest, just one continual disaster.

More often than not, the primary problem I experienced with every interview process, no matter the company, was the interviewer proverbially trying to prove who was smarter. In the crassest of urban dictionary definitions, I think the kids refer to this as a dick swinging contest.

For example, why in God's name would you ask anyone to polyfill the querySelectorAll() function in JavaScript? Or write a function that takes an integer and returns that integer's index on the Fibonacci sequence. That last example: they wanted me to do this with pen and paper over the phone.

The only thing you've done is made yourself feel valuable and smart and you didn't care if you had to dismiss another human being completely to do it. The problem is, how many great developers did you pass over because your interview bias tends toward self-gratification or in the belief that you avoided a secretly terrible engineer?

I'm not telling anyone anything new here. This topic has been covered manymany times.

Thinking Fast & Slow

In my experience as an interviewer, I can tell you that there is a huge bias towards hiring candidates who areextroverted rock stars (rock star is subjective here) over candidates that are less experienced or introverted or just not as confident.

I'm horrible at interviews. I freeze up for no reason. It's not that I can't write loops. I can. I know the difference between call() and apply() in JavaScript. Whoop-di-doo. I've written thousands of integration tests. Solved difficult problems for huge companies. But in the end, when it comes to my turn on the other side of the interview chair, none of that comes through.

Part of this is my personality. I speak slow and think slower. And doing anything with someone staring at me or looking over my shoulder is next to impossible. It makes me itchy and it's all I think about. Not the problem at hand.

Recently, we had the same sort of intern candidate come through at Sonos. Nervous guy. Quiet speaker. By the time it was my turn to speak with him, you could visibly tell he was spent. It had been a long day, the poor guy was tired. I'm an introvert. I could tell.

So I spent the interview talking about whatever he wanted. We talked about his projects for school and I narrowed in on a single problem. Just a question or two. I let him take as long to think about my questions as he wanted to. He would posit some ideas and I would pose new questions. About ten minutes of this and he started to relax and focus on the problem. He left our little conference room with a smile. He thanked me for the new ideas (they were his own, he just needed some prodding).

Not all of his interviewers could see his potential, at first. I approached his hire like Moneyball. He was good where it counted. I had to explain why. In the end, I brought everyone around.

He's an intern now. Doing good work.

How I Interview

As I mentioned before, there have been a lot of articles on this topic in recent years, positing a lot of greatideas. I'm not attempting to define some universal solution, but merely add to the conversation. This is how I do interviews, no matter what the company. This is also how I tend to judge the process of any company with which I interview.

How you interview a candidate speaks to the quality of the organization.

If I encounter any of the shenanigans I described in the article opener, I immediately start to wonder if there are larger problems in the organization.

Interview Focus

  1. Know what you're looking for. If your requisition is vague for any reason, you're going to have a bad time. You might have a great developer on your hands, but if your organization isn't aligned on what you're looking for, you might as well forego bringing in any candidates at all. Know the skill set you want and make sure your recruiters know what they're looking for, not just keywords in a LinkedIn profile.
  2. Don't forget the small talk. I know that this sounds trite, but engaging in meaningful conversation about lighter topics goes a long way in making your candidate feel comfortable. If they're introverts, it will help draw them out of their shell (don't worry if their answers are short and sweet, it takes time). How was their flight or drive? How do they like the city so far? Have they tried any good restaurants? What are their favorite hobbies? Time is limited, I get it; but be polite. It's not hard.
  3. Start with broad topics. I'm a front-end engineer, so broad topics for me will be the easiest questions possible regarding HTML, CSS, and JavaScript. I probably won't even talk about code, just ideas. See if the candidate has opinions about their craft and what those opinions might be. Later, you can delve in to reasons behind those opinions.
  4. Talk about specific ideas. The whole point of starting with broad topics (#3) is to mentally map some ideas that you can dive more deeply in to later. How do they approach Responsive Design? Why do they use or not use CSS frameworks. Why do they like (or hate) jQuery? What do they know about Web Components. How familiar are they with build processes? The list will be endless and you'll find plenty to talk about. You'll probably have to timebox this, but what you're learning is how they think. Any developer passionate about their work will have interesting opinions if you only take the time to draw them out.
  5. Talk about past projects. Some developers are not going to have a treasure trove of Github repos for you to peruse with them. Many of them will. Have them walk you through the project they're most proud of. If there are code examples, take a look beforehand and come prepared with questions regarding choices they made in their code.
  6. Leave out the ego. The single most important thing I see lacking in the interview process is kindness. This is something I'm working on myself, since I tend to come across as a jerk to everyone when they first meet me. It's a defense mechanism. I'm really sensitive, actually. I feel things more than most extroverts and feel a need to protect myself. But when it comes to interviews, I try really hard to lower those barriers. This is a pattern that needs to overflow in to the rest of my life. Kindness is everything.It's hard. But it's everything.
  7. Give them a project. If you feel good about the candidate at this point, let them know that you'll be sending them a project to code on their own the next business day. Try to tailor it to your specific needs and if you can manage it, a simplified problem that satisfies an actual business need. Give them a few days to code it on their own. When they submit the code, you'll quickly discover if they copied and pasted some solution vs. working through it themselves. You'll also know more about the way they write code than any amount of whiteboarding.

My results with this kind of approach towards the interview process are still being tested. But if you read any of the articles I've linked to, you'll find that these ideas are becoming more and more common. Every company wants to hire the best talent possible. We all want to work with other great developers. But it's time we start to seriously question how we go about accomplishing those goals.

There's no need to make anyone feel small and unworthy. Candidates that are not ready for the position need to leave with a positive experience. Anything less is just doing this industry a disservice. And honestly, with all sexism, misogyny, and racism in this industry, it's not like we don't have enough problems that we need to fix. Let's not make more for ourselves. 

Continue reading on www.zdfs.com