Comment by adrianhoward | Hacker News Reader

Comment by adrianhoward | Hacker News Reader

The first step in opening up a position for hiring is to define the position you are looking for. Most companies call this a job specification (or spec).

I'm still shocked at the number of employers who don't create one before they start looking for somebody. Especially those who don't think about how the new hire will fit into the existing organisation.

For example, I've seen this pattern multiple times.

a) Lead Developer (let's call 'em Mary) gets massively overloaded. No time to do the numerous things she's asked to do.

2) "We need another Mary" is as far as the job spec goes.

3) They find "Bob" who is, indeed, mostly another Mary. Bob gets pulled off onto NewFunProject, since Mary is waist deep in keeping CoreCompanyProduct running. Pattern repeats.

4) Mary rapidly gets rather annoyed that Bob gets to play with all the fun new projects, and promptly finds herself a nice new job. Walking away with a head's worth of CoreCompanyProduct that never got to Bob.

5) Bob gets massively overloaded. Goto 2.

Hiring is not what you should do to fix a short term problem.

Defining the position is an interesting challenge. I've certainly been frustrated as a candidate in the past. I've been through eight hour technical interviews, going from dev to manager to dev for an hour each, solving math puzzles, traversing trees, coding up design patterns, optimizing sql, and realizing, at the end of the day, that after eight hours I actually have no idea what the company does beyond the questions I asked and the material I read on their website. Part of the problem was that the interviewers weren't coordinating well, so everyone was pretty much just hammering me with tech questions. Hell, at lunch someone thought it would be clever to ask me how to swap two integers without creating a third integer.

Here's the thing - I actually do understand why companies do this. Many well funded, established companies are just in a state of constant recruitment. If you can solve math problems, write efficient data structures, optimize sql, withstand the pressure of coding on the spot, and seem like a pleasant enough person to be around, they'll have something for you to do. Hire. Step 1 to tech recruitment is to constantly scan who is on the market, identify those who have good credentials and can withstand brutal technical screenings, and make sure you hire them before facebook and google do. You have a few weeks to do this. Step 2 is to define the position you are looking for, and if you wait too long, you won't have time to do step 1. It actually does make some sense.

I would recommend a happy medium, because I really didn't want to work for that company after a day of wind sprints, never knowing where I was going or why I was going there. I think that what they want, and get, is whip-smart people who live for technical problems, with perhaps less emphasis on the business context.

The fundamental problem in your example has nothing to do with hiring. It's that Mary is working on something that she dislikes to the point that having to continue on her project in the medium term will cause her to quit. It's both the company and the employee's joint responsibility to ensure that this isn't the case.

I'd argue that it has everything to do with poor hiring practices :-) I should have made it clearer that at (a) you have a happy, but overloaded employee.

By hiring somebody else, and by not thinking it through what that person should do in the context of the current workforce, a happy employee becomes an unhappy one.

Before they hired Bob - before they even start looking for a Bob - they should have had a good idea what "Bob" would be doing, how that's going to fit in with what Mary's doing now, and that everybody is happy with that.

Nobody went in with the idea that "Mary will get the dull stuff and Bob will get the neat stuff" since that's obviously a dumb decision. But because nobody had articulated what exactly Bob should be doing, and how that may or may interact with Mary's role, bad things happened.

If they'd thought about it, written a job spec, and talked to Mary some of these issues would have come up. They would have probably figured out that "We need another Mary" wasn't what they actually needed. When a company is growing "another Mary" is almost always the wrong thing to ask for - since as the company grows roles change.

By looking to define the role they would have found out that Mary does Q, W, X, Y, & Z. She's not very hot at Q since it's not a core skill, but she's really passionate about X, Y and Z, and W needs to get done and she's happy to do it. So maybe what the company needs is for Mary to focus on X, Y & Z, and get somebody else who's good at Q and W... or two different people who are good at Q and W.... or some other option.

Hiring is exactly what makes this happen - and I've seen it more than once.

Reply on news.ycombinator.com