19

You are in the process of looking for candidates for a software development position, all the resumes are reviewed, and you made a couple of interview invites. Now, the folks show up in the conference room onsite, and you begin the back-and-forth talking about past experience, reviewing the resume, the personal development interests, etc.

In your experiences of hiring, what were the responses (and questions) that you wished you had processed better initially that may have stopped you from hiring a poor candidate?

I am looking for some red flags to watch out for, and hoping to be discerning enough.

Improve this question
4
  • 8
    This is a very broad question as some responses would no doubt relate to the specifics of a particular job or vary from person to person. Additionally, I think this question might not be very unique to programmers if the responses you're looking for are about more generic HR-type questions.
    – Adam Lear ♦
    Jun 3, 2011 at 17:26
  • 4
    Definitely looking for responses to programming/software-type questions.
    – Randy
    Jun 3, 2011 at 17:29
  • Not always, but very often there is an inverse correlation between buzz word use and ability. The best at XYZ are more often the ones who can explain XYZ in insightfully simple terms.
    – hotpaw2
    Jun 3, 2011 at 19:12
  • 1
    I think you really want to read Joel Spolsky's "Smart and Get Things Done"
    – Julien Guertault
    Jun 6, 2011 at 3:52

11 Answers 11

Reset to default
35

The only thing I know for sure is that there's a correlation between obfuscating, avoidant, yet overly confident answers and my desire to not hire the candidate. This is my personal "red flag".

Some candidates don't fully answer questions in a satisfactory way and instead they will verbally dance around a psuedo-answer. Above all the goal of these candidates is to never say I don't know. They'll use buzzwords, but they'll also use other strategies to try to appear intelligent and knowledgable. They'll also refer too some project they were on in the past but can't describe that well exactly what it was or how it worked, but they'll emphasize how difficult it was. They'll appear to have a very confident demeanor despite an inability or lack of desire to dive into the technical details. They'll be really good at getting the managers excited about hiring them, but the devs have a hard time making heads or tails of them. They will never use the phrase "I don't know".

They're good at not admitting they don't know something, so I can never say for sure they're 100% bad, but I never feel comfortable recommending someone unless I feel I learned something about that person and they're work. I usually have a very strong positive reaction or a grumbling "maybe!?!", and I've just learned not to recommend the "maybes".

Improve this answer
9
  • 2
    +1, Great point. I believe one of my better qualities that I have learned to say I don't know. It may feel embarrassing at first, but better that than painting yourself into a corner that you don't know how you got into in the first place.
    – Randy
    Jun 3, 2011 at 17:47
  • I disqualified myself in an interview one time by bluffing on my knowledge of OO patterns, and then getting called on it. Sad time. But I learned a lot about myself and pressure situations!
    – Dan Ray
    Jun 3, 2011 at 19:29
  • 2
    So, what can you ask them to ensure that this is one of those that never say "I don't know"?
    – user1249
    Jun 3, 2011 at 19:56
  • 4
    @Thorbjørn: "So, do you have experience working with <made-up acronym that means nothing in your industry>?
    – Michael Borgwardt
    Jun 5, 2011 at 10:15
  • 4
    I've actually said "I don't know." before at interviews and usually followed it up with a "But I would like to learn about that" or asked the interviewer about it as well so I can read more about it after the interview.
    – rjzii
    Jun 7, 2011 at 13:02
22

An amusing filter is the following. Give them a list of buzzwords for different technologies, and ask which they have worked with. Make a couple of them fake made-up technologies. Anyone who claims to have worked with those is a no hire. (Someone actually made up a networking technology, wrote up a good web page describing it, and then used it in phone screens. Any candidate who read back his fake description when asked about the technology was a no hire. I forget the name of the technology.)

More seriously, the biggest things you want to look for are signs of honesty, ability to learn, and how well they will fit in. If they say that they know X really well, and can't answer questions on it, they are not a hire.

More specifically if you're looking for a specific skill set, then try to have an interview process that reflects that.

For instance at one place I used to work we would give people the description of a real but simple application (generate a bunch of reports for use in playing fantasy baseball). We'd ask the person to design a database schema for this. Then we'd ask questions about how their schema would handle various issues. Then we'd ask them to write some specific queries against their schema. This process closely reflected how our CRUD application actually was designed, and so was a good filter for the exact skill set we wanted.

Similarly when we wanted to hire a front end HTML person, we had a graphic artist layout a realistic page, and then cut graphics. All of the candidates were given the image and the graphics, and were asked to write this in HTML in their own time. They were judged by how well their HTML page reproduced the image given, how clean the HTML was, and whether it worked in different browsers. When they came in we asked a couple of questions about the HTML (basically to verify that they actually wrote it) and checked personal fit. That was in fact the workflow that they were going to face in practice, and it proved to be an excellent filter.

So look at what you're hiring for, figure out the skills people use in daily life, and then design a realistic interview that actually tests that. It won't be perfect, but it will be a lot better than most organizations' craptastic interview processes.

Improve this answer
5
  • 7
    +1 for making me laugh in the first paragraph. I love it! I actually know an interviewer who does this, and it works pretty well.
    – Mason Wheeler
    Jun 3, 2011 at 18:30
  • 2
    tell them you're looking for someone with 10 years' experience with Google's "go" language [announced in 2009] en.wikipedia.org/wiki/Go_(programming_language)
    – Steven A. Lowe
    Jun 3, 2011 at 22:04
  • 2
    @Steven A. Lowe: I always thought that the companies that put that sort of stuff in their requirements were just clueless. They are using it as an intentional BS filter?
    – btilly
    Jun 3, 2011 at 22:17
  • 9
    @btilly: no, they're just clueless
    – Steven A. Lowe
    Jun 4, 2011 at 1:56
  • 3
    @btilly, @Steven: I think that happens mostly in large companies where hiring is done by the HR department and the IT department is only indirectly involved. So IT writes "we need someone who knows Go" and HR says "we're not hiring amateurs, so let's make that 10 years of experience in that Go thing".
    – Michael Borgwardt
    Jun 5, 2011 at 10:20
14

I am looking for some red flags to watch out for and hoping to be discerning enough to not fall into any of this: Is there a correlation between buzz words and ability?

Yes. People with too many buzzwords tend to not be capable and try to hide that by making themselves appear flashy, always following "the latest technology". I'd be extremely skeptical of anyone claiming to be an expert in too many things, especially if they don't have the professional experience to back it up.

Of course any lies are instant cause for ending the interview.

Improve this answer
5
  • 4
    +1, Agreed, fibs are intolerable. Proving them as lies, more difficult.
    – Randy
    Jun 3, 2011 at 17:45
  • 2
    One thing I've noticed is that people who don't actually understand the concepts behind a buzzword tend to misuse prepositions in the same sentence. Silly example -- Them: I program under C++. Me: Oh, really? How far under?
    – Peter Rowell
    Jun 3, 2011 at 21:22
  • 2
    I have met several recruiters that are addicted to buzz-words, if they don't see the candidate use a lot them, they dropped :-s
    – umlcat
    Jun 7, 2011 at 19:15
  • of course, umlcat, those exist. But do you want to work for them? I've even experienced headhunters that'd add buzzwords to resumes to "flesh them out" without consulting the candidates first.
    – jwenting
    Jul 7, 2011 at 6:15
  • I once got turned down for a job because the interviewer asked me what the acronym IOC stood for - its a three letter acronym and could mean anything depending on context. If he had asked what I knew about Inversion of Control I could have answered as I had used it before but he wouldn't tell me what the acronym stood for because that was the answer I was supposed to know - apparently qualified candidates have exactly one meaning for the IOC acronym... I learned then that if you don't know the buzzwords and acronyms you aren't good at your job - even if you have used the technology before.
    – Jerry Jeremiah
    Nov 8, 2016 at 22:28
10

Get them talking about specifics. Preferably about their pet projects. If they don't have any, that would be an orange flag to me, but still acceptable. In that case get them to talk about a project of which they are proud.

Get concrete, avoid the abstract chit-chat about anything. Get a couple of developers in on the interview if you yourself aren't up to par in the specifics. When you get down to the nitty-gritty of what someone is proud of, what challenges they encountered and how they overcame them, there is little room to hide behind buzz words.

Improve this answer
6
  • 1
    pet projects... what if you are overly worked at your job and have no pet projects as a result.
    – Ben B.
    Jun 3, 2011 at 18:50
  • 3
    @Ben B.: Like I said, not having pet projects is an orange, not a red flag. I prefer people having pet projects, but I understand that there are good reasons not to have them. Being overworked at your current place of employment would be one of them.
    – Marjan Venema
    Jun 3, 2011 at 19:02
  • +1 for talking about specifics. If the candidate can't go into design/implementation of something they worked on and talk about why they did it that way, it should be a red flag that perhaps they didn't actually do the work.
    – Tyanna
    Jun 3, 2011 at 19:08
  • I will consider "pet projects" as a plus, but there are interviewers that drop people, because "pet projects" are distraction
    – umlcat
    Jun 7, 2011 at 19:16
  • @umlcat: I know those interviewers exist. They are shortsighted. I for one wouldn't want to work anywhere where petprojects are considered a distraction...
    – Marjan Venema
    Jun 7, 2011 at 19:26
9

I've found that when someone talks only about their responsibilities in a job and not their actual accomplishments that usually means they won't be able to deliver a working product. Programmers who produce real deliverables can tell you about them in extensive detail.

Improve this answer
1
  • 4
    but may not be allowed to under NDAs. I have that myself for various projects, can only talk about what and how we did them in rather vague terms, not mentioning any company, product, etc.
    – jwenting
    Jun 4, 2011 at 12:21
6

Bad-mouthing of former employers or colleagues excessively. Criticizing specific decisions is OK, but someone who goes on and on about how incompetent people were is probably arrogant and overbearing towards everyone and incapable of teamwork.

Improve this answer
1
  • 2
    I always tell people to go for a 'practise' interview before any job you really want. No-one leaving a company does so because its wonderful and perfect, so the first thing they want to do in interview is get a load off their chest. And they do. I understand this and try to see past it when interviewing.
    – gbjbaanb
    Jun 5, 2011 at 12:20
5

Now, the folks show up in the conference room onsite and you begin the back-and-forth talking about past experience, reviewing the resume, personal development interests...

In your experiences of hiring, what were the responses (and questions) that you wished you had processed better initially that may have stopped you from hiring a poor candidate?

Tales from the Interview would be a bunch of horror stories if you want some entertainment or specific examples of where things go bad.

Look at how various questions are answered and consider what kind of style does the person seem to be using and how well does that fit with your team? For example, how well do they like structure and formal procedures? What kinds of questions do they ask about the company? While I understand Joel's take of wanting someone smart and can get things done, there are many pitfalls that if a person hits enough of them, that would be what could take them out of contention. These would be more yellow flags though if a person gets enough of them, that should be equivalent to a red flag. While a minor mistake shouldn't get you kicked out, if you make a dozen of them that may be another story.

Improve this answer
1
  • 1
    Nice link, thanks! I also really respect Spolsky's view, but my experience is that some of the best programmers can be so anti-people/anti-other's ideas that they essentially zero out their positive contributions to the organization.
    – Randy
    Jun 3, 2011 at 18:40
4

The best way to start looking for fakes starts from their resumes. Absence of clear start and end dates in the employment history is a good sign. If there are multiple employers and or projects, when you question them about thier experience dont ask them serially (in chronological order). Ask them randomly, for example just when he is describing his fourth job/project ask him something about his second job or ask "ok tell me about the one before that". A faker is bound to fumble

Improve this answer
2
  • (+1) I agree with the goal, you describe, but, that method sometimes gives false responses. Sometimes, I do not register or remember the exact dates. And these days, projects are short medium term, not 1 year or 2 years
    – umlcat
    Jun 7, 2011 at 19:07
  • @umlcat. I agree it is not foolproof. it is a human tendancy to forget. But it really would be a good pracitce to note down your project assignment/reassignment dates or store such mails. Project start/end dates are easy to forget but company joining dates/release dates are more easy to remember.
    – DPD
    Jun 8, 2011 at 7:06
0

The most obvious ones are where the candidate is more interested in what they'll get from the job rather than discussing how they would fit in with the work.

eg. "how much money will you be offering me", "how many holidays do you give", "what car will I get". You can add "how much training will I get", "I want to work with , will I get trained in it".

I've also rejected candidates who want to talk more about why they want the job - one guy preferred to tell me all about his holiday cottage and lifestyle and needed the job to fund this.

All red flags for someone who is not interested in what you want them to do at all. I know we're all only really interested in these things, but they are not for discussion at interview. The interviewer is representing the company and wants to hear only the things that benefit it. The time to discuss these things is after you've been offered.

Improve this answer
0

For me there is a little bit of the reverse.

Does the candidate inquire about the Company enough?

e.g. If there was no mention of which Version Control "this" company uses, what we use for bug tracking, automated builds, or what the components of our development stack is built on... and the candidate doesn't ask about it I'm concerned the candidate is just "looking for a job", vs. trying to find a suitable position for their career path.

Improve this answer
0

One of the first things I do in an interview is have the candidate rate (0 - 10) his skill and knowledge levels on various subjects that are interesting to us. Zero means he never heard of it, ten means he invented or wrote the seminal book on the subject. I always include the skills we specifically mentioned in our advertised job description.

It helps me flow the interview, since there's no point in talking about subjects he doesn't much about. As Joel is right to look for 'smart and gets things done', to which I add 'and is honest'.

I try to drill in to the areas he or she claims to be strong.

For example, if the candidate rates his C++ as strong, then I'll ask him to write a function to do something really simple with strings, like print out the reverse of a string, or count the letters in the string.

If the candidate's function looks like this:

void MyLittleStringFunction(char* str) { /* raw pointer manipulation here */ }

I know the candidate lied to me. He's just another C programmer who has no real experience with C++. Anyone who has actually used C++ would use a string library. I don't care which library, if he's an MFC guy I have nothing against CString, although unless MFC was mention in the job description I expect most C++ devs would default to std::string.

No candidate knows everything about every technology used in my company or yours, but he or she better be honest with me about what they do know.

Hiring a candidate who faked his way through an interview into a job they can't really do is a disaster for the company and the candidate

Improve this answer
2
  • 2
    I hate it when interviewers ask me to rate my skill level. It's a loaded question where if I answer a high number they'll either: A) Think of me as cocky B) Assume I'm lying C) Try to crack me and if I answer low they'll think I'm not a good fit since I don't know enough. This question makes me (and likely other interviewees) feel very uncomfortable. And since we all know the best programmers are humble...what are you really looking for here?
    – Casey Patton
    Aug 1, 2011 at 23:43
  • I'm trying to save both of us time. If you rate yourself as '1' on something, why bother to even ask the question? OTH whatever skills you rate as high (where 'high' is relative, every person has his own scale, I don't care about absolute values) then I will dig deeper into that area. Nobody has every skill needed for any real development job, we understand that. We're looking for honesty. Its not a trick question.
    – Jim In Texas
    Aug 12, 2011 at 4:20

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