Edit, 6/26/2012: This post is my personal rant about interview questions. If you got here looking for actual programming interview questions, I can recommend these books: Cracking the Coding Interview and Programming Interviews Exposed. These books helped many engineers getting their dream jobs.

It’s no secret I’ve been in a bunch of of interviews in the past few years, both as an interviewer and as a candidate. When it comes to tech interview questions, to simplify things, I can break it into 3 major types:

1. Implementation questions
2. Architecture/design questions
3. “Problem solving” questions

The first type intends to check your experience with current industry standard tools. For instance, as a javascript engineer you will be asked about specific jQuery method, what problem it designed to solve, and how you can effectively use it, how a web browser works, or what is the HTTP protocol.

The second type intends to check your software design skills, and your ability to design a complex application. As a front end engineer, you will probably asked about MVC concepts, RESTful architecture, or design patterns.

The third type intends to check how well you handle with random problems you didn’t expect. However, in many cases, this part is a tricky, and mostly out of scope. It’s not that I don’t think a good engineer should have strong “problem solving” skills. I do. I just think most of these “problems” you are being asked about has nothing to do with what most of us actually do on a daily basis.

In my past interviews I was asked algorithmic questions, mathematical/geometry questions and physics questions. Hell, I’m surprised I wasn’t asked to solve rocket science problems. After all, my “problem solving skills” are being measured. When an interviewer asks a front-end engineer questions that yield for BST traversal, how to test and optimize algorithms, or how to calculate the distance in pixels between a mouse click and each dom element on a given page, they probably:

1. Want to check what you remember from your undergrad CS classes
2. Did not read the part of your resume that says you don’t have a CS academic background
3. Have no idea what front end engineers do
4. All of the above

In either case, you are probably being asked the wrong questions. Don’t get me wrong, algorithms are a fascinating part of computer science, and it is important to understand the basics, but at the end of the day what most engineers struggle with most time is NOT algorithms, but software architecture. We all know that poor performance can be tuned, and fortunately, we also know that poor architecture can not be easily tuned.

Most of the modern engineering challenges are not to write the perfect algorithm to begin with, since you don’t have the perfect understanding of your problems set to begin with. The challenge is to abstract the algorithms in such way it will be easy to later improve/replace them without rewriting big parts of the application.

So, if in a 4 hours session with 4 different interviewers you are were asked a bunch of “problem solving” question, and you weren’t great at it, there’s no reason to worry. Your interviewer, which is probably an experienced engineer knows there’s no reason to worry about this.

However, if MOST of your interview questions were about “problem solving”, and you sucked at it, don’t feel too bad about yourself. You do not want to work for that company to begin with. Such interview is most likely a disclosure that this company (or team) has no idea what the challenges in modern software engineering are, and they are most likely wasting their time solving the wrong problems (which were probably solved before). You do not want to work there.