The problem with today’s Software Developer interviews
During the month of March of 2015 I was actively looking for a new job opportunity in Boston. I had just moved there and I am now sharing my experience. Boston’s marketplace is quite intriguing, something worth writing about. This post just highlights my point of view on how interviews for Software Developers are conducted. Hopefully you might find some useful information for your future possible job search, but I would even be more amazed if I could change some interviewer's perspective.
Let me give you some context before I begin. I can’t say that I am an expert in this subject; after all I only worked for two different U.S. companies in the last 3 years. In both of them, besides fulfilling my role as a Software Developer, I was responsible for conduct some technical interviews. Also, both of those companies were located in Philadelphia, which is a totally different market than Boston.
Now, regarding Boston. As you may know, Boston is also referred to as the Silicon Valley of the East. Boston is not bigger than other cities in the Northeast, like Philadelphia or New York, however all the major technology companies have some kind of development office here (Microsoft, Google, Amazon, Apple, Twitter, Akamai, you name it). On top of that, Boston is also the hometown for some of the best U.S. colleges like M.I.T., Harvard and Boston University. So here’s my first point: small city, big tech companies, great Colleges equals demanding market. Now, there’s also a great need for Software Developers here, but they can put themselves to high standards just because every year, there’s a new wave of great minds walking into their Colleges and Universities. Some of them eventually move to other locations (like Seattle, San Francisco, or New York), but also a lot of them will stay. So for a large company in Boston, they can raise the quality standards and simply wait until they find somebody that will pass their challenging technical tests. To be fair, some of these technical tests are universal, meaning no matter where you are, you will be presented with the same test. However, what I want to talk about is how this affects other smaller technology companies located in Boston, more specifically what I call “the Google interview syndrome”.
Now here’s some additional context if you’re not familiar with Google’s interview process. If you are familiar, feel free to skip this paragraph. The concept is quite simple, no matter what development position you are applying for, you are given a set of problems that requires some actionable knowledge of algorithms, data structures and optimization. This is a transparent process; before they schedule an interview, you will receive a bunch of material to get prepared. Anyway, in a nutshell, you know it will be a challenging process. The premise is, if you can solve this generic problems you will be able to execute whatever task they may ask you in the future. However, taking a simplistic view makes it look like “one size fits all”. To be fair, there must be tons of different development roles at Google, having a generic set of questions simplifies and reduces the maintenance cost of the interviews quite a lot. At the same time, isn’t this process quite unfair? Imagine that you are an incredible high-level coder (like a JavaScript developer) with a decent set of open-source projects, a few professionally executed projects, some professional years of experience under your belt and knowledgeable business perspective. Now you are applying for a Front-end developer position, nothing fancy, just the typical website HTML, CSS, JavaScript development (no framework, or dev-kit development). However, if in the midst of a 5 hour interview process (and considering that you are a nervous wreck), you choose the least adequate algorithm for the problem presented, you are out. Now, I don’t want to criticize their interview process; they have a reason to do this and the reason is a developer should be able to fulfill any role. And I think they are right, after all they're Google, tomorrow they might want to reinvent the entire Internet, so it would require all of their developers refocused to meet that goal.
The following image, twitted by @kelukelugames perfectly describes my point.
Back to the Boston companies. Let’s first agree on something, there are few companies like Google. I would say the truly comparable companies are Microsoft and Amazon. For these three, I would agree with an interview process similar to Google. Anybody else, probably not so much (this is a generalization, but you get the point). Now let me ask you one thing, do you think a company with a very specific goal, a very specific business and market, should use this highly generic “Googleish” type interviews? Shouldn’t they present problems more focused on their challenges and more relevant to their business, instead of the generalized questions presented by Google? Probably yes. Well, this wasn't my recent experience. Honestly it felt like a lot of the interviewers spent quite some time studying for Google interviews, and either they failed the interview process or worked for these companies before, and now this process of recruitment seems to be the only chosen one. I am not dismissing Google's interview process; a generalized set of questions woks for a big company with hundreds of different positions. But a smaller company could, and should take advantage of their smaller size and customize each position for the exact requirements needed. This allows each new addition to fulfill a specific role in the company, more easily meeting their business needs.
To conclude, I would like to quickly describe what I consider a good technical interview. First keep in mind the interviewee might be nervous, try to provide a comfort zone. Respectfully, treat them like you’re a friend and that both of you are there with the same goal, solving a problem. Now I believe you should present a real problem; something you solved before that can be presented simply without a great business knowledge. Allow and tell them to define some assumptions, after all they might not know the business enough to correctly solve the presented problem. But most importantly, communicate and be engaged in the interview. Try to make it a teamwork exercise where both of you are designing a solution for the presented problem. Also one key point, when the interviewee is talking to you, look at him, don’t be on your laptop working on something else. This actually happened to me, you can’t believe how disrespected I felt, so please don’t do that.
Disclaimer, this blog represents my personal perspective. All of the writing here is of my responsibility and only mine. It does not reflect any opinions of the company I work for, or any of the others I had worked for. Feel free to disagree or even correct me if you share a different perspective.