Software Engineering Interview Questions

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 lot of interviews in the past couple of 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 couple 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.

Lead UI Engineer and a Software Architect.
Over 12 years of professional experience, writing complex web applications, and still learning something new every day.
Currently working for Okta in San Francisco

Twitter LinkedIn Google+ 

7 thoughts on “Software Engineering Interview Questions

  1. Fromdev Architect

    You are so right…I always prefer to ask very basic questions and avoid asking any specialized or tool specific questions. The approach and fundamental knowledge matters not the fancy keywords in resume (which is unfortunately a trend these days).

    Reply
  2. Pingback: Javascript RPN Calculator | Simple ThoughtsSimple Thoughts

  3. Vicky

    I do not agree with you at all. Problem sovling questions help to gauge a candidate’s inate abilities and the power to imagine/connect. It enables the interviewer gauge how people handle something new/cold.

    I believe the interviews you referred to placed yourself and other candidates with similar experience under the same test. Whether elementary or not, it helps to evaluate your ability to connect with the basics.

    It is very important for a good engineer to able to remember the basics. For instance, after 20years of practice, I was faced with a problem requiring Quadratic Equation. I couldn’t remember the formular but was able to derive it from Completing the Squares because I took time to understand the basic principles in my elementary years.

    So in a nutshell, your position is misleading please.

    Reply
    1. Uzi Kilon Post author

      You don’t have to agree with me. Problem solving is indeed important as long as the problems are relevant and as long it’s not the only factor for the decision making.
      It also depends on what type of job you are looking for or hiring for.

      Reply
  4. Anonymous

    I have a question, what do you do when your interviewer (1) doesn’t know what position you applied for in a company & (2) has a hard to understand Indian accent? Because I was faced with a interviewer who had no idea what position I applied for & was so difficult to understand due to his thick Indian accent?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>