“I Don’t Know”

One thing that’s inevitable in a growing software company is that engineers are tasked with the chore of interviews, and I’ve done more than my fair share of talking with candidates through technical problems and projects they’ve done and why leave a company and how systems should work.

I also enjoy writing about it.

So here I am sharing1 another of my pet peeves: don’t try to fast talk your way past an interview.

This usually takes the form of the interviewee hedging against a difficult question by using increasingly vague buzzwords and terms. The candidate is feeling out the interviewer(s) to see whether they’re on the right path, and unabashedly try to tease out additional hints while making it seem like they’ve made progress on their own.

One telltale sign from the candidate is that they’re answering to the expectations of the interviewers instead of looking at the question itself; they’re not trying to solve the problem in an elegant and efficient manner, but tailoring their answers how the interviewers react. They’re quick to agree, but add nothing substantial between the increasingly obvious hints.

And sometimes, if I feel particularly annoyed by wishy-washy responses, I’ll try asking a question that I know is out of their area of expertise, something that they would have no realistic way to figure out in the context of an interview.

I want to hear, “I don’t know.”

This is not to boost egos – it’s better to give a candidate a good experience regardless whether they get an offer or not. Rather, the question is simply testing whether they know what they don’t know and are willing to admit it, so when I have real questions, I can be assured that they can give a direct and honest response. Embracing ignorance and remaining humble is actually a strong sign of the willingness and amplitude to learn.

We should all want to work with that developer.