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?

  • 16
    Ah screw you, who are you to judge others?
    – Job
    Commented Jun 9, 2011 at 4:44
  • 3
    Seems off topic, this would apply to any profession. Commented Jun 9, 2011 at 5:28
  • It's worth noting the guy ended up quitting himself after a couple months.
    – Gopherkhan
    Commented Feb 10, 2012 at 19:42

8 Answers 8


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.

  • 2
    It's also pretty obvious in an interview. Better IMO to go through the code they write and just pick something to be a little unreasonable over, see how they react.
    – Мסž
    Commented Jun 9, 2011 at 4:27
  • 34
    Trying to purposely irritate a candidate is just plain rude. And you run the risk of the potential hire thinking that your company is comprised of a bunch of jerks, or if they realize what you are doing, thinking you're a bunch of scheming jerks. Show the candidate the respect you think they should be showing you. Commented Jun 9, 2011 at 5:33
  • 4
    @Richard What do you mean by point #1? It's an unordered list :P
    – alex
    Commented Jun 9, 2011 at 6:31
  • 4
    @wolfgangsz: And, as a hiring manager, what do you do when you irritate your first choice hire - who is talented and wonderful to work with - to the point that he calls you an arse and leaves? He is evaluating you as much as you are evaluating him. Unless you're very careful you'll come across as needlessly argumentative and unpleasant, and who wants to work with that? Not you, apparently, which is why you're doing it in the first place. Why would he have lower expectations of you than you have of him?
    – Ant
    Commented Jun 9, 2011 at 10:23
  • 2
    @wolfgangsz: You don't use it unless you think there will be a problem. That's great, but the comment still stands. Every time you use that trick there's a chance that you're wrong, the candidate is perfect, and it will backfire on you horribly.
    – Ant
    Commented Jun 9, 2011 at 10:35

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.

  • Sometimes those programmers insulting your code and intimidating you are actually doing just that xD It's best to assume they're not but I've seen and ran across a couple scenarios where I knew for a fact it was no act they put on for the person they were interviewing. Like you said, it's still a way to see how a person will react to harsh criticism, which from my experience will likely crop up at least once in a while (usually near release xD) Commented Oct 19, 2017 at 21:16

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 :)


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.

  • 3
    So that's the thing. Personal references are usually hand picked by the candidate, and not all that helpful. The problem is when a previous employer has a policy of not providing references. They can say yes, they were employed, and whether or not they would be allowed to be employed with the company again, but nothing as to their character.
    – Gopherkhan
    Commented Jun 9, 2011 at 3:54
  • 1
    Fair point. My last experience in this was actually interviewing a nanny for my kid. The referee we phoned was her previous employer and obviously a close friend. Her reference was so good that we knew we couldn't trust it. We ended up not offering the job based upon this manipulation. As it turns out, the woman in question was a bit of a bunny boiler. As I see it, you have the screen the referees as much as you do the applicants. I've had one arrogant prick get past me in an interview and I spent ages working out what I could have done to pick upon it sooner. I came up blank :-(
    – dave
    Commented Jun 9, 2011 at 4:05
  • I'd like to hear more about this arrogant person story, if you want to tell.
    – user1249
    Commented Jun 9, 2011 at 9:57
  • The problem of organizations refusing to give references is a growing one IMO. 3 of the past 5 employers I've had refuse to give references as a matter of company policy. It makes it very difficult for you to provide professional references. And these are large multi-national companies that I'm talking about. Commented Jun 9, 2011 at 15:25
  • @Thorbjørn Ravn Andersen - said programmer saw a team of a dozen coders who'd been developing an application for years and declared it was all a waste - he could rewrite the whole system himself in 6 weeks. He actually believed this. This was typical behaviour. His rationale was simply that you take out all the business logic (ie: what people actually wanted) and give the (internal) client what he thinks is important. As a person, he was fine but as a co-worker he was difficult.
    – dave
    Commented Jun 9, 2011 at 17:30

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.


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.

  • Erm... and this answers the question how exactly?
    – fretje
    Commented Jun 9, 2011 at 12:01
  • 1
    @fretje: It gives a perspective from the other side of the table. I would call it a useful data point.
    – Robusto
    Commented Jun 9, 2011 at 12:06
  • I think it's a silly idea to choose a company based on your experience with the interviewer. In my response, where I complained about the nasty interviewer who insulted my code, I took the internship anyways and haven't had any bad experiences with people since. The interviewers don't represent the whole company. You should have a better reason than "didn't like the interviewer" for not choosing a job. Commented Aug 19, 2011 at 0:37
  • @Casey: As an intern you have that luxury. In a senior position, however, with a family that relies on me to be a provider, I don't.
    – Robusto
    Commented Aug 19, 2011 at 0:41
  • I suppose it depends on the company. The company I'm working for has thousands of employees, so it seems a little silly to refuse to take the job because I didn't like one guy there (who probably works in a different building anyways). In a smaller company I could see not accepting the offer, as it may be more indicative of their culture. Commented Aug 19, 2011 at 0:56

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.

  • 4
    That could be fun to watch, but probably not the right solution :P
    – Gopherkhan
    Commented Jun 9, 2011 at 3:24
  • 1
    A good talking to can do more harm than good, depending on where the "touchiness" is coming from. Two extremes of the scale: unwarranted believe in one's own abilites leading to "I can never be wrong"; unwarranted lack of confidence and seeing every criticism as a threat or a prelude to dismissal. Find out where the person sits on this scale before "the talking to"... Commented Jun 9, 2011 at 6:06
  • @Marjan - or in other words, in some cases you want to skip the "talking to" and show him the door ... or put him on a project where he doesn't need to interact with normal people.
    – Stephen C
    Commented Jun 9, 2011 at 10:01
  • no. Problems are never solved by avoiding them. In case of "I can never be wrong" a good talking to has my blessing. If that repeatedly doesn't help, dismissal comes into view. In case of unwarranted lack of confidence: make sure feedback doesn't take the form of "bashing" (for anybody) and get the low-confidence person a coach to help them deal with feedback. You would be supprised what a little attention can do and how much productivity you c/would then get from someone. Commented Jun 9, 2011 at 10:36

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.

  • 1
    +1 For interviewing the interviewer! Just as often as employers hire bad employees, employees join bad employers. Years of interviewing taught me the right questions to ask and how to interpret their reactions. I have asked about average turnover "Some people need to find an environment they are happy in." WARNING, any answer other than I am not sure should be skeptical. On development processes, "We are trying to go Agile" or just "trying to" anything. WARNING, sign of dysfunctional leadership or management. Probe them about they have tried and why they think it failed.
    – maple_shaft
    Commented Jun 9, 2011 at 12:11
  • 2
    If you had pulled the table towards you to write on, you'd have gotten into the MiB.
    – TheFogger
    Commented Jun 9, 2011 at 12:16
  • table was not one you could move, was a loooong square block of adjoined tables and everyone was sat around the block. it was well thought out :D Commented Jun 9, 2011 at 12:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.