Stop with the Computer Science Interview Questions Already

Over the years, I’ve been on both sides of the interviewing table, as many of us have. And I think there are only a few more annoying and more or less useless interview questions than the ones that ask about specific, often obscure, computer science questions.

You know, the ones that ask about things like “which sorting algorithm is more efficient?” You know, if you are regularly writing sorting code, this is hugely important to be able to pull off the top of your head. Otherwise, a quick internet search and maybe half a day max refreshing yourself on this topic will be enough in 99% of the cases to tackle such a performance optimization. And the reality is that most — certainly most business software — is built on frameworks that handle this for you.

Only slightly less useless is “tell me what a closure is in JavaScript?” There are literally 1,000,000 blog posts about this topic, with “what is a promise?” coming in at 999,999. Arguably, promises are more important to understand. But in any case, these are easy for a smart dev to pick up, and there is currently an almost irrational focus on them in the Web dev interviewing world. It’s a stupid litmus test to see if you can be a good front-end dev.

In the majority of software development jobs, questions like these are mostly irrelevant to one’s day to day success. And when they do become relevant, you can do some quick discovery and trial and error to find the best solution. They will almost NEVER make or break the success of a project.

Equally as useless are the trying-to-be-clever off the wall interview questions. You know, the “why are manhole covers round?” type questions. Or as parodied in The Intern — “you’re a nickel in the bottom of a blender, how do you get out?” They are fun brain teasers. It’s fun to watch people squirm (if they haven’t memorized the “right” answers already), and it makes those who know the answers already feel smart. But they are useless at determining future job effectiveness. Don’t believe me? Here’s more behind that claim.

What will make a dev project fail? If a dev is lazy about code quality practices is one. Understanding how a dev thinks about code quality is a key indicator. Do they write automated tests? Which kind? When? How do they determine “good enough” for test coverage? How do they practice refactoring? These are strong indicators and not something you can just Google to figure out, without a ton of effort and practice (which is why it’s important to have it up front in most cases).

Another key thing that can make or break it is attention to UX. Does the candidate understand what UX is? Why is it important? Do they have examples they are proud of to show their efforts in this area? Do they prototype? How? There’s a lot to dig in on for this area. I could go on and on here. :)

Debugging is another crucial developer skill that is usually overlooked. Drill into that — how do you approach a typical bug? What is your process? What tools do you use? Tell me a story of a particularly difficult bug and how you resolved it. This is a skill that can be learned, of course, but it’s like code quality — the more practiced you are, the better.

As Bock notes in the article linked above, if you can get actual work samples, that’s hugely helpful. This is more than “coding” off the top of your head in a whiteboarding session. A dev needs time to think about a problem, ask questions, maybe consult some of their favorite resources, and then structure a solution — with testing ideally.

Giving a scoped sample task is probably the #1 best way to get a sense of how someone approaches solutions — covers things from project structuring, model structuring, layering, testing, and yes, commenting. Tell them to approach the scoped problem like they would a real project. Or if they have an OSS contribution they can point to, that is good. (It’s important for the commit timeframe to be public, so you know it is theirs.) But in the absence of that, a small sample based on a scoped problem is great.

And beyond all the dev-specific skills, you need to ascertain cultural fit — this is far more important than specific technology skills. Bock (and others) highly recommend structural interviewing for these skills. There are a lot of resources out there for this.

Can we — the industry — please start setting better expectations for the interview process? Having someone cram on rudimentary CS questions to interview well is useless. Having them cram on all the “clever” interview questions is useless. Coming in and whiteboarding through or handwriting code is not very useful either. I would argue that most online Q&A tech assessments are not very useful, but they can be better than the above.

It should be a baseline assumption to apply for a software dev spot, you will spend some time coding a small solution. We’re talking about like a few hours, max, of investment by a qualified candidate to vet fit for a long-term working relationship. It’s a worthwhile investment of time.

But too many companies don’t do this, so candidates will take the easy route when confronted with that. This company is making me an offer after talking for a couple hours in person. This one is asking me to do work?? Asking for work samples should not be the exception! It should not be “I will only do that for a really well-known company I am desperate to work for.”

All of us hiring software folks should raise the bar. We all say we want top quality people, but usually our hiring practices show otherwise. It’s hard to find good talent, and it doesn’t help anybody when we make it easy to get into bad fits. This is not good for candidates, and it’s not good for companies.

Many companies, I believe, are already doing better with interviewing along these lines, but I’ll step out on a limb and say the vast majority are not. We — all of us — can do better. So let’s stop with the CS interview questions already and focus on what really matters and set the industry bar a little higher. It benefits everyone if we do.