A Rant on Intervews

The Soapbox soapbox_zpsdc88bddd

   For the past month or so I have been on the hunt for my next slave driver and/or employer. On one hand it’s awesome to see that my field of expertise is in high demand and getting interviews is relatively easy. It is quite the happy position to be in given that so many others are having trouble finding their own job. However I have noticed a disturbing trend in all of the interviews that I have done and I’d like to share why I think they all failed at what they are supposed to do.

The: Ohh that’s nice

  Interviewing a developer, whom is not straight out of College, should in theory be a lot like interviewing a Graphic Artist or Architect. What I mean by that is both of those fields require a person to show their stuff. You wouldn’t dare hire either one of those people without first seeing their portfolio, so why would you do the same for a developer?

 In a recent interview, I was asked to create a page based on some mock-ups. We are off to an OK start here. While I know that some people would not want to devote time to working on a “project” that only gets their foot in the door, I see it as a necessary evil. Alternatively a group could simply ask the candidate the submit some of their own code for review, but that comes with a host of other problems. My suggestion is to just make the problem something a person, with the require experience, could finish in no more than 2-3 hours. 

Moving on, I did the sample problem and got an interview. Hurray! By this time I had already done a few, so I had very little prep work. Mostly I just loaded my Surface with various coding samples to show off. On the day of the interview, I show up and am greeting by an HR person. They lead me to a small room with a window and dry erase board. It is here that I was to meet 2 other developers, one at a time, and they would do their thing. Sadly, after a few minutes of talking to the first guy, I know this interview was going to be a carbon copy of allllllllllll of the rest. My main complaint here is that they asked me to create this pre-interview code, which I commented the hell out of, and then proceeded to ask me zilch about it. Instead they asked what I call, College Test Questions. The ones that have zero actual use. Example: List out the number of times a word occurs in this sentence. Yes, I’m sure that somewhere in the vastness of software programming, this is an actual problem. But outside of that particular job, it’s a stupid question. 

After I went ahead and drew out the code, I intercepted his next question and offered to go over the sample problem and some of the coding samples I brought with me. One of those samples being a fully functional web-app with lots of pretty bells and whistles. It even had a fully working backend that I also made. I can tell you that when I was giving interviews that if a candidate brought in something like that, I’d being jumping with joy! But instead, this guy glanced at the site, said “Ohh that’s nice” and proceeded to his next question… *sigh*

So what’s the right response? 
Candidate :”Here’s working code that does stuff!”
Interviewer:”Awesome! Show me your code that does stuff! After that I can ask a few questions that are directly related to what you’d be doing here.”
Candidate:*Shows off code*
Interviewer: “This is great! I was going to ask if you knew this and that, but you clearly do because you used it right here and here! And it’s fantastic because now I also know what you’re style looks like! And I’m not judging your coding ability based on how you do on a whiteboard!”

That right there is how it should have gone, and all of them should go. The only time that this should not happen is if the candidate does not have any code to show. But that again should be covered by having a simple pre-interview coding challenge. The idea here is very simple, at the basic level a company is hiring you to build them something. If a candidate comes in with something already built. Ask them some questions about it. It saves time for both the candidate and the interviewer… All this leads to my next point which I have touched on briefly here, the questions.

Let me ask you a question…

Before I rant, let me say that I myself asked these same stupid questions when I used to interviewed people. That said, coming up with good questions is hard, very hard. So hard that it took me almost 2 days to get a list of 5 down that I thought would actually show someone has quality. There is one subset of questions that I absolutely hate. Asking me how to use a library.

In the world of programming people build off the works of others. In any given project that I work on, a good 80% of the code comes from either other workers code or open source software. The saying ‘Don’t reinvent the wheel” is kind of a programmers creed. I mention this because there are thousands of libraries(collections of code) out there and asking questions on specific ones is somewhat tiring. You see, when someone writes some code that say, counts the number of words in a sentence, they put it inside a function. They give that function a name, and then document the function and how to use it. For example:

If I wanted to use that function above, I would invoke the function name and pass in a sentence like this.

The above would then return to me the number 6.

So how does this relate to an interview question? A lot of times an interviewer will ask you about function X in Library Y. This to me is silly. You should care if I have memorized the name and usage, you should care that I know how to look it up and then use it.

A better question…

Interviewer:”I want to you solve this problem. To help you do that, here is some documentation on code that you might find useful.”
Candidate:*Reads over documentation *
Interviewer: “Great I can see that you know how to read and use documented code to make your code better!”

There are of course caveats to this. I wont go over them in detail, but for example, if you’re candidate absolutely has to know Ember.js, then it’s fair to ask them questions about it. But to be honest, I’d rather hire someone who knew nothing about Ember, but has demonstrated that they can learn quickly over someone who knows Ember but little else. Hire for the future, not the past. 

Another thing of questions…

 Another common theme that I saw is that I would be given a question. I would then proceed to use one of those libraries that I touched on above to solve the problem as quickly as I could. In each interview though, the person would say that I can’t use a library. Their reasoning was that they wanted to know how I would solve the problem without the library. Here’s the kicker though, if I was working on an actual project, I’d probably use a library*. In effect, what they are asking me is to solve a problem the wrong way. I get the point they are trying to make, they want to see how I think. Of course allowing me to show off my code would solve that problem… But none the less, if I can solve the problem easily with an outside library, the real problemis that your question is bad. An Example

Problem: Given a list of words and a sentence. If one of the words in the first list is in the sentence, reverse the word in the sentence with the word in the list. 
List of words: Cat,Mouse,House
Sentence: The mouse in the House was chased by the cat.
Answer: The esuom in the esuoh was chased by the tac.

Best solution: Use what’s know as a regular expression to search for a word in the sentence and then replace that work. It would look something like the below. 

Boom. Done. But that was to easy of a solution, so I had to describe another way to do it. Another way is to break the sentence up into pieces. Check each piece, if it matches, do the reverse thing. And then stitch it all back together. Yes it works, and yes it’s a worse answer.

You want to hire people who know what they are doing, and know how to get it done the fastest. Tying their hands behind their back tells you the first part, but not the last. If you want to know the second then your questions have to be good enough to allow for outside thought. 

*There are times when you wouldn’t want the overhead of a huge library if you’re only going to use one small piece of it.

Off the box

There you have it. My little rant on interviews and how I think they should be done. Let me know if you agree or disagree in the comments below! Ohh and I created a GitHub repo that has a few of the questions/answers I was asked. I’ll be adding more to it as time goes by…

Thanks for reading!

Facebooktwittergoogle_plusredditpinterestlinkedinby feather