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.

The First Rule Of Development: Nothing will work as expected!

Allow me to be bold with this one, but today I ran again into another one of those environment set up issues that make you question your sanity. No need to get into the details, but ever since the beginning of my career, which has involved quite a bit of J2EE development, one of the things that have amazed me is the ramp up time it took to get started on a project. I am not talking about merely perusing through the code, trying to understand the architecture, get a feel for what’s going on, but simply checking out a project from repository, into Eclipse, and being able to run it on my localhost. “What about the documentation?” I hear you say, you smug devil,  and I smile with full teeth at your foolish smugness. Documentation? Who has time for “Documentation”. “Documentation” means one eager programmer like you was kind enough to flesh out the major steps that should get you to where you need, but in development: THE DEVIL IS IN THE DETAILS…

Why is it that nothing ever works as expected?(Hint: Because we need enjoy the gift of debugging to become expert debuggers)  “Copy the so and so .jar to the WEB-INF folder, change this line in web.xml and you are good to go!” said the instructions, yet it’s one week later and Tomcat still won’t start.   I remember on one of the J2EE projects that i worked on, which was an offshoot of an existing project with a 50+ pages outdated development environment set up document, it took me close to two months to get an environment going. I followed the steps, but with each one a pitfall, a bug, that I had to extract a solution for from the minds of not-always-willing-to-share previous developers. It was so obvious in their minds, but not written in the documentation:

“Oh yeah, we had to change this because this and this happened, this is what you need to do…” Thanks, that could have saved me two days!

“Oh that piece of code, unless you are working on this and that you won’t need that!” Thanks, I just spent the last three days trying to get it to work.

Bottom line is that we as developers have to do a better job at documenting what we do (I hope the developers that came upon my documentation agree), and that for the sake of other developers, and not assume that a) it is not such a big deal or b) others will be able to fill in the gaps. I thought J2EE development environments were the worst but I’ve had my share of mishaps in LAMP environments as well.  I am curious, though, as I always assumed that .Net programmers must be somewhat free of those problems being that the word was MS did a good job of providing a polished development environment,  is the grass greener on the other side? Is it an open source software issue? I am interested in hearing about your experience with how easy (or not) it is to become productive within your chosen programming language and associated development environment.

Programming mistakes and how to avoid them

For a good write up on some common programming mistakes and how to properly avoid or mitigate them, check out this excellent article by Paul Tero. Not only you get an explanation of the mistake, but he also gives you some tools and techniques to use alongside. What i really appreciated as well about the article is that Paul is not shy about admitting to past mistakes, no matter how serious, which helps give perspective about their repercussions and is without a doubt a sign of experience and maturity. Insightful to say the least, I have made some of these mistakes and picked up a few best practices from him:

My Favorite Programming Mistakes.