A friend of mine interviewed for his first development job today. He’s been taking some classes on the side for the past few months in the hopes of making a career change to working in software. When I found out he got an interview, I had some advice I wanted to give him, but I wasn’t sure if I should just keep my mouth shut. Everyone’s different, including people who interview software job candidates, and not all of them will necessarily agree with me. But I gave it to him anyway:

1. If you don’t know the answer to a technical question (or maybe don’t even understand the question at all), don’t be afraid to ask for clarification. “Can you explain more what you mean by that” is better, in my opinion, than pretending to know what they mean.
2. If, after clarification, you still don’t know the answer, simply say so (and make a note of the topic so you can look it up later).
3. Finally, after having admitted you’re not familiar with what they’re asking, make an attempt to reason about the topic and perhaps make an educated guess.

Nothing profound, I know, but I think it’s sound advice. Especially if you’re a junior developer, it’s unlikely that you’ll fool anyone by BS-ing. It won’t save face, it will only make your ignorance painfully obvious. However, a mere “I don’t know” without any follow up isn’t great, either, because the interviewer might be hoping to see you struggle a bit and observe your critical-thinking process. Personally, when I interview developers, I’m not a big fan of that; if I want to see how they think, I’ll let them know: “It’s fine if you don’t know the answer, but I’d like you to use what you do know to make an educated guess.” But not all interviewers agree with me, so that’s why I included number 3.

To be clear, it’s still important to project confidence in interviews. If the interviewer says, “We’re looking for someone who’ll be able to help maintain our build configurations,” and you don’t know what that means, don’t reply, “I don’t know how to do that.” You can probe a bit to find out what’s involved, and then you should express confidence that, given some time to get up to speed, you can contribute to the team in that way. The point of this post is to admit what you don’t know when asked to comment directly on unfamiliar things of a technical nature, not to advertise a lack of confidence.