Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm conducting technical interviews to fill a few .NET positions. Many of the people I interview really do know .NET pretty well, but I find at least 90% embellish their skillset anywhere between "a little" to "quite drastically". Sometimes they fabricate skills relevant to the position they're applying for, sometimes they don't.

Most of the people I interview, even the most egregious liars, are not scam artists. They just want to stand out among the crowd, so they drop a few buzzwords on their resume like "JBoss", "LINQ", "web services", "Django" or whatever just to pad their skillset and stay competitive.

(You might wonder if a person that lies about those skills is just bluffing their way through a technical interview. My interviews involve a lot of hands-on coding and problem-solving – people who attempt to bluff will bomb the hands-on coding portion in the first 3 minutes.)

These are two open-ended questions, but it would really help me out when I make my recommendations to the hiring managers:

  1. Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

  2. Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?


locked by ChrisF Apr 9 '15 at 18:26

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by ChrisF Apr 9 '15 at 18:26

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

@jmein: Nope. It is not programming related, therefore it should not be here. – Geoffrey Chetwood Feb 19 '09 at 19:00
@Rich B: Agree. This is generic to any employer and belongs on a site devoted to those issues, not here. – jason Feb 19 '09 at 19:03
Just because something could be relevant to non-programmers doesn't mean it can't live on SO. This is highly relevant to developers responsible for hiring and developers looking for jobs, and here we can focus on hard technical aspects, rather than generic "lying" as you'd find on – Rex M Feb 19 '09 at 19:48
Kinda hard to earn a living at it if you can't get a job – kajaco Feb 20 '09 at 16:10
@m4bwav: there is no criteria that defines what should or shouldn't be wikified. Wiki is used to prevent people from gaining rep (read "winning the pissing contest") for "fun" questions. My question is not "fun", it's technical merit and utilitarian value is certainly applicable to programmers. – Juliet Feb 20 '09 at 16:21

37 Answers 37

Should I attempt to determine whether a person really possesses all of the skills they claim to have?


To determine if they're a big fat liar? Or to humiliate them? Or to prove your total technical superiority?

Or to make a hiring decision?

Be sure to distinguish between doing the right thing in hiring and being a jerk about nuances on someone's resume.

Some people say "experienced" but you wish they said "exposed". Does that make them a evil liar? Or does that mean that their definition of experience isn't as rich, varied and deep as yours?

If you suspect they're lying -- and it would be a bad hiring decision because of this -- remember your real goal.

You're just making a hiring decision.

If they're big fat liars, don't hire them.

If you think they've "overstated" their experience, perhaps your use of the words are just as wrong as theirs. Does it matter? Do they have to be converted to your way of writing a resume? Or can you simply determine what they mean by the words they use?

If you're not sure, probe their experience. You don't have to make someone uncomfortable to arrive at a meaningful, useful assessment of their skills.

In general, when I talk to people, I like to get a feel for their technical background. I came across a guy who put JBoss on his resume, which is a pretty heavy technology, so I asked him to describe the apps he's written with it -- turns out he couldn't even define what it is, and (cont...) – Juliet Feb 19 '09 at 19:14
(...) was embarrassed that he'd been exposed. Oops! Not my intention. However, from a hiring perspective, a diverse skillset can affect a person's salary -- a good bluffer might be able to weasle his way into a senior position, and the company gets a smaller ROI for hiring the guy. – Juliet Feb 19 '09 at 19:18
In my experience, being modest on the resume is a Bad Idea. I wouldn't worry about somebody being as favorable as possible about themselves, short of actual dishonesty. – David Thornley Feb 19 '09 at 20:47
+answer: I was discussing this issue with the hire-ups, and they wanted me to go down a person's resume line-by-line to see if their skillset checked out. They even wanted me to intimidate people by asking them to cross off anything on their resume which "may have been inflated". (cont...) – Juliet Feb 20 '09 at 20:17
@sleske: Good advice, but "Built" might be too vague. The correct combination of "Designed", "Coded", "Tested", "Deployed into a web server", etc., should be included to describe what you actually did. – S.Lott Oct 15 '09 at 11:22

You have to assume that anyone who claims to know anything on their resume is lying. There are many different definitions of "experienced" or "fluent", and until you agree on those, claims on a resume are meaningless. The only thing you should care about is what they have done in the past and whether that means they will be able to help your company in the future . The point of the interview is to determine what they have actually done and how that will apply to the job you are interviewing them for.

That being said, if someone is obviously a good liar, send them to sales :)

One can't be obviously a good liar. It's an oxymoron. Or the nearest rethorical figure. – Adriano Varoli Piazza Feb 19 '09 at 19:11
+1 for the sales joke. It was a joke, right? Right...? -cries for humanity- ;-D – Adam Davis Feb 19 '09 at 19:17
+1 for last sentence – ryeguy Feb 19 '09 at 20:01
Sales Rep on call: "We can do it", looks at developer emphatically shaking head no we cant!!, "we can do it and we will finish 1 week early" – BigBlondeViking Sep 22 '09 at 16:01
If everyone lies on their resumes, then what's the point of asking for a resume? – Robert Harvey Aug 8 '10 at 17:16

1) Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

No. Find out of they posess the skills needed for the job you need them to do (and if they're "Smart and Gets Things Done").

2) Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

Yes. Then make fun of them mercilessly about a month after they started as your coworker. This is assuming they lied about knowing Java, and not lied about getting that Master's degree.

I haven't worked with C in a couple years, and if I sat down with a terminal and gcc and tried to write something in it I'd be going to google every 5 minutes. If I had to write C code on the whiteboard I'd forget all sorts of stuff like what malloc returns when it fails or the right syntax for declaring a typedef. I still feel I know C, and I'll still put it on my resume. I don't think I'm "lying", it's just writing a paragraph for every language on my resume explaining my experience with it, and how out of practice I am is impractical.

Based on your description of your C knowledge, you are not "experienced" with C, and therefore it should not be on your resume, unless you say that you are merely "familiar" with it. – Robert Harvey Aug 8 '10 at 17:17
Disagree Robert - If someone has 10 years of experience with C, but has been doing other stuff for the last few years, I would expect them to be rusty with C, but be able to get back up to speed very quickly. Like riding a bike. – red-dirt Jan 24 '11 at 10:50
@red-dirt: Exactly. So on the resume, you can just write "C: Built xx app as lead developer, 1998-2005". Then the reader can judge whether that is too long ago or not. If you brushed up regularly by e.g. contributing to a free SW project, you could append something like "Collaboration in free SW project XY, 2006-2011". That shows that while you didn't use it professionally, you did keep the knowledge alive. – sleske Nov 21 '11 at 8:35
@RobertHarvey: As to "experience" vs. "familiar": As other comments pointed out, the problem is there's no universal definition of what "experience" means (though there's a vague consensus). If you used it for a month, is that "experience" or "familiar"? What about 6 months, 1 year, 3 years? That's why it's best to avoid these labels, and just list your experience. – sleske Nov 21 '11 at 8:37

I generally don't care too much about the specific skill sets listed on the resume. I just ask them about the work they do/have done. The word matching part of resumes is unfortunate for all concerned and I blame the recruiters.

If the person is/does blatantly lie about experience then of course you want to consider if they are a good fit for you.

I never really let the specific buzzwords and acronyms and languages get in the way of figuring out of the person is good for hiring. People in our field are supposed to be able to learn and solve problems. Knowing a specific technology is not a big deal, hiring for a specific skillset is not a good practice in my opinion.

+1, especially for you last paragraph. – 0xA3 Feb 19 '09 at 19:15
Agreed, asking about what someone has done in the past is one of the best ways to know if they know what they are talking about. Plus, the more details you ask about a project, the more likely someone that is lying will slip up. – rjzii Feb 19 '09 at 19:22
I would nearly always agree. The disagreement is when we decide we need someone for a whole new technical area that we don't yet know. Then the buzzwords become important - also alas we are less able to judge truth from embellishment. – MarkJ Sep 22 '09 at 16:07
Knowing a specific technology is not a big deal, hiring for a specific skillset is not a good practice ..But employers do it anyway. – Robert Harvey Aug 8 '10 at 17:18
@Robert - Of course they do. It is very common. – Tim Aug 8 '10 at 19:08

Here's my magic question to sort out exaggerated claims.

You have [insert technology] listed here in your skills... How comfortable are you with answering technical questions about that?

Honest candidates will tell you outright if they haven't worked on that technology for five years, or only have had basic exposure, or studied that in college twelve years ago and barely remember anything (and that's perfectly ok with me)

In those cases, I have no problem going easy on them or even skipping that part of the interview if that's not central to the skills they need for the job.

But if candidates tell me they're comfortable with the technology, they better be able to answer those questions.

Technical questions can only show that you know a precise point. I would start with "Where/How did you use [insert technology]?" to get a overview of the experience. And then ask technical questions. – h3xStream Jul 26 '10 at 3:57
The point of that question is mostly to give an easy way out to an otherwise honest candidate who overinflated his skills in some technology. I'll also ask about projects using that technology, examples of architectures, etc... – Kena Jul 26 '10 at 14:36

You guys are screening for the wrong thing.

You need to be looking for the Smart & Gets Things Done people, not the I know the minutiae of the C++ standard because I don't have to crank out code in my real job people.

I worked in a big company once (never again)... for a little over a year (felt like 10)... I know how insulated most of those guys are from actually seeing how code is translated into a paycheck.

Aside from the politics, it was all nice & neat to be able to sit and spend a week debating a design pattern, or probing what the standard said about xyz...

Try to take that game to a startup (non-VC funded), where you're one of the single digit hires, and see how well that goes over.

You: We haven't deployed that new feature because we're working through the merits of NoSQL vs. Sharding vs. blah blah blah

Owner: Oh... when I had you on that sales call with BigCo, I thought they were clear about how they needed this feature to move forward? P.S.: Don't cash your check this week. We sorta needed that sale to stay cash flow positive. P.P.S: Get out.

You come to the startup world, then you're going to need to be able to hit about a dozen different technologies, all in the same week, if not day to be able to get things up & running. Apache tuning? Check. HTML/CSS? Check. C++/Win32 Threading? Check. Now make it work on Linux/POSIX? Check. Replace a freaking motherboard? Check.

Here's the difference between programming and real engineering

When I was freelancing, I looked into becoming a MS Certified "Partner"... I remember getting a list of sample questions and thinking how ridiculous they were to actually being able to deliver product. Things like how do you add to a list container, and then 4 or 5 multiple choices with slightly different syntax.

That would be like asking a civil engineer if they could solve a slope of the road problem with some FORTRAN instead of their trusty HP. When you hire a civil engineer, a licensed one, you know that they can figure out the correct slope of the road - you don't give a crap if they used an abacus or had to look up the formula.

To tie that in with the above example, I have a degree in Computer Science... I KNOW when a problem calls for a list structure, and I KNOW how to implement it, not just call it. But, since I've had to use lists in half a dozen languages, I'm probably going to screw up the syntax if I have to whiteboard it instead of relying on intellisense.

Reading these responses makes me glad to be working on my own company instead of trying to jump through hoops like a trained freaking circus monkey to appease some random programmer's random ideas about how to hire.

I'd give you a plus eleventy-billion for this answer if I could! :-) – Brian Knoblauch Jan 24 '11 at 15:19
I want to work for your company... – UmNyobe Jul 4 '12 at 17:07

Regarding question 1, it's their fault if they feel uncomfortable from lying. Attempt at all costs to determine if they possess the skills they claim to have. Otherwise, you'll have a perpetual problem (as opposed to problem solver ;) ) at your company.

Regarding question 2, if they fabricate on a resume, how can you trust them not to lie about other parts of the job, such as if bugs were REALLY fixed in that new version ready to go to the miffed client.

When I don't know something being asked during an interview, I flat out state that I don't know. In my cover letters, I'll make it crystal clear that I do not fulfill Requirement #34 of the 184 technologies they are asking for :)

One thing I have discovered from doing a lot of reading resumes and then meeting people, lying on your resume is akin to speeding; somewhere north of 98% of applicants lie a little, and honest players are mugged by a failed system. Like speeding, you only bother weeding out the worst offenders. – Colin Pickard Mar 4 '09 at 16:20
If they're asking you to fulfill rule #34, you might want to send your "other" cover letter. – intuited Jun 15 '10 at 16:51

Assuming the lie is serious...(ex. I've got 12 years experience with c++)

Dismiss them. If somebody is purposefully lying on their resume, I'm not going to be too concerned for their comfort. Hiring a liar can cause you considerable financial loss.

If somebody has no problem lying in other areas, they have no problem lying at all. I certainly wouldn't want to hire anybody who feels lying to a potential employer is acceptable.

Assuming the lie is not so serious..(ex. I only write valid markup/css)

I would base the hiring on their portfolio. I really am a stickler for standards, but you might find a target="" in one of my xhtml 1.0 strict projects from time to time.

You probably lie all the time! – Joe Philllips Feb 19 '09 at 19:06

I have little tolerance for this sort of thing. If someone is playing fast and loose with the truth before hiring, there is no reason to think they will be scrupulously truthful after hiring.

That said, I tend to ignore the typical alphabet soup skills listing section of the resume. Everyone understand that the acronym cloud is intended for the resume screening software and not for people. I focus on those skills actually related to accomplishments, or related to the job.

Regarding question #1 (how much/hard to explore) ... don't be concerned about candidate comfort as interviews are uncomfortable by nature. And they should be prepared for questions about anything they choose to put on their resume. I would worry first about those things most relevant to the job, but if I "smell a rat" I would explore it as well.

Regarding question #2 (recommend qualified liar) ... qualified or not, if there are significant falsehoods I would pass. Technical acumen is not the only consideration. Remembering Joel Spolsky on hiring (here, at the bottom) ...

If you’re having trouble deciding, there’s a very simple solution. NO HIRE. Just don’t hire people that you aren’t sure about.


If it's at least 90%, as you mention, the best answer is, "Take it in stride." People have plenty of reasons, both good and bad, to embellish their resume beyond the strict truth.

When conducting interviews, I view the resume as a road map to the questions I'm going to ask. If the interviewee can't answer them, I don't really worry about whether it's lying, bad communication skills, nervousness, or a gap in real knowledge. I can't do that much second guessing.

For the sake of this question, let's address what a wrong answer means. Sometimes, an answer is so fundamentally wrong or uninformative, it's a clear indication that the interviewee doesn't know the subject matter But, even that doesn't mean they've never worked with the technology.

For example, I have ten years of working with SQL Server on my resume. The current application, which I've been building and supporting for almost five of those years, has a SQL Server database on the back end, but we use it very sparsely. I've probably spent less than forty hours on the current job writing stored procedures or Certainly, my skills have atrophied, but that doesn't mean my resume is a lie.

The only time I would worry about lying on a resume is if it's overtly pathological. I worked with one guy who claimed to be an ex-Green Beret. There was no hiring advantage to the claim and he would mention it at least once a week. Eventually, after he was fired for other things, it was demonstrably proven to not be the case. That sort of lying is potentially dangerous. Claiming two professional years of C++ when you've only used it in hobby projects isn't, provided you can demonstrate ability commiserate with your claim isn't.


A little fudging might be ok. Adding "Scala" if your scala skills are mediocre (assuming that scala is a fairly peripheral skill to the job you're applying for) is probably not quite so bad as would be claiming that if you know next to nothing about it. Much worse, I'd think, would be puffing skills that are central to the gig. Fabricating previous positions is also much worse and (I've heard) can be grounds for termination in some places if you're found out.

I personally really dislike working with co-workers that have bluffed their way in, and are getting paid what I'm getting. Thankfully this seems to have become much less prevalent since the end of the boom.

As for discomfort, I think anything you want to ask is fair game, and should be accepted as such, as long as it's not either illegal (personal questions and such) and as long as you're not rude about it. When I'm in an interview and I flub a question it's nobody's fault but my own.

  1. Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

    Yes -- just ask them to describe past projects. You don't have to get into really gory details, but you can at least ask them to describe the project that they used those skills or APIs on. They don't need to have the API memorized, but they should be able to give a well-reasoned response that shows they know the API and what it's good for.

    That said, a lot of applicants will list skills that they only have slight exposure to, which is perfectly fine, as long as they're forthcoming about their experience when you ask them. If they don't specify their level of experience on their resume, that's forgivable, but applicants should be honest when you ask them about it.

    What you want to watch out for is people who are blatantly trying to mislead you to get a job. If they say they're an expert C++ programmer but can't talk intelligently about a major project they've completed in the language, then you have a problem.

  2. Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

    No. If they blatantly lied about something on their resume, you have to wonder what else they'll lie about. Honesty should be a top priority. You're going to have this person around for a while, and you're probably going to pay them a lot of money. Make sure it's someone you would actually want to work with! It'll save you money and energy in the long run.

"talking intelligently about a major project"... Firstly most of the projects I have worked on are the property of the company for whom I wrote them and it's not my business to discuss them with a new employer. The best I can hope to do is pick a small subset of the big problem that is somewhat generic and discuss what issues were involved and how they were overcome and why we chose the methodology we did. It would be useful though if we were allowed to prepare better for interviews. In some they have given us coding exercises to do ahead of the interview. – CashCow Feb 17 '11 at 11:51
@CashCow - If there is one thing you should do before an interview, is to prepare yourself for these kinds of questions. Talking about a project is something you should be able to do quite easily with little prep work (because, I dunno... you worked on it?) and answer what your contribution was to the project without diving into sensitive details. If you can't talk about the projects you've done then there are really only two valid reasons why: either you're on an NDA or you have a case of bad self-reflection. Only one of them is a sign of bad character trait. – Spoike Nov 18 '11 at 13:08

1) Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

This might depend you mean by determining if they know all of the skills or not. One thing to remember when interviewing is that people get nervous and may screw something up, or forget it, even if they know it like the back of their hand. This is normal and unless they clearly demonstrate no knowledge for other related questions, you should give them the benefit of a doubt. Generally you are not going to be able to prove if someone has all of the skills they possess or not in the limited time of an interview. As such, focus on what you think are the deal breakers if they don't have those skills and come back to the other ones if you have time.

2) Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

I'm not sure I understand your question because if someone is genuinely qualified for the job, then odds are you are not going to think they fabricated portions of their skills et.

Also, something that you should keep in mind is that some people define "experience in" differently than others. This is why you need to ask people how much experience in something they have, where they would rate their knowledge of that skill, and when the last time they used it was. There are quite a few skills that you might use, get very knowledgeable in (e.g. C programming) and then not use for awhile. If the interviewee is confident that they would get back in the groove in a fairly short amount of time (or before their actual start day, remember that someone that gets offered a job might not start right away and may have sufficient time to prepare prior to their first day of work) then you should give them the benefit of a doubt if your overall interview impressions are positive.


Unfortunately, in many cases, people feel they need to embellish their resume in order to even be considered for a position they know they are qualified for. The reason is that many resume's have to make it through an HR person before they get to a hiring manager, and HR people filter on things which are often impractical. 10+ years of experience in a language that has only existed for 5, for instance.

I list a lot of things on my resume that I have only passing familiarity with, and in an interview I will tell the interviewer that I'm "familiar" with them, but not an expert. My expertise lies in such and such an area. Then I let them decide if that's what they want or not.

Of course I won't usually even go on an interview unless I think they're looking for my primary skillset. I don't want to waste anyones time by interviewing for a job I know i'm not qualified for.

  1. No. Only test them on the skills pertinent to the job.
  2. If it is small embellishment, recommend them. If it is outrageous, don't.

My reasoning

In Pragmatic Thinking and Learning( By Andy Hunt. One of the co-authors of The Pragmatic Programmer) Andy mentions a study where research determined that most people unknowingly exaggerate their skill set. They found that people really thought their skills were that good. If I remember right Andy point out more than one study that confirmed this.

Andy also points out to become a Guru in any particular skill, It takes most people 10 years. He referenced several famous people in several fields. This is why I like those 1-10 scales. I tend to put the number of years I have experience in a skill with some sort of weight one way or another. The problem is even though I like them, people that process applications think that I am not particularly knowledgeable.


I think it's important to be aware that it might not be their fault. Some of the recruitment agencies in my region are notorious for embellishing their clients' CVs that little bit.


1) Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

Shouldn't you worry if he has the skills you need?

2) Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

Depends how serious that lie is, of course.


In your phone interview, you could mention that next level interview will have lots of hands-on coding exercises. That should scare most of the people trying to bluff their way through.


You can't learn very much definitive about a candidate in a technical interview. (That's one of the reasons there are so many questions about interviewing.)

But you can learn whether or not someone's a liar. I'm trying to think of an upside to working with a liar and I really can't.


Regarding #1.

I don't actively do this but it's a side effect of my interview technique. Usually when looking at a resume I attempt to find some recent project that I have at least a minimum amount of knowledge about. I then spend some time researching it on the internet before the interview. I use this project as an ice breaker for the interview. I've found that people tend to relax if you are talking about a subject they are familiar with. Senior projects tend to be something people are both familiar with and proud of. Much better than throwing my actual question at them straight off the bat.

The side effect of this is I can usually quickly root out who lied and who didn't about their senior project. If you do 5-10 minutes of research you can usually root out the blatant liars.

The point of the pre-amble though is that I don't optimize my interview for the liars. I optimize it for the honest people who are looking to get a worthwhile job (and maybe stretched just a bit on their resume).

Regarding #2.

I classify this in two ways 1) people who are inflating their resume and 2) people who are bold face lying. People who fall into category #2 won't get an thumbs up for me. I don't care what their skill level is. You can't work with people you can't trust. #1 for some reason really doesn't bother me too much.


Joel Test #11 always works for me: "Do new candidates write code during their interview?"

+1 If they are lying, everything will fall apart at this point. This will allow you to focus on the interviewees decision making process and quality of their solutions. – John MacIntyre Aug 20 '09 at 19:30
They should ideally write it though prior to the interview, or be put into a room with a computer and a compiler to write it, not expected to write it on a whiteboard or sheet of paper. – CashCow Feb 17 '11 at 11:52

Most techies overstate their qualifications to some degree, but you need to distinguish between a positive spin and an outright lie.

If I were interviewing someone with Java programming experience, I wouldn't necessarily expect them to answer subtle questions about esoteric features or standards. But if after a few questions it became obvious that the sum total of their experience was playing in the language for twenty minutes, I'd find a polite way to end the interview and move on.

Personal note: I hate interviews were they give me stupid programming tests. Once I passed 'junior', I considered it insulting to have to prove myself on something trivial. Also, I come to interviews in 'conversation' mode, which is very different from 'deep thinking' mode. The context switch is disruptive (I either pass the test and fail the remainder of the interview or vice versa). Generally, I'll just pretend to fill out the code and leave as fast as I can. If the company doesn't already have someone who can tell if I'm any good, then I probably don't want to work there (unless I'm in charge).



I disagree, anything you put on your resume is game. If it doesn't pertain to the job, don't add it. It's not going to make you look any better because you did COBOL for a school project.

About lying. I heard somewhere that you will lie/embellish three times in a ten minute conversation. Not everyone who lies is a bad person. The person may be a quick study and can learn faster than you drive down the highway, I've worked with those people.

I would be more concerned about someone who lied about credentials than about having 6 years with LINQ experience. Ask yourself, how does this affect me or the company?


Generally speaking if I discover in the interview that the CV has blatant lies I don't hire the person - if I cannot trust a person to even write an honest CV how will be able in the future to trust him when he is working for me? E.g. if a person says he is a very experienced C++ developer but doesn't know what a pointer is then I have serious doubts about his other claims in the CV.

but if they told the truth they also wouldn't get the job so they haven't really lost out have they. – CashCow Feb 17 '11 at 11:54

I love to be devils-advocate ;)) Now I am NOT saying that you do this, but I have heard of (and been part of) interviews that should never have taken place. Some companies already know exactly who they want, yet they go through the process of interviewing anyway. Why? Beats me. I saw it first hand: "I'll be submitting the job req today, make sure you respond to me as soon as it goes out there". Or sometimes, contouring such a distinct combination of skills that it could only be targeted to a particular person already in mind.

Anyway, I am only saying that a real possibility for the increase in fibbing that you're witnessing is that nowadays companies seem to want an entire IT department rolled up into one person. They can only do minimal hiring, so they want someone who can do every conceivable aspect of any IT realted work. Good luck finding them. And FYI...Scott Meyers is on record as saying he is against the idea of having programmers write code during an interview. Period. Lots of people seemed to want his opinion when it came time to buy books. They could do alot worse than take his opinion on this subject as well.

So just take the fibbers in stride. Just the same as the fibbers take some pointless interviews in stride ;)

Actually getting interviewees to review some bad code is not a bad idea – CashCow Feb 17 '11 at 11:55

Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

Sure you should and sure you can.

Just ask him to explain the a LINQ / C# / SQL trick he discovered recently. If he comes with "wow, there are outer joins there!", then you and him just don't match. And you may just thank him and he will not feel embarassed.

Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

If you're not hiring them for the George Washington's Cherry Tree website, why not then?


My opinion:

Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have?

Yes you should:

  • You're interviewing them because you're interested in hiring them
  • You're interested in hiring them because of their resume
  • Therefore you ought to know whether their resume is truthful

Can I do this without making the candidate feel uncomfortable?

Ask pertinent questions. When I'm the candidate, I'm not uncomfortable: I expect it, I know what you're doing, and I know why you need to and ought to be doing it.

Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

I wouldn't. If you know they've lie about things you know about (e.g. their resume) how could you trust what they say about anything else?

There are only a few things I want to know from an interview:

  • Is the resume (and the candidate) telling the truth?
  • Do the candidate and I seem to understand what we're saying to each other?
  • Does the candidate want to work here?

It's not that complicated.


Google them and take their resume with a grain of salt. We don't bring people in until they pass a thorough phone and online test gauntlet.

With a thorough interview process, and if you do your homework on the candidates, you won't have to worry as much.

Sadly, nearly everyone misrepresents something on their resume. Some don't even mean to do it.

Online testing? I do a good amount of screening and hiring, and online testing, IMHO, is actually a net negative. It has nothing to do with problem solving, and the people who tend to do well on the tests are actually not the type of employees most businesses would want to hire. – pearcewg Feb 20 '09 at 20:31
We've actually screened out several bad candidates this way, and it prevents us from phone interviewing people who can't write any code at all. The online test is exceedingly easy with a 5 minute time window to complete the task. – Chris Ballance Feb 20 '09 at 20:38

1) Regarding interviewing etiquette, should I attempt to determine whether a person really possesses all of the skills they claim to have? Can I do this without making the candidate feel uncomfortable?

Are all of the skills necessary for the postion? If so, aren't you wasting your time finding out if they possess them all? And, if so, is it worth the time you are wasting?

In general, you are aiming to find out whether the candidate can do the job. If they are a pathological liar rather than an embelisher, I would cut the interview short and state "don't hire the pathalogical liar". To do otherwise is a waste of time.

But, spending time knocking someone down for skills you have no use for just makes you a royal ass. You can call them on it later when you are in the position to do it as a friend, if you care enough.

2) Regarding the final decision, should I recommend candidates who are genuinely qualified for the positions they're applying for, even if they've fabricated portions of their skillset?

Yes, but you should make a note of any serious fabrications. I say that with a grain of salt, however, as a qualified candidate whose resume is 90% garbage should bring up major flags.


JMO on these:

1) No, to do so would likely take weeks if not months for every single skill someone claims to possess. Could you write down every ability you possess and then test that within a week? I doubt it as this would be likely dozens of skills to test your proficiency without getting into the question of how to grade various levels of expertise like how yould you test someone that thinks they can cook gourmet meals or drive a tank easily? On the second question I'd say no, most people in interviews will feel uncomfortable at some point given that the environment is likely a foreign one.

2) Depends on the values of the employer, IMO. If the employer has questionable ethics and is OK with those that lie or cheat then I'd say recommend. OTOH, if the employer stresses honesty and would loathe hiring someone that lied, I wouldn't recommend the person in that case. Another factor is what skill set was communicated in error, is it crucial to the job? If someone said they spoke fluent Russian but the company doesn't do any business involving Russia or Russians then it may not be worth exposing the person if the company isn't rigid on honesty and integrity.

It doesn't take weeks to probe someones skill. For example, if a candidate claims to be a unix DBA, I want to see if they demonstrate minimal familiarity (I might ask them to write a command which greps a set of files and redirects the output to another file). That's one idea I've bounced around. – Juliet Feb 20 '09 at 17:59
I'll disagree there as the level of expertise is where it is time consuming, knowing someone is between levels a and b. For example, if someone claims to be a good DBA then there may be questions about what tasks are done as part of that job, what issues are generally handled over and over, etc. – JB King Feb 20 '09 at 20:00
What I'm getting at is that if someone claims to be a unix DBA, would you go through every unix command with them to see how well they know each one? How about each flavor of unix? Drilling down to mind-numbing precision is where this can be quite time consuming. – JB King Jun 17 '10 at 17:33

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