The Coding Interview (and me)

As someone with many years in the software industry, and having recently gone to a number of interviews at big and small companies, I find myself mystified by the coding interview.

Maybe it makes total sense when looking for a junior developer, less than 2–3 years of experience, where maybe there is not a lot of background and experience to draw from about real projects and it easier to evaluate with only coding questions.

“Fundamentals” are key, and understanding the trade offs of using different algorithms and data structures is really important, there is no question about it, but at the same time, I think this is only one dimension of being a software engineer, specially for senior positions or for people that have been in the industry for a few years.

Don’t get me wrong, as an interviewer you must make sure that the person you are interviewing knows how to code.

I usually check for that coding skill by asking a simple problem, I know simple is in the eye of the beholder, but something like

  • Main classes and methods to build a Battleship Game
  • Method to check if a sudoku solution is valid.
  • Main classes and methods to build a Car Rental App

Depending on the answers I’ll go quick or slow on these, and in all cases I’ll ask to implement at least one method fully, to be able to go over error conditions, boundary conditions, etc. If things are looking dire, then I’ll fall back to a fizz-buzz variation, but at that point things will not be looking good for the interviewee.

Most of the rest of the interview will be around previous experience, hardest bug, hardest performance issue, and in general with questions related to what I am looking for the particular position (concurrency, high scale, high uptime, robustness, resilience, monitoring, etc depending on the project’s specifics.)

Above all I am looking for a smart engineer, someone that can take previous experience and use it when appropriate and discard it when not. Someone that will be able to see a problem from all its dimensions and not only one, i.e. not only performance, not only testability, not only memory usage, not only <insert here your preferred important thing>, real world problems are often a balance between all those competing technical dimensions plus the business dimensiones (deadlines, budgets) and in many cases even political dimensions (which organization, which boss, etc), and engineers that can only be good a one of those are just not great.

What I found in latest foray into the interview world, was the incredible prevalence of “The Coding Interview” which consist of 4–6 hours of only coding questions, along the lines of: reverse a string, function to build string based on other two, LRU cache, frequency counter, find words, propose alternate words, find loops on linked lists, etc…

I believe there are books and sites entirely devoted to these questions, where some developers will spend a fair amount of time getting ready for these interviews. Maybe I should have done that, but I devote all my working time to my job, and then I have other interests in life: paper-crafting, electronics, wood work, leatherwork, and a few others, oh! and I have a family too. I have no problem putting the time to learn new stuff and get up to date on whatever tech I need, but these books and sites feel more like a step into the past.

In a few companies there was not a single question about my experience, or even about things like: concurrency (this at companies offering web applications), scalability, resource utilization, databases, distributed systems, engineering best practices, production support, bottleneck finding and fixing. Think about it: I spent 5 hours with a multitude of people, of which not one of them showed any interest for my experience.

In other words many times there was nothing about me and how I would benefit the company, I know I might sound a bit on the egocentric side, but I want to work for a company that wants me, not a generic developer/coder, but me, an engineer with my baggage, with my own ideas and experience to make beautiful products that perform and are robust and solve things for users and all of it while working with great people in great projects.

Originally published at on July 17, 2015.

Show your support

Clapping shows how much you appreciated Webclimber’s story.