I’ve been fortunate enough in my career to be on the “other side” of the interview table, the one asking the questions and I can come up with some doozies! But I never expect an answer that is spot on… so why ask the question?
It’s quite common to be asked very curve-ball questions in an interview. Some can be quite generic, others very specific. They usually have the same goal and quite often have little to do with the “correct” answer. In the IT game, particularly with the spread of connectivity, it’s less important to know the exact detail and more important to know the general idea. It used to be a valuable skill to know exactly what menu options you needed to click to make a new virtual machine if you were in the home screen of a vSphere client connected to a v3.0.3 vCenter… but these days, that type of familiarity with an interface is becoming common knowledge. Most high school students these days could fumble their way through that exercise based solely on years of Microsoft Windows GUI submersion, but yet they would have no idea of what it was they were really doing at the back end.
This is where a well constructed interview questions really come to the fore. For now I will bypass the more philosophical questions and just concentrate on the idea of a technical question in your specific field. Questions so unusual or off-grid that there is a 9/10 chance that you won’t have come across it before.
Firstly, if you are asked a question like this, you should feel somewhat privileged, because most interviewers (myself included) will have cut off well before here. For me, if you have validated your “paper experience” with some generic questions, then I will toss out the curve-ball.
So there you are, given some technical conundrum that, at first thought, you have no idea how to solve… good news! Every problem starts that way. If it were easy or common knowledge, it wouldn’t a problem! Bad news… there isn’t any bad news at this point. All you can do now is answer the problem with whatever knowledge you have at hand. You can, however, create a bad news scenario for yourself, but if you are willing to put ego aside and admit your own knowledge boundaries, then your interview will progress with ease, for better or worse, strange as that may sound.
Whenever I ask a really tough technical question, I’m looking for some basics around the question and then logic flow of where to go next. For example, if I asked a question that was relating to Kerberos authentication across trusted active directory domains, I would be hoping for answers that might include, “Validate trusts through AD domains and trusts”, “Check which domain client machine is in”, “Check with domain user is in”, “Confirm DNS resolution of both domains from client machine”, “See if there are any duplicate DNS names or computer accounts between domains”, “Verify network connectivity to server XXX”, etc, etc.
What I’m looking for here is some logical flow, some idea of where the problem might start, technologies it might rely on, some basic things you might check. It is amazing how many “qualified” professionals never consider, “Check that the cable is plugged in” as a step… but unless otherwise stated, even these base level diagnostic steps should be considered in your answer. If I had stated, “The server is powered on and we can ping it, but SSH fails”, then the details in question might forgive you from asking some of the lower level details, but if they aren’t specified, then don’t over think it. If you are in a production environment, you server won’t respond to a ping and that is all the information you have, then surely your first thought would be, “Is it even powered on?”. If not, you are overthinking the question.
The key is not to panic. I have never understood panic in interview scenarios. A bit of nerves nous I can understand… people you have never met before, grilling you on your life’s history can be a little daunting. What I try to do is put this spin on it, it’s some technically minded people, wanting to have a technical discussion. In that scenario under other circumstances, you either bring something to the table or you become a by-slander. The same applies in an interview. If you find yourself in a situation where you can’t bring anything to the conversation, don’t feel bad, you just over extended on this occasion or the employer wasn’t clear about what they were looking for. Just like other relationships, occasionally they start out with the best of intentions, but things just weren’t meant to be.
Hopefully though, the knowledge you have at hand will hopefully have some relevance to the field you are in and the question you’ve been asked, but never forget that statements like, “Search the vendor forums for …”, “Submit a ticket to XXXX support”, RTFM and even phone a friend are all valid, logical options. It just depends on what order they appear in. From an interviewer perspective, I’d rather see those things appear than not. Having to call upon a friend isn’t a weakness to me. In my opinion, that shows you know where your own knowledge boundaries lie and when it’s time to defer to a “higher power”.
So, to sum it up, how can you prepare yourself for a tricky interview question….
I would like to add one proviso to this whole piece… it’s fine to inflate your resume a little. Perhaps you didn’t actually configure the blade enclosure, but you subsequent administration of it means that if you had to, you could do the config this time around. That to me is justifiable inflation. Anything beyond that, it just an outright lie and these tricky interview questions are aiming to try and weed the latter of the two out. Do yourself a favour and just stick to the truth (plus reasonable inflation).