Marketing digital. Making results.

The Problematic Developer/Programmer Interview Process

Annoying Orange Fan Art, Copyright The Annoying Orange

Annoying Orange Fan Art, Copyright The Annoying Orange

I was going through Dzone and bumped into this article by Bozhidar Bozhanov explaining his frustration with the interview process at Facebook after being rejected after 3 phone interviews. In the article Bozhanov explains that the interview process consisted of algorithmic skills and general computer science test (recursion, binary search, basic data structures), basically “easy” stuff that any computer science grad should be able to solve and that is the rub that I personally have with those types of interviews. As Bhozanov puts it (better than I could have):

  • what you do on these interviews is something you never, ever do in real life: you write code without using any compiler or debugger. You do that in a limited time, with people watching you / waiting for you on the line. But let’s put that aside for now. Let’s assume that writing code without being able to run it is fine for interview purposes.
  • the skills that these puzzles are testing are skills that the majority of developers have never needed. Most people are writing business software, and it does not require red-black trees. What was the last time you used recursion in your business software? So the last time you’ve done anything like that is in college. And many of these problems are really simple if you are a freshman, you did them as a homework just the other day. But then it becomes a bit more tedious to write even things as simple as a binary search. Because you just didn’t do it yesterday. Of course you will be able to do it, but for a little more time, so that you can remember, and for sure by using a compiler. (By the way, the puzzles at facebook were really simple. I didn’t do them perfectly though, which is my bad, perhaps due to interview anxiety or because I just haven’t done anything like that for the past 3 years)
  • the skills tested are rarely what you will do in your daily work anyway. Even in these cool companies like Google and Facebook, there are still pretty regular projects that require coding to APIs, supporting existing code, etc. I don’t think you will be allowed to tweak the search engine in your first week, no matter how great you did on the interview
  • interview preparation is suggested and actually required before these interviews. Exactly as if it is a college exam. But that’s dumb – you don’t want people to study to match your artificial interview criteria. You want them to be…good programmers.
  • focusing on these computer science skills means these companies will probably miss good engineers that are simply not so interested in the low-level details.
 

And I agree with all of the points. I love programming, but I did not love my computer science classes. I had the most fun in classes that involved web development and database practice, but the theoretical classes,  zzzzzzzzzz… In all honesty. So it annoys me when going through an interview process and I am asked questions that I could have answered in 2003 but whose answers have long been pushed out of my general memory. Bozhanov (I agree again)  states that “obviously my problem is that I don’t like low-level and algorithmic stuff, so I wouldn’t be able to work for cool companies like Google and Facebook ” not just them but smaller companies that adopt the same practices in looking for candidates.

In my own personal experience, I was once rejected in pre-screening for a possible opportunity because I used “obtrusive Javascript” on a skill test I was given. For the uninitiated, obtrusive javascript means mixing Javascript and HTML code within the same document, proponents argue that the JS and HTML code should be contained in their own respective files, which is okay and makes sense to me for the the purpose of keeping organized code. What peeved me in this case is that the only reason I used obtrusive Javascript was to make submission of the test easier since there are email filters that block Javascript files. In the end, I figured that it was a sign that culturally in any case, I would not have been a good fit at that company. In any case, I feel like the market for developers is so hot right now that there are enough opportunities to interview with companies where you are asked and even tested about what you actually did, and will be doing at the company than algorithms I learned a decade ago. Some would argue that makes me a bad programmer, and it is fine with me, but the work I have done so far in my career did not involve me pondering what the Big O of binary search is and how to improve on it. There are cases where in pursuit of optimization there is a need to get a refresher on those concepts in order to research of to improve of them, but as I know, the life of a web developer rarely involves that detail of knowledge. If your dream job is to work for Google/Facebook/insertanybigtechcompany out here and you are willing to study for the interview, then proceed by all means, and it might be that those companies are looking for those individuals with that kind of profile but as for me, I will stick to interviews to where I am asked: “So what type of projects are you worked on?”, “Can you explain to us why you chose to implement this functionality this way?”, or better yet, “how would you go architecturally about implementing a Twitter like site?”.

PS: Jeff Atwood over at Coding Horror has his own views on the developer interview process and #5 and #6 where the biggest source of no-nos from the comment sections and the consensus in my opinion that is that the process Jeff outline was very risk averse for the company but will lose a lot of good people through it. This confirmed what I felt, is that as a developer, unless I am applying for a research oriented position don’t want to be bothered with theoretical knowledge from the past or being taken through loops which I feel are unrelated to what I worked and will be working on.