How To Hire Good (People)

Tuesday, Aug 12 at 10:32 a.m.

An Introduction

Recently a friend was discussing a new prospect. The gentleman had a great resume, great interviewing skills and a decent portfolio. His previous experience was a great fit for the position my friend was hiring for. After lobbying for an exception to the normal hiring rules, my pal got the guy a higher salary than any of his other developers. After much hemming-and-hawing, this exemplary fellow was brought onto the the team. Within the week he quit his job. After a brief review of the little work he had done, it became apparent that his code was bad. My friend had been burned by a Faker.

What's a Faker?

In general, a Faker is a person who seems really really really impressive until you apply fingernail to surface and discover that there is no there there. Fakers usually have great resumes, decent people skills, and an uncanny ability to cover up their own mistakes. Fakerism does not discriminate between technical resources and managers.

I've actually had a legit "select is not broken" conversation with a Faker. This wasn't just in the class of conversations that are like "select is not broken". I had to prove that select() was indeed not broken.

I've taught a Faker (with "5 years of experience") how to write a for-loop in PHP. After he was in the PHP development gig for 9 months!

I've had library code changed by fakers, because they found a "bug". Fixing that 'bug' broke the 20 other clients who were using my library code.

All of these people are not a composite. These examples all come from different people who I've dealt with in my rather short career.

Fakers are not fun.

Here's a quick taxonomy of the Faker:

The Best-Practice Drone

Does your candidate have a hard-on for Design Patterns no matter what? Does your candidate lack any kind of healthy skepticism for what he was taught in college? If you've answered yes to either of these questions, you've just hired a Best-Practice Drone!

Congratulations! You will have the pleasure of dragging yourself through the thick brambles of files and files and files of classes that were written (one per file, natch!) because he was taught in school "always to write getters and setters, and to put all classes in their own files". If you ask "why?" this person will likely tell you that it makes reading the code easier. If you ask "why?" a second time, this person will stare blankly until you look away.

In the very worst cases, the Best-Practice Drone will have a fetish for alphabetization of methods. He was taught to alphabetize methods in a seminar once.

His lack of imagination and reliance on process-over-people should belie the fact that he doesn't know what it takes to get something from "planned" to "complete" without throwing something over the wall to another, likely more competent, team.

When things go wrong, the Best-Practice Drone will bleat that there was "no process" to deal with this situation. He will certainly not have any concrete plans for a process. He may be possessed of a vague notion that "things should be better."

Bottom Line

Avoid the Best-Practice Drone at all costs, unless you've got some posts on Craigslist for "Apparatchik" or "Kafka Antagonist." It is acceptable to hire the Drone for state or federal agencies. He has turned up on "employee of the month" posters at Kodak and BAE systems.

The Javaholic

The Javaholic is much like the Best-Practice Drone, but he only knows Java. He won't use JNI. He won't learn another language. He knows Java. He uses Eclipse. That's it. The Javaholic is trying to escape from his Fortune 500 job, and he hopes that his deep knowledge of a hot new language like Java will be his ticket to dot-com riches.

The Javaholic believes that if a client is written in Java, the Server for that client should be written in Java. He will talk about BufferedInputOutputStringReaders until your eyes glaze over. These are the hot new classes needed to build applications on the "Internet".

If you have code that's not written in Java, he will tell you to rewrite it in Java. He will, however, not take up the task of re-writing it in Java, unless he's a really inexperienced Javaholic. The inexperienced Javaholic will try to rewrite your code in Java, and discover that it's really hard to rewrite it without the whole team pitching in.

The experienced Javaholic will tell your team to rewrite the code in Java, because it totally won't have enough 'enterprise' in it without the big J. He will also be happy to manage the project or advise on it, but will not actually re-implement any of your features in Java. Getting one's hands dirty is not the Java way.

Over time, he may build an application of sorts. It will take longer than he thought. He will not understand that it will take the offshore tech-equivalent of a team of 20 pack-mules to get your application up and running. You should have your checkbook ready.

Bottom Line

Stay away from the Javaholic unless you already have a big unwieldy Java application. Beware if he says the word refactor; you may have just been tricked into a rewrite. It's also cool to hire him if you want a big, unwieldy Java application.

The "Dumb/Smart Guy"

Did you hire someone who's like wicked smart? He knows a little bit about everything. Have you noticed that his code seems super-inefficient? Have you noticed that he seems to do things in a really really weird way? Have you noticed that he seems to write a lot of "while" loops when maybe he should use a "for" loop? Does he even know how a "for" loop works? He's been on the job for how long?

Uh-oh. You just hired the Dumb/Smart Guy.

He talks a big game, but when the shit hits the fan, a "for" loop is something that someone else writes "for" him.

Bottom Line

Don't hire. Unless you're looking for a Director-level position or higher.

Prevention is the Best Cure

Ok, so unless you're, like, really into pain, you don't want to hire these people. Here's what you can do to detect and weed out the Fakers.

1. Require that the candidate write code in the interview. Not on paper, that's stupid. Give them a laptop, an environment, and a task. Watch them. See if they do something sane. If they complain that it's not 'doable' then you've got a Dumb/Smart guy or a Process Drone. If they ask where "NetBeans" is installed, you've got a Javaholic. Set a time limit. If they give up, don't hire. If they don't succeed, think about what happened, and make a good call.

2. If you're dealing with a potential one-language pony, ask about other things that they've learned or other projects that they've worked on outside of their professional sphere. If there's nothing, don't hire.

3. Require a portfolio. Review the work that they are 'proud' of. If there is no portfolio, or if it sucks, don't hire. This applies to coders, managers, document-folks and everyone else. If they cannot show you something that they've produced, assume that they cannot produce.

4. Don't bother with language quizzes. Anyone can memorize a bunch of shit for a day or two. Memorization does not imply that one can code one's way out of a paper bag.

Wow, Kevin, You're an Asshole

It's true. I am sure that this process weeds out a lot of good people. But there's a funny thing about process: when your gut tells you that this person without a portfolio will make a great addition to the team, hire her for God's sake! But when the warning signs go up, don't ignore them.

0 comments