I don’t know the answer to that, but let me find out for you…

“When in an IT job interview, admit when you don’t know the answer to a technical question, but give an example of how you would find out the answer”.

It’s often cited as a top tip for IT job interviews, something that hiring managers respect and appreciate.

That’s all well and good, and more than likely sound advice, especially when the alternative is to potentially dig your own grave trying to spoof an answer to a subject you have no knowledge on.

But does that attitude and advice carry over to the real world? After the interview, on the actual job, do IT professionals openly admit they don’t know the answer to technical questions?

I find more often than not the answer is no!

Us IT guys like to be right. We like to show off our knowledge. We like to be the go-to source of information for our field. But it feels like there’s a huge difference saying “I don’t know” in an interview setting compared to saying the same in front of your work colleagues and peers.

The people you work with on a daily basis are more than likely roughly equal to you in a technical sense, even if their field is different. I think a lot of technical people don’t want to be “found out” for not knowing something, that they will lose the confidence of their colleagues if they admit to not knowing something which is expected of them.

The result of this is often very negative in my observations, both for the person bluffing and for the person posing the question.

Let’s take a simple example, as it’s easier to explain the outcomes. Sarah is an IT project manager tasked with co-coordinating the deployment of a new datacenter. She asks the company sysadmin, Adam, a question on VMware vSphere licensing. Adam, not knowing the answer but not wanting to look uniformed in front of her, confidently but incorrectly states that each host will require a single vSphere license. Sarah leaves happy, confident that Adam knows what he is talking about. Adam on the other hand, wipes a bead of sweat from his brow, and wonders was that the best move…

Not a great example, but you get the idea. I see this kind of thing all the time, and have been guilty of it myself. It impacts negatively on both parties.

Firstly, before things even get to misinformation being provided, Adam runs the risk of getting called out for his answer. If anybody involved in the conversation knows the actual answer, even if they don’t directly call Adam out on it, they will earmark Adam as somebody who provides incorrect information and is not to be trusted in their response to technical questions. Getting called out in this way can be incredibly embarrassing and damaging to your professional reputation.

After answering, Adam has put himself in a very awkward and potentially damaging position. Knowing he was asked something he was not 100% sure of, he goes and researches VMware licensing to confirm the answer he gave, only to find out that it was incorrect. Does he now go back to Sarah, and have to admit that he gave her wrong information? This is far worse than having admitted not knowing the answer in the first place, particularly if some time has passed. Does he stay quiet about it, and hope that he can cover his actions down the road? This could result in project delays or overshooting budget. Either way, he has caused stress and anxiety for himself, and planted doubt in Sarah’s mind going forward about Adam’s technical knowledge.

Sarah, unknown to her, will now base her project on incorrect licensing information. This may result in an inaccurate budget or incorrect licensing being purchased. Sarah believes Adam is knowledgeable on VMware licensing, and will come to him again for further queries, or direct other colleagues with VMware licensing questions to him.

In contrast, had Adam simply stated that he doesn’t know the answer but will find out, all the above could have been avoided. I find that colleagues do genuinely accept this answer, and it’s often followed up with something like “No problem, just try to get back to me by tomorrow”. Adam provides correct information, Sarah bases her project on accurate licensing costs, everything runs much more smoothly for the sake of a quick Google or phone call to your reseller.

I’ve been guilty of all of the above before. Being asked a question and faffing about with a half-arsed hesitant answer is just not worth the risk. Even when an answer has been accepted, I’ve been on the receiving end of that “does this guy really know what he’s talking about?” stare. Not a comfortable place to be in, especially if more probing questions follow.

Recently I’ve been saying “I don’t know, but let me find out for you” a lot more often, and each time it has been for the best. I notice much more when my colleagues say the same, and absolutely appreciate when they take the time to confirm their answer first before getting back to me. Likewise, I more often notice when a colleague is bluffing, or has to reach for the excuses box to cover up some poor information he has given on a subject he was lacking knowledge in…