I’ve been doing a lot of technical interviews for my employer, 10th Magnitude, as our portfolio grows and we need to bring on more Azure talent.
And I’ve spotted a pattern. One that I know I’ve repeated myself. One that is absolutely fatal to anyone I am trying to qualify for a role.
This huge mistake that almost every applicant makes?
Trying to give an answer when you don’t know the answer.
What’s the only right answer when you don’t know the answer?
“Let me get back to you on that.”
Or its near cousin:
“I don’t know, but I am going to find out.”
‘… Speak and remove all doubt’
Really, which of those phrases you use is a preference. I prefer “let me get back to you on that” because it tacitly admits ignorance, which tends to be less jarring than “I don’t know”, and thus makes continuing the conversation or changing subjects easier.
But admitting ignorance in a technical interview is far better than making up an answer or worse, using a barrage of words to cover for it.
Consider: The screening interviewer asking you the technical question knows the answer. If you don’t, what are the chances you can bluff your way out of it?
Zero, of course.
But that’s usually OK. Because as long as you know most of the answers, you’re probably going to pass the interview. Especially in this tech market, where every warm body will eventually find something.
Interviewer: “Have you worked with Azure Functions?”
Applicant: “A little. I built a couple API endpoints with it.”
Interviewer: “Really? What does that API do?”
Applicant: “It keeps track of when employees use a key card to enter the building. That helps the company track staffing needs.”
Interviewer: “Interesting. Do you think an API App would have been a better way to host it?”
Applicant: “Let me get back to you on that. I can say I built that API with Functions because it was pretty simple and wasn’t going to see much use.”
If I have that exchange with a candidate, I would report to the recruiter that she understands what Functions are and how they work, but isn’t an expert on App Service.
And I guarantee you that’s going to be enough to get that person hired. Especially in this job market.
Blind man’s bluff
I recently interviewed a candidate looking for an Azure solutions architect role. He claimed to have worked with Service Fabric and Azure SQL Database.
So I asked him to explain when I would want to use Service Fabric versus an Azure Function. I got a 10-minute soliloquy in which the candidate failed to describe the features of either service correctly.
What was a better response? “I’ve not had a use case where I had to balance those options. But I can tell you that when I built the Service Fabric solution, I chose it because …”
If he did that, he would have at least demonstrated some ability to architect a solution. But trying to mask his ignorance by iterating features, in a blind hope that if he talked long enough, I would forget the question I asked, was a perfect contribution to failing the interview.
I then asked how the candidate would describe the caveats and “gotchas” in Azure SQL Database, to someone who is looking to migrate an on-premises SQL Server to PaaS. I got a 5-minute speech that time, which was basically a recital of the Azure SQL Database service overview.
What was a better response? “I’ve not worked much with SQL Server. Let me research it and get back to you on that.”
In this case, the candidate didn’t actually need to know a lot about Azure SQL Database. Knowing what it is, how it works and some example use cases would have been enough.
But this person claimed to have used Azure SQL Database in production. And he is applying for an architect’s role. If he can’t describe how Azure SQL Database is different from on-premises SQL Server, then he can’t architect.
Mind you, there was no digging his way out of that hole. But I could have forgiven his ignorance if he had stuck to what he knows, and used that magic phrase:
“Let me get back to you on that.”
Better for acknowledging faults
The key here is that you can’t bluff your way through a technical interview. Or, more specifically, any company where you can successfully bluff your way through a technical interview is, in practice, a terrible place to work.
Since you can’t know everything …
… and you can’t fake your way out of it …
… your only option is to prove you’re going to do something about your ignorance.
That’s the beauty of “let me get back to you on that.”
- It’s a neutral statement, which is less jarring than the comparatively negative “I don’t know.”
- It takes ownership of the fact that you don’t know: “Let me get back to you on that.”
- It provides a definitive action, rather than cowardice. You’re not admitting defeat; you’re going to go get the answer.
Next time you take on a technical interview, remember to say “let me get back to you on that” any time you’re stuck. I think you’ll be be pleased with the results.