Tricky interview questions

Posted: December 1, 2011 in Information Technology, Rants

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….

  • Don’t panic! Its meant to be tough, there are usually a number of applicants, employers are looking to really thin out the herd.
  • Don’t rush to answer the question just because you knew something about the 8th word in the sentence. Properly consider the question… Are they really asking about a CommVault issue or are they looking for you to diagnose an underlying network issue?
  • Follow through the logical steps from the most basic point, unless these are overruled in the question. Start at the physical layer unless the interview has given a scene where this is assumed all good
  • If you have knowledge at a particular step, expand on it, but don’t leave it as your last resort. “Phone a friend”, or supplier, etc. is still a valid option. No one knows everything about a product, even the guy who designed it!
  • Know when your knowledge has reached an end and be willing to openly admit it, but don’t let that stop you throwing out some other needle-in-a-hay-stack options. This shows you’ve had experience to a point and then have some random ideas about what you might do next. Combined with the step above, that’s about all I would ask.
  • Leave your ego at home. Interview questions this tough are meant to test the personality as much as the person’s knowledge. I’d rather have the humble employee who knows when they are lost and will stop and ask for directions, than the fool who blindly believes his own BS and takes us all off a technological cliff!
  • 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).

    1. Truth…plus reasonable inflation. Love it!
      It’s a great post which – apart from the specific tech questions – applies to people in all fields.

    2. […] you are interviewing candidates to fill a position or you are the candidate, this post on Tricky Interview Questions is worth a read. Like this:LikeBe the first to like this […]

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s