Gotta' Catch 'Em All

Hiring brilliant people is hard and expensive, it's a task that can take several months of preparation and diligent follow through to successfully execute. So, why do so many employers seem to be burning through these individuals that they've so harrowingly fought for?

After posting on facebook that I was looking to fill several programmer positions, and noting friends at EA, Zynga, THQ, and other companies were doing the same, I decided to write a short (read: overly long winded) post on the topic.

Let's look at the hiring process, first, just so we can understand how costly and difficult it is. I'm going to use my experience in NYC as the primary guide, as this is an area with several developers, great technical schools, and a dearth of programmers.

Now, for this post, I am going to focus on game programmers; but, I'm sure the stories and factors are similar for other disciplines.

Preparation for the hiring process -- the hidden cost

Most companies do not just delve into the hiring process. Rather, they carefully build tests, solicit questions, and possibly develop entire engines for questioning their candidates. This is pretty typical. Time is spent in writing a posting and position description, in thinking about what questions need to be asked, and in preparation of any materials needed.

It's not uncommon for a studio to have a written exam. Someone has to make this exam. Indeed, I've worked for places that have had off-site and on-site exams. These are materials that have to be prepared and updated.

Additionally, many potential employers require actual, production quality code to be written. Someone has to figure out what the project should be, the scope, etc.

All of these tasks take active programmers away from their work. These just can't happen without developers participating.

The cost of posting

HR is usually pretty good about handling posting (something that costs money), farming out to agencies (more money), etc. Yet, an engineer has to be on hand to review the candidates' resumes and schedule phone interviews.

Typically, there has to be a back-and-forth as candidates flow in, where an engineer is constantly refining the posting. This is all time consuming. All candidates have to be treated cordially, as well, so their experience with the company, even if rejected, isn't soured.

Phone interviews

This is the department's first line of defense. It's easier to reject a candidate in a one hour interview, and less costly, than to allow that individual an on-site interview.

In my experience, a candidate can be interviewed anywhere from 1 to 4 times by actual engineers over the phone. These are typically one hour phone conversations. That's one hour of productivity lost per employee participating in the interview per candidate.

On many phone interviews, candidates are asked actual coding or technical questions. Again, this goes back to preparation time. Personally, I like to use Google Docs to have candidates write code on the spot. I have a set of staple questions I branch through depending on what I'm hiring for and how the participant responds.

On site

Ideally, you want to prevent as many candidates as is humanly possible from getting to the on-site. At this point, anyone remaining has probably taken a programming exam or completed some code samples or projects specified by their interviews.

Again, we have an extensive expenditure of time to 1) prepare interview materials 2) review any existing materials (resume, previous answers, etc.) and 3) actually interview.

At some companies, only a handful of team members are introduced to the candidate. However, I have worked at studios where upwards of 13 engineers participated for an average of an hour each (usually in groups).

That's more time invested.

Finally, there's the recap. Everyone gets together, slings around their feelings, and a decision is made. Sometimes this is immediate. If the candidate stumbled on easy concepts, got hung up, or simply shut down, it's usually rather apparent that they're not qualified.

Hiring the person

If you have managed to separate the chaff from the wheat, there's the entire issue of getting the individual hired. This can involve talking to HR, IT, planning relocation, negotiating salaries, juggling benefits, etc.

Great the person has started working…

Well, you better not expect them to be up to speed immediately. There’s code to learn, standards to follow, practices to experience. Additionally, everyone operates differently! Your brand spanking new programmer won’t become valuable for at least a few weeks. In that time, your lead programmer and various other team members will begin investing their time in training that individual and bringing them up to speed.

It’s a process. It takes time.

Finally up to speed

That’s great, they can finally contribute!

Wow, the person has been here a year!

Now your previous candidate has become a key, valuable member of your team. He or she is writing code, developing new systems, and training others. Wow! That’s awesome!

What would happen if they left? Eeek! I don’t even want to think about how much esoteric knowledge they’d leave with. Not to mention the stress that would be put on the remaining team members.

Well, this begs the question, now that the individual has been found and trained and they’re integrated and productive: what the hell are you doing to keep them there?

As a programmer, I expect:

Salary

First, a good programmer is probably an experienced person with a good level of education. They expect to be able to afford a nice apartment/house proximal to where they work, support their family, and have enough left over to relax. That’s the minimum. If you’re paying local programmers just enough to get by, expect them to jump ship.

Programmers getting paid enough cost more, this is true; but, hey, they’ll work happily along.

Programmers not getting paid enough become grumpy, work less, and generally lose productivity until they leave and find somewhere else to haunt with their genius.

Benefits

You don’t want your programmers worrying about paying for anti-biotics for their sinus infection. Hell, you don’t want them in the office when they have a sinus infection—we can write rather terrible code when sick (but, we’ll tell you otherwise, certainly).

So, take care of us. We take care of your code, after all. Without us, you really do have nothing.

A sick programmer writes bad code.

A healthy programmer writes great code and appreciates that he or she is healthy.

Environment with learning

You want someone who strives to continually learn. We’re working on the cutting edge, after all. So, provide opportunities to work with the latest, learn it, master it, and wrangle it for the company’s benefit. Pink talks a lot about motivators (http://www.ted.com/talks/dan_pink_on_motivation.html) and you’ll note that they’re not all monetary.

A bored programmer without anything new to learn will start looking for a new place to learn—possibly at Monster.com.

Flexible hours

Programmers aren’t robots. I know, sometimes we speak like robots, or pirates, or in a weird language all to our own; but, seriously, we’re very fallible humans. Sometimes, we even have the energy level of a panda, especially after a long day of crunching. Let us be late, as long as we’re not disrupting the team’s productivity. Let us leave early when we have to.

What are you losing if there’s nothing mission critical at stake?

Keeping a programmer against his or her will certainly demoralizes said programmer.

Letting the programmer go home early to surprise his or her honey means they’ll be happier the next day, makes them appreciate working at such a flexible location, and means they’ll be rested for tomorrow’s day of development.

Reasonable hours

Why burn out a programmer over a small button widget that can be delayed from going live? Why burn out a programmer early in the project’s development? Why burn out a programmer?

What’s the worst that happens if your product doesn’t ship? You may lose some money. You may have to quiet some fans or clients.

What’s the worst that happens if you crunch a programmer? They leave. You’re now back at square one. Go ahead. Try and find another Mr. or Mrs. Genius.

Sick days

Stop cutting these short!

One sick programmer turns to two sick programmers turns to ten.

Sick programmers, as I’ve said, write nasty, ugly code and wonder why they’re working with the flu.

Healthy programmers don’t even think about these things!

More, lots more

Company ZipCar accounts, stock options, the freedom to make our own hours, the ability to take my laptop to the nearby Starbucks and have a double whip toasted insanity with extra foam… these all help you retain employees.

After all, which would you rather have? Productive programmers? Or transient coders?

It's all there for you to control, within your power. Spend more, get the best, keep them happy. Or don't and see what happens.

Either way, good luck!

About the Author

Andrew Andreas Grapsas is a game programmer at Arkadium, Inc. developing facebook games. Previously, he was a gameplay and animations programmer at Kaos Studios|THQ, and intern systems programmer on Medal of Honor.

Andrew is actively writing and programming for various projects. You can read more at his blog aagrapsas.com. He promisses to update it soon.

Follow Andrew on twitter!