I Ask Basic Questions During Technical Interviews

Over the past 18 years at IBM, I have interviewed over a thousand programmers for positions within my team (which has a fair number of interns.)

Most of them are students from North American universities seeking an internship with us. Some were in their third year of undergraduate studies while others were completing their Ph.D.

For each position we post, we receive hundreds of such applicants. Their profiles are impressive (at least on paper) so we can afford to be highly selective and make the students jump through hoops. But we don’t.

My Interview Process

When I first started I used to ask tough algorithmic questions. What I learned pretty quickly was that you don’t need gruesome interviews to separate the most talented candidates from the rest.

This goes against my instinctual bias as I love algorithms and mathematical problems. But I also found a tenuous correlation between those who could make a Red-black tree twerk to their command and great web developers.

Of course, teams working on implementing database engines instead of web development, might benefit from said twerk masters.

At any rate, in most cases, if your candidates need to study a book specifically on how to pass interviews to survive your tech interview, your process might be broken and you might be missing out on a lot of great candidates who didn’t spend the past three months optimizing for the interview on Leetcode.

Now, I conduct a quick 30-minute interview asking questions considered basic by most. Candidates who do well during their first interview and are likely to get the job are promoted to a second interview.

This second interview, conducted with my manager and me, is not technical at all. It’s mostly about explaining what we do, selling the candidate on the idea of joining us, as well as answering questions they might have. In essence, the “hard” part is the first interview.

During that technical interview, I don’t ask tough questions. The questions I ask are arguably very basic.

What I do, however, is ask questions that give away one’s experience with web development. I also really pay attention to the answers I get. I don’t need hard questions, because the answers to these basic questions are extremely telling.

A Basic Question Example

I’ll give you two examples of basic questions I ask. The first one is, what are your two favorite programming languages? Let’s say that the candidate replies, “Python and JavaScript”. I will then ask them what they like about each and list some technical differences between the two.

Guess what? Great candidates will give away in their answers a deep understanding of types. Less strong candidates will confuse dynamic typing with weak typing and struggle to mention any difference between languages that are quite different. If they do, to rule out nerves, I’ll drop hints to see if the poor answer is due to a lack of knowledge.

From here, we turn it into a conversation from which other questions arise. Asking you about your design choices for a particular project you’re passionate about tells me a lot more about you than reciting the solution to an A* problem.

Here is another one. What are some differences between a GET and a POST request?

A weak candidate will not be able to name any differences. That’s an easy way to weed out people who put React and Redux on their resumes but don’t have any familiarity with web development in practice. Or people who followed some tutorials on YouTube without actually understanding what’s going on. Résumé inflation makes this occurrence sadly common.

The most frequently mentioned difference is the data submission method (URL vs body). Generally speaking, that’s what I expect to hear given the lack of seniority of prospective interns.

However, even with such a basic question, stellar candidates will start talking about idempotence, caching, security concerns, data size limitations, ASCII vs binary, conventions within the REST paradigm, etc.

Now, some candidates are more loquacious than others so I tend to ask follow-up questions to fish out knowledge of other differences if that knowledge is there.

For example, if the answer is, “POST submits the data with the body while GET puts it in the query parameters”, I might ask them in which scenarios that can be problematic. Or even, “Why is it a bad idea to use a GET method for a login form?”

The question is as simple as they come for web developers. But the answers can be very telling.

I often hear from candidates who didn’t make the cut that they still enjoyed the interview process and remark on how they found it less stressful.

Does It Actually Work?

In case you’re wondering, the success rate of this approach has been remarkable. So much so that I have other teams reaching out asking us about our secret sauce.

BTW, I think recruitment is only one ingredient of the secret sauce. Another substantial ingredient is our stellar senior developer team members who are paired with new interns to mentor them, as well as other initiatives we have to train them effectively.

On that note, a telling sign that this approach works is that the candidates we select grow quickly when they join us.

The aforementioned senior developers were interns hired with this process years ago and they are simply amazing. Even when I look at the LinkedIn profiles of former interns we couldn’t keep on our team once they graduated, I see impressive careers at some of the best companies (and a few who founded their own successful companies).

And finally, the interview is only one data point in the many factors I consider when evaluating a candidate. Past projects carry a lot of weight too, for example.

This overall approach works for us. I’m not claiming it will work for everyone but perhaps a different way is possible within the industry.