In the course of being a recruiter giving interview tips and advice and prepping candidates for interviews, there’s something I do certainly every week, almost on a daily basis. The single biggest tip I give to my candidates when it comes to actually performing within an interview, is to tell compelling stories.

A compelling story is something that the candidate has actually done in the course of their job history or personal life which proves to the interviewer that he or she has done this before and is therefore capable of doing it for the employer themselves. Let’s get straight into an example.

If you’re an IT support engineer and you’re asked the question “What are your skills like with Windows server?” A typical and not particularly good answer would be “Oh yeah I’ve used it quite a bit, I feel very comfortable with it.”

Just because you say that you’ve used it, then you say that you feel quite comfortable with it, does not prove to the employer the level of skill that you have with Windows Server technologies. Without doing a technical test, the only way to prove skill level in any particular technology is to be able to recount in detail with specificity, a specific example in your working life where you have been hands-on with that technology.

So a good answer to that question might be “Yes throughout the course of my previous role, I had the occasion to use Windows Server from an administration point of view on perhaps twenty to thirty occasions. We have one specific client who has three Windows servers and I’m the primary engineer for that client. Last month one of the Windows servers completely failed and wouldn’t start up so I went out on site, tried to boot it up it wouldn’t boot up, so I used one of the underlit Windows servers to connect to the backup system, locate backup for that server and then do some research and consulting of the disaster recovery documentation to work out how I was going to restore the server from the backup. After about five hours and several attempts, I managed to do a base level install of Windows Server from downloading the software from Microsoft and once the operating system was installed, I managed to restore the file level backup from the backup server and then proceed to rebuild the critical services like DHCP DNS and Windows update services. I had to do this entirely on my own because there was no senior engineer that was available or had any idea of this particular client or site so it was all down to me. During the time I was on site kept the client up to date with the progress as we went through and gave them estimated times of when they could likely expect to be up and running again. I also reassured them that their data wasn’t lost, that we did have a backup and I could access the backups so there wouldn’t be a data loss issue. Where possible I provided them work around options and gave them quick access to key files that they needed to keep working on some things during the day. By the end of the day when it was all up and running, the client was extremely happy with the work that I’ve done and the communication that kept up with them during the day. So on this basis, I feel very comfortable in the Windows server environment including recovering from a disaster, installing Windows server from scratch and setting up key components for a Windows file server. “

The reason why that is a good answer is because you’re recounting the story in an emotive way and with passion over time when you were specifically dealing with the technology in question that the interviewer asked. Because you are able to recount in the interview immediately off the top of your head specific examples of not just where but also how you have used that technology, is proof in itself that you know what you’re talking about because of the level of detail that you can go to about what you have done with that product.

The ability to tell a story in a passionate and interesting, even emotive way where you are the hero of the story and the one that solves the problem, is key to proving your ability to an interviewer.

So for most technical roles I recommend having four or five stories up your sleeve that you can tell to an interviewer at the appropriate time in the interview in order to answer the interviewer’s question. These stories would be things like:

1. A story that proves your technical troubleshooting ability.
2. The story that highlights your ability to go above and beyond for your clients or users.
3. That time when you’ve had to deal with a difficult client or difficult user.
4. Where you’ve had conflict within a team and how you’ve resolved it or got on with a particularly difficult team member.
5. A time where you’ve come up with an idea or initiative and seen that idea through to implementation.

Now you might not be able to use all those stories in a particular interview and just because you’ve prepared those stories doesn’t mean that you have to.

One thing that is not good to do is to try and shoehorn a story as an answer to a question that hasn’t been asked. While that might sound like a good idea, the problem is if the story doesn’t directly address the question that’s being asked. It can seem to the interviewer like you weren’t listening or that you’re going off on some irrelevant tangent.

So when you’re preparing your stories remember these three things:

Context is key.

Tell the story with the full setting, background, context, details about the client (but not confidential details), the timing (as in when this happened), the technical environment, what the problem was specifically and the emotional impact that this problem had on the client or users and yourself.

Problem definition.

Define the problem, what happened, why did it happen (if known) why it was a problem and the impact that this had on the client and the user.

Be specific in the steps that you took to resolve the problem.

Specificity is gold. Without detail you are not proving your technical expertise in solving the problem.

The key here is to be very specific in the steps that you took to solve the problem because that detail in itself will give the interview of the impression that you are really switched-on, very smart and know exactly what you’re doing with this technology that’s involved with this problem. And finally, in being specific about the solution, make sure that you are seen as the hero in the story.

Unfortunately I’ve come across too many times when I drill down with a candidate about their particular experience whether with a troubleshooting problem or a project or a piece of technology that in the end they tell me that they don’t actually really know how it was fixed because they weren’t the ones that found the fix in the end and yet it was the candidate themselves that brought up this story and their experience with this particular piece of technology.

So, don’t introduce a subject or your own technical expertise if you are not the one in the story that you’re telling who actually was the key hand in solving the problem.

Stories are critical to the human experience. Stories have been told for thousands and perhaps millions of years down through history and they serve to pass on experience, to explain phenomena, but also it connects us as people together and gives us a bond and conveys critical information in an interesting and exciting way. There’s nothing else you do to prepare for an interview, I would make sure you have a few good stories up your sleeve that you can tell as answers to specific questions relevant to what the interviewer is asking.

I hope this helps you prepare for your next IT job interview. Reach out if you need IT career guidance.