Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of and . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

My Problem With Your Interviews

  • submit to reddit

This article comes right after Facebook rejected me after 3 phone interviews, but it is not going to be a hate-post. In fact, I’ve been planning to write it for a couple of months. But now onto the topic: tech companies (Google, Facebook, VMWare, at least, but certainly many more) are all trying to find the best technical talent. (So they contacted me and asked if I’m interested in “exploring opportunities” with them). But how do they do that?

The typical interview (be it a phone screen, or an onsite interview) consists of solving a problem. Some call these problems “puzzles”. They are usually non-real world problems that aim to verify your algorithmic skills and your computer science knowledge. The simple ones include recursion, binary search, basic data structures (linked list, hasthable, trees). The more complex ones require red-black trees, Dijkstra, knowledge of NP-completeness, etc. If you are on the phone, you write the code in a shared document. If onsite – you write it on a whiteboard. So, these puzzles should verify your computer science and algorithm skills. But let’s step back a little and see the picture from another angle.

  • 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.

Btw, here’s an excerpt from my feedback after my first phone interview with Facebook:

On the other hand, I don’t think having 1st year CS homework problems on interviews for senior developers is a great idea. One thing is – most people (including me) haven’t done this since university, and it looks a bit like trivia questions rather than actual programming.

The problems outlined above are what I don’t like about these types of interviews. And that’s obviously because I don’t like solving these sorts of puzzles. I just don’t like them, they are not interesting for me. You could argue that in addition to your daily job, you can participate in programming competitions (like TopCoder) in order to keep your algorithm skills trained. I’ll give a short story about my high-school years. There were two student competitions – one was about exactly these types of programming puzzles – you are given a number of them for a fixed period of time, and you must submit a solution that covers as many of the pre-defined (but unknown to you) test cases as possible. The other competition was about creating a piece of software at home, and then presenting it in front of a jury. I was a top-competitor in the latter, and sucked quite a lot in the former. Why? Because I hated solving useless, unrealistic problems for the sake of solving them. I liked building software instead. I would probably be good at solving puzzles if I liked them. I just don’t. And these are not two levels of skill – one who can solve complex algorithmic puzzles (superior), and one who can’t, therefore he builds some piece of software (inferior). These are two different types of skills. And both of them are very useful in the process of creating good software. One writes the low-level stuff, the other one designs the APIs, the architecture, the deployment scheme, manages abstraction in the code. So, to get back to the question what I do now in addition to my daily job – I build stuff. I’ve worked on a few personal projects that I enjoyed. Way more than I would’ve enjoyed a TopCoder competition.

Unfortunately these cool companies are hiring primarily the TopCoder-type of people. Which probably works for them, because they have a lot of candidates and they can afford a lot of “false-negatives”. But many smaller companies adopt these interview practices, and so they fail to get the best technical talent. The best article on software engineer interviewing I’ve read appeared just a few weeks ago. Jeff Atwood advised how to hire a programmer, and I completely support his approach.

And my problem with interviews is that they don’t actually verify if you can do real programming work. And 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.

Important note: I’m not saying you should not know what computational complexity is, how a hashtable works, or how to write recursion. You should, because that is basic stuff that you need in order to be able to write good code. But focusing too much on these things is what I consider irrelevant to day-to-day programming. (And for the trolls: I wouldn’t have passed the 2 phone screens if I was a complete dumbass who can only write websites in PHP and thinks a hashtable is some sort of furniture)

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Martin Vaněk replied on Sun, 2012/03/25 - 6:49am

Exactly. We do software engeneering, not computer science homeworks.

The Point Of Si... replied on Sun, 2012/03/25 - 12:12pm

+1. Totally agree with you. I find, that these types of tasks are pretty niche. Most of the time you actually using these algorithms  and not writing them. It's actually more preferable  option in day-to-day job because it saves time, money and number of bugs that would be produced initially, by writing custom implementation. What's more important IMHO, is to know alternatives, understand their advantages and disadvantagesand be able to make reasonable decisions  (You still need to decide whether you will use ArrayList or LinkedList in some paticular case and understand their performance characteristics, but it's more conceptual understanding and it does not guarantee that you will write you own highly performant LinkedList implementation within 10 minutes). Based on my 6+ years experience of Java web development I can say, that there are a lot of sides of software development and writing very performant algorithms is only one tiny side of it. I find things like sofrware architecture (at different levels), application scalability, maintenability and even human factors (ability and motivation to learn new stuff, question what you already have learned, communication skills) are also very important. From my point of view, the reason why these companies have these interview question should be one of these three:

  • They actually want you to write performant algorithms most of the time - it would be your main job, so you should be good at it. So if other sides of software development inspire you much more, than I think you should think twice before take this job or even send you CV.
  • Making an interview questions is very hard job. And it's actually much easier to find out whether you are good at writing quicksort in 5 minutes rather than to fond out whether you are good at understanding new concepts or your ability to develop robust architecture. Especially if you are given about 30 minutes for this. So probably they have decided, that it's actually better to have more objective and clear results even if it compromises knowledge about your other abilities which you can be good at, but they can't really verify it.
  • Or maybe there is much more to it, and the main purpose of the task is not to test the end result, but the process. So they are interested in how exactly you are solving it and how good your communication skills are. During one interview, I was asked to solve river crossing puzzle on whiteboard (classical mathematical puzzle). I'm not completely sure whether we can place this task in the same category as yours, but even if code was not involved, I can see this problaem as a good candidate for the algorithm. What's interesting about this, is that it was actually not about solving this problem in the best possible way (there is only one way to solve it was af far as I know) - it was all about testing communication skills and ability to solve problems together with my collegues. Of course it can be the case only if you are solving it interactively.

I actually prefer test assigments where you are given several days (maybe a weekend) in order to implement something according to some requirements or specification. That's probably the reason why I liked SCJD and hated SCJP. So I find that SCJD format is very good for testing development skills - it captures many different aspects of software development.

 Thanks for the nice article and I wish you luck in your future challenges! :)


Mikael Couzic replied on Sun, 2012/03/25 - 4:16pm


The tested skills you mention never prevented anyone from creating a rotten buggy blobby mess.

Lund Wolfe replied on Sun, 2012/03/25 - 8:25pm

The interview questions should apply to the job.  They probably want to weed out those without basic CS skills, which they probably do in the first interview or two.  I agree with a previous comment that knowledge of data structures/algorithms is important at the coding level to avoid unnecessary maintenance/performance problems.  You should also know what basic data structure/algorithm applies to the particular question/situation.  A lot of candidates will make it this far and a lot won't.

Extending this filtering process to more difficult coding problems is probably not going to get you even better, higher level developers, even if they might be faster or more intelligent in certain ways.  Problem solving and judgement of alternatives comes with intelligence and experience and should be the criteria for these developers, but it does require more interpretation and skill by the interviewer.  Certainly a take home programming exercise will find your best programmers but it won't work on a larger scale.  The better solutions will become known to later applicants and, again, it takes much more time and skill to judge them.

This is actually a win-win for you.  They were either looking for low level developers and you would have been bored in no time flat or potential high level developers, which they don't have yet because they can't identify them. 

Jammer Man replied on Mon, 2012/03/26 - 2:30pm

This looks more like sour grapes to me.  You obviously think quite highly of your abilities; obviously, FB did not share the same thoughts.  I'm going to guess it was probably more about your attitude and ability to fit in with the team than anything else.

sd giant replied on Tue, 2012/03/27 - 12:40am

Thanks for posting this.  I thought about posting a similar blog after my phone interview with Amazon a few years ago.  Amongst other things I didn't want to deal with the douchy responses that you will unsuprisingly receive(d).

My interview with Amazon was for a Java/J2EE postions, and like you I was contacted unsolicited by a recruiter.  The interview questions they asked had nothing to do with anything in the job descriptions, and were verbatim from sites like this:

I was so thrown off by the questions I would say I did quite poorly and obviously did not get the job.  I'm sure Amazon has some great developers, but with the interviewing methodology they were using, I doubt they weeded out many of the bad developers, and probably hired some that just memorized questions from sites like the one above.

Spencer Kormos replied on Tue, 2012/03/27 - 11:10am

I've been complaining about this as well. Algos are important to understand, as are design patterns, if for nothing else it shows that you have interest in lower level components of design. However, at that point, it should be enough to just discuss them, their merits and why one might be a better fit for a solution than another. Many of these problems really only test memory, because once you realize the type of problem (variation on traveling salesman, for instance), then it's just regurgitating a textbook. So beyond the discussion what's the point of testing programming on a theoretical level.

One of the best interviews I was on, provided me with a couple of dependent classes and asked me to fix the result which was incorrect (exceptions being thrown, poor order of precedence, etc). After I completed that part, the interviewer asked me if and how I would refactor the application. It showed that you understood what the different components of the language did, how different variations of a collection might work, and if you were aware of the newer features that were available.

And seriously, shame on people who claim this to be about sour grapes. Not everyone has the same skill set, and if you don't understand that, you're most likely a poor teammate who thinks that memory recall == intelligence and craps on people for it.


Stephane Vaucher replied on Tue, 2012/03/27 - 7:54pm

IMO, it really depends on the position. In my line of work (software analysis), to be effective, you need to know how to understand and code algorithms because we deal with large data sets (in graphs) and have to stay in polynomial time. At a minimum, I need for someone to know what is a DFS and the pseudo code to get it to work. If someone knows can figure out why reverse post-order is useful, then it is a big plus. These are skills that are required to understand what we do. If someone has this basic knowledge, next up are engineering skills (testing and design).

David Cameron replied on Thu, 2013/01/31 - 1:54pm

After graduating the Michigan Technological University I applied for a job at VMWare and got hired because I knew how to solve the "puzzle". By doing this type of interview they get more objective and clear results even if it compromises knowledge about your other abilities, from high school I wanted to work at a major company like VMWare, the team I am working with is fantastic and we work on interesting projects.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.