Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 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 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 Monster.com –  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

Are you "Still Hiring" from Bob Lewis' blog entry?

It seems to me that virtually every "expert" I have talked to or read recommends that one embellishes one's resume if it will help get the interview.

Not original to me here, but yes, it's okay to ask about the interviewee's skill set, especially as it pertains to the job for which they are interviewing. If they really have the skills, they shouldn't get any more uncomfortable than they already are. If you ask the question correctly (i.e. don't just ask "Do you know about technology XYZ?", to which the answer could be "Yes" even if they only read a single blog entry about it yesterday) it should be possible to tell if they have embellished a bit; at this point you want them to be honest and say they only have a little knowledge in the area.

As for hiring, if it's a minor embellishment, I don't see a problem, since that's what's advised these days (and would they have gotten through the door if they hadn't done that?). If it's something major, turn them down.


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

There is no law that states a person must tell the truth in a resume. Don't be petty.

I rarely read a resume because they are only a calling card. I glance at the first page in order to make sure the candidate has the required skills so we are not wasting each others time. During the interview, I ask specific technical questions. If they cannot answer to my satisfaction then I do not hired them or recommend them. Everyone lies. I really do not care if they lie or not, I just want them to do their job if hired.

To be honest, I lie more during the interview then I do on my resume. (I do not lie on the resume, because there is not enough room to fit on two pages.) Yet, I have never had a client or employer that was dissatisfied with my performance or skills in the two decades I have been in the industry.


I lied before but only once because don’t know on how to impress my employer and call me up for an interview. On the next day when they called for an interview I said the truth, everything was embarrassing. Well advice me if you’re getting difficult with your resume and don’t know what will be the content is use a resume template.

But guess what after a week they called and I’m hired because of my honesty.


There are too many reasons to lie on a resume/CV to call people out on every single bullet point in their skill set.

  1. Sometimes you have to put on stuff you don't know very well to get past HR. How many job descriptions have you read that say things like "knowledge of MySQL, SQL Server, Oracle, Sybase, Postgre SQL, C++, Java, Com, Win32, ASP, ASP.Net, VB" etc blah blah. Like they just went to a site that listed out programming acronyms and technologies. HR doesn't know anything about what we do, all they can do is do a comparison. "I see SQL Server and Oracle, but I dont' see Sybase or MySQL. Hmmm...well, then they must not be able to comprehend our really difficult 25 table database that we have."

  2. A recruiter/head hunter might have encouraged emphasis on certain technologies, or at worst, actually ALTERED the resume before you see it. I've had the latter happen to me. Got to an interview and the interviewer said, "wow, so you have 12 years in .Net? Interesting since it has only been around for 6 years." I had to spend a lot of time really explaining my experience that looked contradictory to "my" resume. I was not offered that position.

So, really, use the resume as a jumping off point. Find out what they mean by experience, and see if it jibes with what you understand that word to mean. I mean, I've had "experience" doing PHP. A 3 month stint at a side job that was nothing more than a CRUD web app. So, yeah, I've had "experience" in it. It's on my resume. Am I qualified to jump onto a PHP project and be a tech lead? Hell no.

Other people have said it best -- look at the job and app experience and ask them about that stuff. Dig deep. Don't spend a bit of time on the bullet points. You really never know who put those things down.


Not everyone might asess their own skill set as accurate as you. That's especially true if they are less experienced. Because of that, not reflecting the resume accurately may not be sign of lying but a different understanding of one's own capabilities.


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.


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


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 is very dangerous ground. If you are an EOE (equal opportunity employer), questions not related to the actual job can get you into some hot water. I'd recommend putting together a solid list of the known skills that you believe the position requires now. It wouldn't hurt to add a few of the nice to haves for future projects.

Also just to play a little devil's advocate... Just because they put something like LINQ or JBoss on their resume does not imply in itself that they are not being honest. They may know a little bit about it, but are not experts. This is why you'll see people score the needed competencies for a job on a 1 - 10 basis to make sure they have the required skill base for that technology for the job.


What I would do is give them a complicated piece of code and ask them to tell you exactly what's going on, or some similar test. Watch them closely - often they'll be able to guess, but you will be able to tell from their facial expression what they're thinking.

If they look like a deer caught in the headlights, then chances are they did lie.


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.


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.


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.


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?


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.


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.


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



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.


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
  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.


Joel Test #11 always works for me: "Do new candidates write code during their interview?" http://www.joelonsoftware.com/articles/fog0000000043.html

  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.


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.


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.


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 ADO.net. 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.


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.


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.


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.


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.

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

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