I Cheated “The Interview”

There are many common topics that reach the top of HN on a daily basis, but there’s one that really resonates within me. One that stirs up much controversy, for it is reviled by many as a repulsive practice in today’s IT community. What I speak of is “The Interview.” Everyone has their own reasons why they believe The Interview is broken, but here are some common ones:

  1. More often than not, the problems an interviewee is asked to solve are irrelevant to real-life problems they’ll have to, you know, actually solve on the job.

  2. In a work environment, developers have plenty of time to solve a problem before actually showing anybody. Also, they try many solutions knowing full well they may not work. I personally find myself using the process of elimination to squash bugs.

  3. Performance in the interview isn’t often reflective of workplace performance.

I’ve only been through a few interviews, but one in particular left me baffled. People in the Silicon Valley like to say “fake it till you make it,” and if there was ever a time I truly took that to heart, it was in this interview. Not only did I bomb the interview, but only after receiving an offer did I realize I may have fooled the company into believing I had abilities that in reality I didn’t have.

This was a pretty typical interview by most measures. Two phone screens, flown in for an interview, the works. I spent the night before the interview laying in my hacker hostel bunk bed in the Castro, furiously reviewing everything from JavaScript prototypical inheritance to ECMAscript. As a self-taught developer, what frightened me the most was all the information a skilled developer may look at as basic knowledge that I simply skipped over. I braced for the worst.

The morning of the interview, I woke up with a stomach in knots and a heavy cloud of doubt hanging over my head. If you’ve ever been to an interview, you probably can understand my feelings in the moment. After meeting with the recruiter that I had spoken to multiple times over the phone, the dreaded technical interview began. I vividly remember having to wipe the sweat off my hands before standing up to shake my interviewers hand. I think interviews like this are difficult because you’re opening your kimono to a sea of judgement that you shouldn’t take personally, but always do. These people are determining whether you’re worthy of their time and money, how can you NOT take it personally?

My interview involved a musical chairs type event in which I was interviewed by eight, yes eight, different people from the company. For this reason I won’t go into each of them, not least because some went well, but one in particular felt like the nail in my metaphorical coffin. Not only was this one of several technical ringers I was put through, but the interviewer was almost faceless and gave no indication of how well I was doing. At one point he asked me a really deep question about MVC’s and Backbone in particular, and I just froze up. Instead of actually trying to figure out the answer, I couldn’t stop focusing on the awkwardness of what was happening before my eyes. Upon admitting that I couldn’t answer the question, he turned his head and just looked out the window quietly. Maybe it was to look at the beautiful Golden Gate in view, or maybe he was contemplating something about my answer.

The next interview wasn’t much better, as the interviewer looked at my Github profile and thought all the repos that I had simply forked were actually ones I created. She was enthusiastic about how I had created all these JS and responsive frameworks all on my own. Needless to say I didn’t correct her.

All of this is to say that The Interview is a broken, kludgy mess. Humans make errors and we should try and reduce risk as much as possible by testing interviewee’s in the field. Give them a take home test, have them work with the team for a day, whatever suits your fancy. But the technical interview simply doesn’t work because it’s not how many developers work. I’d consider myself a good developer, but I’m self-taught meaning that the way I solve problems and work may be completely different from another developer. I learn by building things and StackOverflow is my savior in times of need. I may not understand everything there is to know about JavaScript, but give me a task and if I don’t already know how to solve it I’ll figure it out.

I just hope these technical interviews go away.

If you enjoyed this post, consider giving me a follow on Twitter

 
61
Kudos
 
61
Kudos

Now read this

Goodbye Windows, Hello Chromebook

It’s been about a week since I picked up the HP 14” Chromebook (whatever the official name is), and I decided that I’ve had enough time to give a solid verdict on the don’t-call-it-a-laptop device. What do I think of it? I love it. I don... Continue →