On Software Engineering Interviews

Interviews are always fun but also time consuming. The entire process can get stressful, because you don't know what you're gonna run into or where you're gonna end up going. After going through a bunch of interviews I'm starting to notice real issues with interview processes at many companies and I believe that the normal interview process is broken.

By normal process I talking about a process where you send out resumes or a recruiter from a company reaches out to you and wants to schedule a conversation. Typically what follows after that is a tech interview (most likely Skype/Google Talk), if that goes well you do another one onsite. Finally, you might get cultural fit interview (depending on a company size) with a bunch of folks. As you get older and the time window from when you graduated college till now gets larger, the tech interviews are becoming more difficult. Let me explain why.

In a technical interview you are asked to write some code and solve problems. The problems usually revolve around some particular computer science topic, e.g. trees or graph theory. I've asked these types of interview questions myself. All of us who work in the field have done it. However, it's unclear what exactly they are trying to test.

• Your ability to recognize and memorize graph algorithms?
• Your ability to write code?
• Your ability to solve problems?
• All of the above?

These types of problems are fine for someone who just graduated college and doesn't have track record showcasing their achievements. However, they are completely irrelevant in most cases, because such questions do not test whether you actually can do things. Let's step back for a second and think about why the company is trying to hire in the first place. All the company needs is someone who can solve business problems, be it through engineering or accounting. Engineering solves these problems in one way, accounting does it in another. The expected result is the same — added business value and increased revenue or profits. Then we should ask ourselves, how can we test engineering talent and make sure that this hire will create enough value for the business? I leave this question open, because I don't know the answer myself.

Such interview questions are not an issue as long as they are not at the start of the interview pipeline for more senior engineers. The first tech interview in most cases is the gatekeeper to the next ones. If you fail this one, you will not be able to participate in the next interview round. It does become more problematic for a seasoned engineer to pass it if the question is tackling a very specific computer science problem. Why is it problematic? Because almost 100% of the time you will not be solving these types of problems at work, and people forget things. We have such interview questions because today's companies are run by children who don't know any better. There are lots of new startups popping up everywhere due to the excess VC capital and all of them hire cheap college graduates who interview people based on what they've been taught at school. The same type of problems are evident in a more established companies because they hire same type of people and don't educate them what really matters. There's too big of a gap between engineering and business folks. It's not about solving difficult puzzles, or trying out new languages — it's about creating value for the business. So, how can we test people for value creation? I'm not sure, but I know a few things that should happen.

• Interviews should be done by more senior engineers who ideally have much closer relationships with upper management and understand business needs.
• Very specific computer science questions should be left to more junior candidates, because they lack experience; unless the business needs someone who knows answers to these special questions.
• You should still test programming abilities, but it's much better to do so via a take home exercise that mirrors real-world problem. In later interview steps you could walk over the solution and ask design related questions.

What I've written so far, does not apply to all companies. There are exceptions. I'd like to leave this post as an open discussion and finish it here.

I'm really excited to hear what other people are thinking about the engineering interviews today.