[elblanco]

Even more disconcerting, it can sometimes be very hard to tell the competent from the incompetent until you have them in the door working for you.

I once worked with a guy (not in an engineering discipline) who could talk circles around much more competent people. He knew all the buzz words, and even knew most of the topics about one level deep. When he spoke, he spoke with an absolute air of authority on whatever subject he was talking about. He managed to convince division manager after division manager (he jumped around a lot and it was a very large company) that past failures were just because of circumstances out of his control.

However, he didn't actually know anything and every project he was put in charge of either failed disastrously, or was caught from the brink at the last minute by colleagues who worked double shifts to do the project (which of course allowed him to point to those same colleagues as incompetents that he had to deal with on his project and hence the reason for failure).

The really sad thing is, I could never figure out if he knew he was grossly incompetent and just spinning things to keep a job far above the level he should have had, or actually believed the yarns he wove about what he knew.

[billybob]

I'm curious: is this not solved by a solid technical interview?

I would have guessed that if someone impresses HR, you could find out if they really know their stuff by getting a KNOWN competent person to ask them lots of hard technical questions, make them solve problems on the spot, etc.

A friend recently gave me a great example of how to do open-ended questions and probe someone's knowledge: ask a question like "when you type in a web address and hit enter, what happens?" The answer can range from "your computer loads the page" to delving into DNS, IP routing, HTTP headers, server load management, server-side processing, sessions, database access, cookies, browser rendering, etc etc. If the candidate gives a simple answer, you can continue to probe different areas to see how much they know in each one.

The trick is that the interviewer has to be competent enough to tell what the candidate knows and whether he/she will BS rather than admit not knowing something (which is also important to find out).

If you don't already have anyone competent enough to conduct the interview - maybe you're hiring your first programmer - you could temporarily hire someone who comes highly recommended to help you with the interview process.

So, was this guy vetted like this on technical merits, or did he just talk impressively to non-technical people? I'm curious to know how he slipped through.

[elblanco]

It wasn't exactly a technical field. It's amazing how many fields outside of development are very nearly impossible to test in a meaningful way. For example, hiring a sales vp, if done at the same level of problem solving as most tech interviews I've seen, would have to result in a 30% sales increase for the company. You basically have to just see what they say, if they sound like they can tie their own shoes, don't suffer from short term memory loss and have a pulse you usually give them a try and just fire them if they don't work out.

That's why there are so many hangups during the interview process that have nothing to do with a person's actual skill in a given area..like font choice on a resume, or little tips like how to sit in a chair or whatever. Those are all little tells that people look for in an interview, but candidates also know this, so they try to game the system by appearing confident, showing up precisely 15 minutes early with a binder full of extra copies of their resume, just the right amount of hair gel, etc. Because by and large, in fields outside of technical ones, that's how you get a job.

> So, was this guy vetted like this on technical merits, or did he just talk impressively to non-technical people? I'm curious to know how he slipped through.

But yeah, this is actually how he kept slipping through. His interviewers were hiring him for expertise in his field that they themselves did not have. Pretty much it was bureaucrats and administrators hiring somebody for a particular skill requirement. They simply didn't know how to dig more than a level or two deep. In the same way that a person can game the hiring system like I mentioned above, he could do the same for his field. Somebody who was actually in the field would have to spend a little time to figure out that he didn't know the equivalent that computers need electricity to operate. But he could talk for hours about how for example, a browser operates with DNS servers to resolve IP addresses -- and do it with authority (again, as a very rough equivalent).

You could even ask him to produce a plan of action for the next six months and he could produce a pretty good outline, good enough for an interview, but ask him to fill in the details and he couldn't.

[rikthevik]

> His interviewers were hiring him for expertise in his field that they themselves did not have. Pretty much it was bureaucrats and administrators hiring somebody for a particular skill requirement.

This is what keeps me coming back to small companies and startups. Any company with an HR department big enough that they hire using a series of bullet points pretty much guarantees I will have brain-dead coworkers.

[elblanco]

Funny you say that, I actually left that place largely for this reason directly for a very small startup.

[j_baker]

Two things:

1. He noted that this wasn't in an engineering field (which I would presume to include programming :) ).

2. A technical interview is hardly a panacea against bad hiring decisions. It's just the least crappy way to hire people that anyone's found (that I know of).

[DuncanIdaho]

You perfectly describe an Successful Technocrat.

Go read Archibald Putt and you will be enlightened.

[dpritchett]

Thanks for the tip! While the 184 page Putt book is $15 on the Kindle I've just found a 30 page PDF that gives the gist:

http://www.rako.com/Other_Voices/Putts_Law/Putts_Law_no_ads....