Tuesday, August 14, 2012

Resumes: The 80% Rule

I've sat on both sides of the interview table. I've been a lead looking for competent hires for a complex software project. My experience hiring staff can't be that different to the mainstream.

I'm amazed at the resumes I receive. I'm amazed at the quantity; about 100 resumes back in the day when we wrote newspaper ads. Somewhat fewer for an ad on hotjobs or monster. When I'm hiring, I don't have HR filter the candidates, because if they do, I don't get any resumes. I love the folks in HR, but they just don't know enough about software. So, 100 resumes in a pile, or 100 resumes in my in-box.

About 80 per cent of the resumes I receive are unqualified on their face for the clearly described position for which I'm hiring; retreaded poets and astronomers; guys with no experience at all in the languages or technologies I specified; people with no degree and no experience and no apparent ability to write grammatical english sentences. People whose home address is on a different continent (plus they have no experience). I guess these guys send a resume to absolutely every job posting, web site, and advertisement. They might as well not bother. These resumes go in the recycling on the first pass. (HR keeps a copy for awhile, because there is a requirement that they do so).

That leaves about 20 resumes that are worth a second look, which is to say a careful, front-to-back reading. Of these resumes, about 80 per cent are unqualified in some specific way. You can understand why they applied, but they are not the droids you are looking for. Not enough experience, not the right experience, or there's just something funny about them.

That leaves five resumes that are people you want to call up and talk to and maybe have in for an in-house interview. Of these five, there are maybe one or two (20% again) that you might make an offer to.

And there is another one who is lying to you. You bring them in for an in-house interview and their experience melts away. They clearly don't know what they're talking about. They just aren't what they say they are. Posers; fakes; cheats. And not very good ones, because you bust them in a couple of hours of interviews.

In the modern age, the barriers to submitting a resume are far lower, but there are more jobs. What that means to a hiring manager is more resumes that do not make the first cut, and fewer qualified candidates from whom to choose. You might not even get one candidate you want to hire, so your job stays open longer...and longer...and longer, while your team misses milestones because they are too few.

So, if it seems like your beautiful resume disappears into a black hole every time you submit it, remember that it's a needle in a pretty big haystack. If you get called, you made the first two cuts, the 20 per cent of the 20 per cent. That's pretty good.

Thursday, August 9, 2012

Coder's Block

I used to get coder's block, which is like writer's block, only for software. I'd stare at an empty screen, having no idea where to start. I'd dither between two implementation directions, unwilling to commit to either course, while the cursor blinked away the seconds in the corner of that empty screen.

I cured my coder's block, by the same technique recommended to cure writer's block; write something.

OK, initially this is hard advice to follow. By definition, if I didn't know what to write, what could I write? If I didn't know which implementation path was best, wouldn't I potentially be wasting my effort writing the wrong thing?

The solution that worked for me was to write something different. If I didn't know what code to write, I would write down a list of requirements (in prose) for the code. If I was looking at a big undefined area and I didn't know just what I'd need, I would write a structured walkthrough, again in prose. Or, I would write the function header, so that what I was doing had a name and an argument list and a return value. If I was feeling particularly virtuous, I would write a module test attempting to use the unwritten method to solve the problem.

And this is what happened. As soon as there was something on the screen, I could begin to review it. I might realize that I didn't know what the requirements were. That gave me something to think about, and pretty soon I did know. If I did a walkthrough, I would find myself writing in the passive voice, which would mean that I didn't know what object called which method. Now I had a hook on which to hang further thought. If I wrote the function name, I could begin to think about whether I really needed to do a thing with that name. Every word I wrote got thoughts out of the nebulous fog inside my skull and down in (temporarily) solid and immutable text where I could see it and analyze it and refine it.

If I couldn't write a paragraph, I'd write a bullet list. If I couldn't write a bullet list, I'd write a few conceptual phrases. What I would not do is get a cup of coffee or read my email or surf the web. That way lay madness. OK, maybe just a little surfing, but I would hold it in mind that I was procrastinating, and what I needed to do was to grind it out.

I know some people who deliberately distract themselves with some email or web surfing. Maybe that works for them, or maybe they are self-deluded. But for me doing something else is just postponing the hard stuff. I know some people who say the answer comes to them in a dream. In my dreams I just worry about being blocked, although sometimes in the morning I have amazing insights in the shower, when I'm very fresh.

When I grind it out, I almost never find I've gone down the wrong road. Perhaps that's part of being an Old Hand. Come to think of it, I conquored my coder's block about the same time I became an Old Hand.

2,000 Mondays

This post is a warning to undergrad CS majors. The stories you hear about the "real world" are not the truth.

There's this place called Xerox PARC. At the dawn of the Computer Age they invented personal computers, and Ethernet, and Smalltalk, and windows and stuff. And the conference rooms were full of beanbag chairs and the streets were paved with gold. This is what your professors think the real world looks like.
Xerox PARC, ca. 1980: A fantasy of the real world
There's this cool startup you'll hear about (a different one each year), where they give you a MacBook to develop on, and there is free pop and snacks in the fridge, and wine on Fridays, and the office is decorated in twenty-something chic, with a universal gym and foosball tables, and you can work any hours you want, and dress like a slob.

This is the "real world" you hear about in college. It's a world where nerds rule and employers are so desparate for top talent that they'll do anything to keep you happy.

It's a fantasy; a fairy tale told by people (students) who have never even seen the real world, and people (professors) who turned their backs on the real world in favor of a place where you could never ever ever be fired no matter how you behaved, once you got tenure.

Mostly, the real world looks like this.
Sorry, this is a lot more real
The real world is a very interesting place. There are lots of challenging, engaging projects in the real world. But it's not a playground. Most offices are cube farms or open bullpens. There are a whole lot of add/change/delete screens and login pages to code for each unique and challenging algorithm you get to invent. There are a thousand lines of somebody else's poorly written code to patch for every line of your own unique software stylings.

Employers really are desparate for top talent. Only the thing is, new grads aren't top talent, no matter how smart you are. You're a n00b, a novice. You won't even know how much you don't know for a couple of years. To employers, top talent means that one guy on the team who turns out 10 times as many lines of solid, functioning code as anyone else; who works 80 hour weeks for 40 hours of pay; who's been coding since he built his first computer from individual logic gates when he was six. Top talent has already worked for Microsoft and Google and Facebook. That's how your employer knows they're top talent. You haven't worked for anyone at all.

There are indeed startups with free food, and wine, and foosball, and a fancy office. They just aren't all the same startup. And most of them are in just one or two cities; cities where a decent house costs a million bucks; cities you don't currently live in. What every startup has is long hours and low wages and stock options, which 99 times out of 100 expire worthless, and 1 percent of the time make you a millionaire. Most startups only live for a year. Then they crash and take your dreams of wealth with them, leaving you unemployed, wondering why you worked so hard for so little.

In the real world, if you're lucky, you either play nice with others, or find yourself suddenly unemployed. If you aren't so lucky, your employer doesn't care if you smell like sweat socks and annoy your colleagues with conspiracy theories, because basically they don't even care if you are a carbon-based life form, as long as you crank out code.This type of employer treats you like a replaceable part, and discards you like last years' cell phone when they're done with you.

In the real world, your CEO is probably not a geek. He's probably an extraverted, glad-handing, back-slapping, ex-frat-rat, because weirdly enough that's the right skill set for a CEO. He definitely votes Republican. And he thinks you look a lot like the nerdy kids he used to stuff into lockers and trip in the cafeteria.

Working in the real world is a job. It can be a lot of fun, but it's also a lot of work, and a certain amount of tedium, and a certain amount of putting up with stuff you don't like. There are 2,000 Mondays in the average career. Anyone who tells you different doesn't know what he's talking about.

Sunday, August 5, 2012

How I Became an Old Hand

One morning, about 17 years into my career, as I sat down in front of my terminal to begin a day's coding, a thought occurred to me. I knew, with the certainty of muscle memory, that any idea I could think up, I could turn into working code. What was more important, I realized that this hadn't been true a year ago. There were things I wouldn't have dared attempt because they seemed to me too hard or ill-defined.

Seventeen years is a long time to master a craft. I'm sure there are people who became master craftsmen in fewer years. I'm also sure that anyone who thinks they have mastered software development in one year, or in five, is delusional. Mastering the craft of software development is like mastering a martial art, sport, or musical instrument. There are aspects of the craft that just take time to develop. There are no shortcuts.

You are an Old Hand when you know you are one, with the certainty of completely internalized reflexes. There is no test. There is no certification. There is no course of study. You cannot buy mastery with any currency but time and practice.

That does not mean you cannot improve. Mastery is only obtained through study, but study doesn't lead to mastery. Study does lead to knowledge, and to improved practice. But mastery comes from a different well.

Mastery doesn't mean you cannot improve either. With considerably more years practice behind me, I find coding tasks come easier and easier. And I'm still learning too.