when relevant content is
added and updated.
- A hiring manager told me that occasionally he gets people who look great on paper, interview well, yet cannot do the work at all. He wanted a waiver on his contract, that if the person is let go within two weeks, they would pay nothing.
- A candidate we interviewed gave fantastic answers … until we asked for specifics about how to do the work.
- Another hiring manager told me that once the candidate gets to the interview, she throws away the resume, because they are so full of deception, she might as well start over.
I think I understand what is going on here, and I have a few ideas to help.
How The System Works
Hiring Managers want winners — people who can “hit the ground running.” They explain this to HR, along with a job description. HR turns the job description into keywords and require them.
In too many companies, you don’t get the interview unless you match all the keywords. If you manage to get in the door because C# is kind of like java, you’ll still be at the bottom of the stack. No one has all the buzzwords, so people lie.
Somewhere between the staffing company, the candidate, and the hiring company, someone injects the keywords into the resume.
I used to say “aha! Those companies get what they deserve”, but now I find myself in the position of trying to win contract bids with some of these companies — honest people, working in a system that incentivizes lying.
And some of these liars are really good.
How They Get In The Door
One company I worked with had a contractor who could not seem to tell the difference between compiling the code (it was PL/SQL, a programming language for databases) and running it in the database. He would also disappear for half an hour or an hour at a time. Eventually I followed him, and realized that he was going to another contractor to write his code for him. He would get the code by email, press F5 (Compile), then write a select statement, find his data was not updated, and then ask me for help.
Eventually I asked if he had written PL/SQL before, and he said yes. I told him it was okay, I wanted to know the truth; he insisted he had done the work before. So I asked “When you wrote PL/SQL before, what did it do?” After a long pause, he said “…looping?”
I walked over to the team lead, and expressed my concern. Dave said “Honestly Matt, I came to the same conclusion; I asked you to work with him to get a second opinion.”
But how did this happen Dave?
Answer: “I think the person we interviewed on the phone did not speak with a lisp. This contractor does.”
Now look at the resume. Is it “too perfect”? Does it list every last one of those things that are not right, probably multiple times? Does it list new tools under older experience, or old tools with out of date names under current experience? Does it confuse things with similar names, like say, a protocol (SOAP) with a tool (SOAPui?)
Now during the interview, you can do a few things:
(1) Latch on to those things on the job description that aren’t right – the one-line about Novell Netware. Ask about a time they used the technology. You may get a simple answer back – as a sysadmin at the local college, they had to reset passwords. In programming, it might be examples of user or product information searches. These answers will sound kind of textbook. Push back – they worked on this tool for a year; what were some other things they did with it? In our Unit Test Example, ask for an actual example of a unit test, not textbook, but something they did.
(2) Get confused over the difference between two similar things with different names. For example, HP recently rebranded their Quick Test Professional product as UFT, or Unified Functional Tester. Ask about the difference.
(3) By now you’ll get a feel for the one or two tools they might really know, and the few that might be faking. If you can, set up a scenario where one tool is clearly the right tool for the job — and it is not their favorite. Then ask which tool they would use, and why. When they say they would use ASP.NET for a simple desktop application to store that user’s notes, push back. Ask why. Ask “why not C#?”
(4) If it’s a phone interview and you feel awkward pauses, turn up the volume and listen for whispering, or typing sounds. They might be googling.
Of course, none of this works if the person is willing to literally have someone else interview. If you suspect that then you are working with the wrong vendor.
Peter Theil, the author of Zero To One, said in his book that ethics is a sort of luxury. To be fair, if someone has to steal a cell phone from a tourist in order to feed his family, I would hope I would understand. It’s worth noting that most of these people are just humans working in a bad system — they just want the job. They may know the job description is only loosely correlated to the job, or, more likely, hope to gain the skills on the job. Only a small number of these people are genuine duck and groove psychopaths who plan to take credit for the work of others while not doing their own. So we want to be sensitive.
My company has been successful enough that, at least for right now, we seem to be able to afford the luxury of integrity. (I’ve also found that integrity yields dividends.) I think you can too. I think you should demand it. Let’s change the system to reward the right behaviors – starting with rewarding the honest job candidates.
Here’s one more idea: Inject fake keywords on the job description. Tools that don’t exist. Perl on Pails, B++, the Comache or EngineY Web Server and so on. See who not only claims those keywords, but claims every single one — then throw them in the dustbin.
Or call me. I’d be happy to look at resumes and detect BS as a service while teaching you to do it, for a modest fee. I’m completely serious – but I don’t think we need that.
One last thought.
When you hear “Everybody does it”, please remember that no, everyone does not do it. We don’t at my company, Excelon Development … and we ain’t starving.
But keep in touch. We’ll tell you how it goes.