Three Interview Questions that Matter Most

I’ve interviewed a lot of people over the years. Most had applied to join companies that I’ve founded or organizations that I ran. It’s hard to get to know someone in 30 minutes. It’s harder when both sides are in full-on sales mode (me pitching why they want to work here; the applicant pitching why we want them).

Over time, I’ve developed three simple questions that tell me a lot about a technologist. Like hiring managers everywhere, I look at what skills a person brings, whether they will execute and deliver, and if they culturally fit with the team.

What I try to assess beyond that, especially for technologists, is how they think. Nail these if you ever want to get hired by me. Since I started using them, I have never hired someone who answered badly (there is a difference between a “bad” answer and one that’s factually “wrong”). I promise to explain why I’m asking what seem to be unrelated questions, but only after I have the answers. I’m sharing my questions so that others might build upon them.

Question 1: “How many telephones are there in the United States?”

I actually don’t know the answer to this question, nor do I care. What I care about is how someone approaches a problem that wasn’t well defined. I look for the breadth of their thinking; did they include office phones or just home? Mobile phones or just landlines? How it was defined doesn’t matter; what does matter is that he or she identified the ambiguity and clarified it. If asked what types of phones I’m including, I always respond with “that’s up to you.”

Once the problem became clear, how did they approach it? I want technologists who know how to break a problem down into parts and solve it in an organized way. Consider the number of adults/businesses/households, estimate phone density, and repeat.

The only truly awful answer is “I don’t know” or a random guess with no thought.

This question has only failed me once; an applicant immediately responded with a number. When I asked “how did you get that?” he told me that it was referenced in an article he had read the day before. Even that had one upside...at least I knew that he read and remembered things!

Question 2: “How does a toilet work?”

This question is designed to probe for intellectual curiosity. A toilet is a device that each of us has used every day of our adult life. Any engineer that hasn’t bothered to open up the back and look in the tank (or other mechanism, depending on where one lives) isn’t someone I want. I believe that problems are often solved by applying tools and techniques from other disciplines so I try to hire people who want to know how everything works.

Again, the only failing answer is that they have never cared to look. There are degrees of answers that range from good (able to describe the mechanism) to very good (able to describe it using the correct terminology for the flapper, float valve, etc.). Once, an applicant not only described the mechanism, but then explained the physics and connected the two. I made him an offer that same day.

Question 3: “Tabs or spaces, and why?”

The newest addition to my list elicits the most passionate responses. I’m still tuning how to probe the responses, in part because when I tested it on some very competent people I didn’t get the answers I expected. Still, I believe it delves into an important aspect of solving problems and I’m determined to get it right.

The important part of the question is “why?” When writing code, indentation is used simply to make the software more understandable for the next reader. The compiler doesn’t care if you indent at all (Python programmers may now object). Most programmers and engineers appreciate this. Please don't tell me that tabs consume fewer bytes on the disk— disks are cheap and the amount of storage saved or consumed is negligible. Focus on this and you are solving the wrong problem.

\What’s shocking is when they fail to apply their understanding that this is all about the next reader. Indenting works fine with tabs or spaces, until you get more than 2-3 indents deep. Then, lines of software often no longer fit on the remaining space on the screen. They “wrap.” Splitting lines unnecessarily makes the software harder to read. Not impossible, but if we are doing this for the convenience of the next person, we should make it as convenient as can be practically implemented.

“Spaces” is a good answer if the “why” is thoughtful. So is “tabs at the beginning, but I change to spaces when indenting more than a couple of levels.” I’ve even accepted answers that say if you have more than three levels of indentation, the code needs to be refactored to be more readable. The only failing answer is to not understand “why,” followed by understanding but refusing to apply it in practice.

Some have defended a “tabs-only” approach by saying that the next person should adapt by resetting the default “tab-stops,” the number of spaces that equates to a tab. They miss the point...if we are trying to make this easy for someone else, we shouldn’t impose extra work on them.

As I said, the answer to this one often surprises me. With many, the choice of tabs versus spaces seems to be tied to a deep-seated beliefs system, with those in an opposing camp labeled heretics. Fans of the HBO show “Silicon Valley” will doubtless remember Richard’s epic rant when he realized that his new girlfriend uses spaces.

Maybe he should have asked “why?”