How can you filter out irritable programmers in interviews? [closed]

Question

So I've had a few situations now where programmers have passed the interview teams with flying colors, only to find when they arrive on scene, they demonstrate an extreme touchiness any time any criticism is leveled their way. I'm not talking about off-day irritability, but a 24/7 bruised ego thing. For certain employees this pertains to code review feedback, but others it can even include debugging suggestions (even if they're right).

How do you filter out touchy candidates during the interview process in a manner that won't get you in trouble with HR? (I'm thinking something far short of Blade Runner here). Additionally, how can you help those types of programmers better deal with both real and perceived criticisms?

Answer 1

You can't. Anyone with half a brain could put on a show and appear perfectly employable. What you can try is:

• Using that interviewing technique where you ask the candidate a question and keep telling them they're wrong. See how they react and respond to this pressure.
• Ensure necessary disciplinary are present and sustained for unruly behaviour once they are employed.

---

Edit: I shouldn't have to write this, but seeing GrandmasterB's comment and the flurry of negative comments, I will. Surely you've all read Joel's guide to interviewing.

Inevitably, you will see a bug in their function. So we come to question 5: Are you satisfied with that code? You may want to ask, "OK, so where's the bug?" The quintessential Open Ended Question From Hell. All programmers make mistakes, there's nothing wrong with that, they just have to be able to find them. With the string functions, they'll almost always forget to null-terminate the new string. With almost any function, they are likely to have off-by-one errors. They will forget semicolons sometimes. Their function won't work correctly on 0 length strings, or it will GPF if malloc fails... Very, very rarely, you will find a candidate that doesn't have any bugs the first time. In this case, this question is even more fun. When you say, "There's a bug in that code," they will review their code carefully, and then you get to see if they can be diplomatic yet firm in asserting that the code is perfect... In general, it's always a good idea to ask the candidate if they are satisfied with their answer before moving on. Be Regis.

My suggestion is merely adapting this technique to deduce whether the candidate has a bad temperament.

Answer 2

Interestingly enough I've heard something similarly from a friend who's training to be an airline pilot, they give them some task to perform but the actual task is not the problem but whether they stay calm or get angry/irritated. So give them some kind of (physical) puzzle that's extremely hard or unsolvable and insist they solve it and see what happens.

Then there's the apocryphal story about wall street interviews where potential employees where asked to open a window that couldn't be opened too see how they'd react. One guy actually took a swing at the window with one of the office chairs, I think he got the job :)

Answer 3

Isn't that what a reference check is for? People with any brains will not show their true colours in an interview. When I used to interview people I would sometimes ask them to talk about the biggest mistake they've made and what they learned from it. I kind of figured that requires a combination of experience and introspection to answer adequately. Few people ever came up with anything useful.

Answer 4

I once had a programming interview where the interviewer seemed to constantly intimidate me and insult my code. I thought it went horribly until I got an offer! Now, this practice was a little extreme. However, I do think you should put their code under some stress and see how they manage it. One tool that I think might be valuable is casting some doubt onto their code. This interviewer tended to do a lot of "that's correct? are you sure? No bugs?" etc (even when my code was perfectly fine).

Another thing to do is just make sure to do a long enough interview. Everyone might seem nice and perfect right when they just get there, but spend enough time with them and you'll probably see their true(er) colors come out.

Answer 5

If I found an interviewer to be harassing me, complaining that a piece of code I knew to be bug-free had a bug in it, I would first comb through the code and see if I could understand what he was talking about. I would be diplomatic, and open to the possibility that I had made a mistake.

If I could find no problem with the code, and the interviewer persisted — especially in an irritable, confrontational way — I'd first try to grin and test whether he was putting me on. "You're kidding, right?"

And if that failed, I'd just say, politely, "I don't see the problem. I stand by what I wrote. I could refactor it, possibly, but I would have to have a context in which to refactor. Can you give me a use case that invalidates this approach?"

If that elicited unpleasantness I'd simply get up, thank him for the interview, and leave. Then I'd tell the headhunter I did not want to work at that place, and not to send me on interviews that were going to waste my time.

Answer 6

Easy. Include one of your most irritating staff members on the interview panel ... and watch what happens.

---

More seriously, I don't think you can expect to achieve a 100% hit rate with your recruitment. Lets face it, there are not that many perfect candidates in the pool. And most candidates are going to try to conceal any problem traits that they have. And mistakes will made ...

The bottom line is that management needs to be prepared to take firm action to deal with problem people who are causing disruption and a poisonous attitude. If "a good talking to" doesn't help, then more serious steps need to be taken.

Answer 7

Play advocatus diaboli. Ask them a subjective question during the interview, and whatever answer they give, represent a different point of view. See how they react.

Answer 8

Sometimes, the lengths to which interviewers go to in order to determine what a candidate is like are borderline ridiculous.

I work as a CTO/Lead dev so have had experience interviewing myself.

Pondering career options, I attended an interview for a start-up recently and found their methods a bit weird. I was not greeted properly nor was I introduced or spoken to much. Instead, I was taken into a corner, made to sit into an uncomfortable chair, handed a printed test assignment (code) and a pen.

There was not even a clipboard to write on so producing code on one's lap on loose sheets of paper, particularly when you're supposed to be nervous, seemed a bit of an overkill. After the initial shock, I collected myself and came to the conclusion I was being tested to see how I would react. I had typed one function definition on my knee when I asked if I can just use my laptop's text editor instead. Unsurprisingly, they just nodded and agreed. Resources are there to be used!

Seems they must have been reading the same sources / pointers about testing programmers aptitudes as the good question on their part was how I would improve it and make my solution more performant (a theme on the bug thing mentioned above). This is when it becomes interesting. It's all subjective anyway - though you may think of ways of improving it, the interviewer may not and may just be playing on your ego, testing you further. Do you admit to writing it less than perfect on the first version, you put on a show and think of cosmetic changes, do you offer other solutions or do you uphold your initial code whilst showing an openness to improvements. What has more value to an employer anyway, there needs to be a balance.

In any case, the most important thing to remember--as an interviewer--is that the interview process works both ways - after being put through hell, I finally took my turn in asking some questions about their business model, the short and long term plans and so forth.

Surprisingly, the answers that I got that were less than reassuring (or perhaps it was deemed above my station to know more). Questioning the employer's very business idea and model (in order to understand them better) before launch, even gently suggesting it seemed like niché that would be difficult to market had the exact result I was afraid of. The CEO got VERY defensive, almost took offence and went way out of his way to reiterate what a wonderful idea it all was.

Also -- if you're a startup, you need to plan beyond the seeding money or any chance of offering job security to candidates goes down the can. Remember, you are selling your company too! Joining a starup is risky anyway, you need to offer some reassurance and particularly so when you head-hunt people who are not pressured to find a job in the slightest. Your employees need to believe in what you do if they are to make your venture a success.