How to answer ‘What is your greatest weakness?’

So, Mr Johnson, what would you say is your greatest weakness?

Worst. Interview. Question. Ever.

In isolation, it’s an interesting question to ask yourself, it requires a great deal of honesty and openness on the part of the individual and it requires trust that there will not be repercussions for the answer.

Sadly, an interview is a place for none of those things. Candidates need, and are expected to, go out of their way to impress their interviewers and actively admitting weakness is a high risk strategy.

And yet it’s popularity remains, company’s still ask it and candidates still find a thousand and one tortured methods to say “I’m a workaholic”. In a novel attempt to get around this, one company used to ask for your three greatest weaknesses. I’d love to know what they gained from this.

So how should this question be answered? From personal experience, responding ‘My left elbow’ sadly does not work.

In comes down to framing, strengths and weaknesses are pretty much alternate views on the same characteristic. Above a certain level of competence it is rare to find people truely good at certain pairings.

For instance, think those people who you admire for their vision. These people are inspiring, charismatic they lift you up and show you a world that you dimly knew existed but couldn’t quite realise. Wonderful people, but tell me, how are they on detail? How good are they are dotting the Is and crossing the Ts and meticulously going through the minutiae of a project, ensuring that everything is as it should be. Not so much huh?

Clearly there will exceptions but Richard Branson, just isn’t a details kind of guy and nor should he be. Conversely I want an Accountant to be exactly the opposite, they need to get down to the details.

Since the question is now framed in terms of strengths it is much easier to answer. Just figure out what strength of yours you wish to highlight, determine how that makes you weak and then go for it.

Not convinced? Here is an example.

Imagine for instance the Great Remallo, Lion Tamer extraordinaire, sitting for an interview. His CV/Resume contains plenty of past experience dealing with many different types of lion and as the inventor of the lion proof cape he clearly knows his stuff. As the final question of the interview the Circus owner, Mr Top, fires out the big kahuna:-

Mr Top: Mr Remallo I have one final question for you. Tell me, what is your great weakness?
The Great Remallo: Well, Mr Top, if I had one weakness it would be that I seem to have trouble accurately assessing the level of danger I might be in at any given time, even as a small child when I used to play in traffic. Actually it’s something that really helps me as a lion tamer, I should think that if I ever truley understod the peril I put myself in everyday I would be petrified and never even enter the ring.

Still not convinced?  Let’s try the same question for a Software Developer.

My biggest weakness is that I can’t stand not knowing how things work, it used to drive my family crazy as took everything I owned (and somethings I didn’t) apart in order to see what was going on under the hood. To this day I really struggle to take things at face value if I can’t look and see what is going on. I suppose it’s one of the reasons I became an engineer in the first place, this drive to understand how things works stands me in good stead when wrestling with a gnarly code base or diving deep into library code, bug hunting.

I’m sure you can come up with something better yourself. Just remember if you reframe the question as an opportunity to talk about strengths, it’s then just a question of determining the flip side to that strength and using it as an in.

Anyone else got a good answer to this question?


Worried about candidates googling during a phone screen? You’re doing it wrong.

Interviewing is time consuming, companies have a finite amount of time to dedicate to recruitment and inevitably some capable candidates are turned down at CV stage without ever having a chance to shine.

Phone screens are a great way to address this problem, they are typically shorter and often run solo. They allow a company to take more risks and consider candidates from further afield.

My company is still pretty new to phone screening, we’ve been trialling it out in cases where it is difficult for the candidate to attend in person – perhaps they are based overseas. As a result I’ve been doing a lot of reading on how best to construct a decent phone screen. By far the best writing I’ve found is Steve Yegge’s take. I’m not sure how practical it is to fit everything Yegge mentions into a 45 minute call, but I consider it an excellent resource.

A common fear I have seen in other discussions seems to be that candidates will use google to somehow game the system. If this is a genuine concern then one of two things has gone wrong. Either:-

  • The questions are purely fact based and will tell the interviewer nothing about how the candidate thinks.
  • Or, the questions are fine but the interviewer is focusing on the wrong part of the answer.

A question like ‘In Java what is the difference between finally, final and finalize’ will tell you very little about the candidate. Plenty of terrible programmers could answer that without problem and what’s worse, a talented but inexperienced developer might stumble. In short these type of quick fire questions add little value to the overall process.

Something like ‘How does a Hash Map work? How would you write a naive implementation?’ is more interesting, it’s open ended but forces the candidate to talk about a specific area of knowledge – even if they don’t know, you’ll learn how good they are at thinking things through from first principles. The only way that it can be gamed through googling is if the interviewer simply waiting to hear specific terms and is not asking free form follow ups.

I’ve just googled Hash Maps on wikipedia and could probably quickly extract ‘Associative array’, ‘key-value pair’, ‘Collision’ but really if that’s all the interviewer wants to hear then the question is of limited value.

So what I’m saying is that if you’re concerned about googling, then it’s probably the questions or desired answers that are the problem. Furthermore if one in a hundred people do manage to game the system you’ll pick them up in the face to face in an instant.

Anatomy of a technical Interview

So you decided that you need to hire a new developer , advertised in the right way , vetted the CVs and even thought of some questions . Unless you’re in the 0.1% of people that think that a 90 minute chat is the best way to assess the skills of someone you may end up working with for the next 5 years you’re going to need to think really hard about how to give the candidate the best chance of showcasing their skills in a face to face interview.

This post won’t help with what questions to ask, but it will help with structure and maximising the chance of getting a good performance from a candidate.

Calm them down

First off let’s start right at the beginning, you’ve just met and are about to commence on some small talk, perhaps give an overview of the company – to be honest it really doesn’t matter what you say at this point, the candidate simply isn’t listening. Years of evolution are telling them to fight or flight  and it’s your job to calm them down sufficiently that you can move the interview forward.

Your end goal is to get to the point where you can ask them some really hard questions with a fighting chance of doing themselves justice, but first off there’s ground work to do.

Get them talking

Having helped them settle into their surroundings, it’s time to turn things up a notch and actually get them talking. A pretty good way is to go through their CV, their past work experience, university projects etc. This is stuff that they definitely know more about than you do, and should help them ease into the interview. The key point to remember here is that by asking very open questions and listening to what they consider to be most important or interesting, you can learn a lot about them. Good candidates will start explaining cool and interesting tech that they have used, while others will start talking about co-ordinating this and managaing that. Give people a chance and press them on the tech, but if they’re not confident or worse disinterested, then this is your first warning sign.

During this period you should be thinking about what sort of person you have in front of you, people handle stressful situations in different ways and if you don’t pick up on this you’re likely to miss some good candidates. e.g. if they are shy they’ll need some encouragement or if they are brash and perhaps little arrogant you need to be challenging them and forcing them to justify their assertions.

A final point, and one that I am most guilty of committing, is to make sure that you don’t go too far and overly relax the candidate. Doing so will make it harder for them focus once you start firing technical questions at them.

Getting technical

Before we get into asking any questions, I’d advise the following approach. Present the problem in a form that will probably be too difficult to answer, expect the candidate to need some help and judge their performance on quite how much help they need. This means that you’ll get an idea for how they think, smart candidates will have stretched themselves to solve the problem and poor candidate can at least solve the problem eventually, meaning that they won’t be so traumatised that they can’t concentrate on future questions.

As an initial technical question I’d recommend something pretty straight forward. Something like Fizz Buzz, I find candidates answer these sorts of questions in three different ways.

  • They write out the answer without even having to pause to think and you move on quickly.
  • They struggle a little bit, think things through and get the answer out. This isn’t necessarily a bad thing and might be down to inexperience, but it does mean that they are unlikely to hit the ground running.
  • They really can’t get the answer together and need a lot of leading. Alarm bells are ringing.

Next up I’d raise the difficulty, I’d suggest something wordy and open ended, perhaps some sort of systems level discussion. This means that the candidate can still push the discussion in a direction that they are comfortable with, but make sure that have at least of few things in mind that you will definitely discuss. Again judge them on the amount of leading they need before completing the question.

Now you’re ready to unleash the killer coding challenge, in many respects the whole interview has been leading up to this point, you’ve learnt a lot about them including how to get the best from them, but the next question will really set the best candidates apart. At this point in the interview you also need to consider whether it’s time to bail, if the candidate struggled with the toy programming question and couldn’t impress with your follow up question, then you really have to ask yourself whether it’s worth skipping the final challenge.

I would chose something that is initially tightly bounded but has the potential for significant extension should the candidate be up to it. Exactly what you go for is up to you, but if you don’t stretch the best candidate they won’t want to work for you.

Any questions?

Lastly it’s time to ask the candidate if they have questions, this in itself can be illuminating, though to be fair at this stage, the best they can do is reinforce a good performance. Questions about working attire and hours are generally a bad sign especially if not a final round, questions about version control, project management practices or something that came up as part of the interview are generally good things and provide an opportunity to sell the role.

After the interview

Once the interview is over, it’s time to come up with an decision. How you do is will be entirely down to your specific circumstances. For first rounds I tend to allocate a point for their programming, their systems and general technical common sense and finally a point for how well I think they’ll fit in. Anything over two and half, i.e. a strong performance in two out of the three and a good performance in the third is a thumbs up. For final rounds you can’t afford to let them leave the room if you still have any concerns unanswered. This is someone who you could end up working with for years so err on the side of caution.

Ultimately though, the only way to arrive at a good system is to have a lot of practice. Make sure technical staff are involved at the earliest possible stage and if you make a bad hire, don’t blame them, blame your process and learn from you mistakes.