Gary Haran.com

Head hunters offer a very valuable service to society but I fear that they’re not evolving at the speed of the internet. If they don’t learn to use the new tools available, they risk getting a bad rap. Heck, they’ll be thrown in league with spammers.

Demography is turning the tables

The population is getting older. As lots of people are retiring a younger crowd is the one that you need to cater to. They’re a really different breed. It’s been said that “Generation X won’t do things because they have a deep sense of mission, or loyalty to an organization.” and generation Y are said to “switch their loyalty in an instant“.

This younger crowd is driven by a desire to change the world. They’re attracted to jobs that give them social recognition or have bigger meaning. If they can change something in this world they’ll pick that job over another.

If you approach them in a sloppy manner they’ll see the organization as a boring entity that just doesn’t get it. They’ll want nothing to do with you or the job offer.

Worst Way To Attract Talent

Nothing spells awkward better than a recruiter spamming a bunch of people on a mailing list. He’s not doing anyone a favor if the mailing list is a technical one. He’s just spamming.

One famous example of bad netiquette is Pradipta who sent out an email forgetting to use BCC to 416 people.

Another form of spamming is hitting the “Add As Friend” button on Facebook to whoever might possibly be a programmer in your region. This guy doesn’t have a profile picture and I know none of the 4 friends on his list.

This head hunter wasted his time and mine and managed to look like a goofball in the process. It reminded me of my uncle trying to act cool with the young crowd by putting his baseball cap on sideways while he was drunk at a party. Any head hunter using Facebook is taking a step in the right direction. He just needs to know that it’s to make himself available, not to spam.

Best ways to attract talent

Employers need to react to this trend and find more innovative ways to attract top talent. (disclaimer: I work at a company building tools to help recruit talent)

Knocking at someone’s door with a job offer isn’t what it used to be. In different times a message about a job offer would have been a favor but today it’s becoming an annoyance. If you are a recruiter and want to reach out to people you have to research your candidates and send an appropriate message through email. If they have a web page with a means of contact you should use that instead.

Tell them how you heard about them. Explain who you are. Tell them about the company and the job but keep it short.

6 Tools A Recruiter Can Use

Twitter: Create a complete profile. Speak your mind about your profession and tweet about job offers in the area.

LinkedIn: Create a complete profile. Create your online network and publicize job offers. People on LinkedIn will accept messages about job offers if they set it in their profile. You can also ask people if they know someone to make your network grow.

Facebook: Create a complete profile. Use it as a window for potential recruits to get to know you. Don’t add someone as a friend to send them a job offer unless someone you both know introduces you.

Google: Search for groups in your area. If there are meet-ups feel free to show up with a few business cards. The ones looking for jobs will appreciate it and you’ll expand your network.

Google Groups: find out what the policy is on job offers. Feel free to ask rather than just post a question.

Standout Jobs(disclaimer I work there): Post job offers on a slew of job boards and find out which give you the best results. Use the sourcing tools to find internet savvy candidates.

I had a really good experience last night with the Standout Jobs team. We had a hairy situation dealing with some new features. The difficulty was that we did too much magic for the end user and it simply didn’t flow from an navigation point of view.

We rarely have lengthy meetings (meaning anything lasting more than 10 minutes) but we spent close to 30 minutes last night trying to figure out the best way to implement things. In the group we had ruby guru, a design guru(more of a Design-Grammer), the CTO and I (a front end programmer).

First we determined what we weren’t doing right then looked at how other web applications approached similar features. The process we went through was very different than what you’d see in a company used to the waterfall model. One saving grace was that we didn’t have huge specifications to blindly follow. This meant we had to think and speak up about what the feature should look like. At any time we could be asked to explain why we implemented something a certain way.

Everyone on the team was open to suggestions even if it meant reviewing what others in the team had already done. Actually we know that everything we do is iterative and nothing is ever set in stone. It’s called the Agile and because this process has a name it’s easier to stand behind it.

After 30 minutes of arguing we settles on an elegant solution to our problem. We split one end-user action that did two different things at once into two separate end-user actions with each their own feedback. We changed the navigation to reflect those changes which made it clearer even for us. Though we didn’t change code during the meeting the resulting code will be easier to test. It’ll also be easier to change if we want to at this point.

A similar experience in company espousing the waterfall model will clearly result in so much red tape that most programmers would just give up and live with it. Imagine having to ask a manager to change his sacrosanct specification document. So many programmers are discouraged to even speak up in large enterprise that their improvements rarely see the light of day.

In a startup egos and job titles don’t get in the way of communication. Everyone’s input is valued and encouraged.

RubyFringe exceeds expectation. The unspace crew who initiated the conference really know how to organize one.

I’m tweeting about RubyFringe live and so are many others on my list.

Writing bug reports is not an art form but a science. If you write bug reports for your team (and yes programmers should write some) here is a short list of what your report should do.

1. Tile of a bug report: describe with a subject and a verb

The title should be a clear and concise explanation of the problem. It should include a subject and a verb.

Bad: Saving does not work.
Good: Body field does not save on submit.

Don’t limit yourself to only subject and verb when the problem only occurs in some circumstances.

Better: Body field does not save on submit when using IE 7.

2. Body of a bug report: enumerate steps to reproduce

The body of the bug report should explain what steps lead to the problem. This means that anyone reading the bug report should be able to reproduce it using only the information in the report.

Bad: [empty body]
Bad: Field body does not save.
Good: I logged on with user madcoco and typed in the usual lorem ipsum in the body field. When I hit submit the “saving” message appeared but timed-out. When I hit refresh the rest of the form was saved but not the body field. This occured using Internet Explorer 7 but worked fine in Firefox 3.

Don’t forget that as you get more information you can always append more text to the body.

Better: John Doe from SkyNet tells me that he has the same error and it seems to be related to the latest Windows Update from Microsoft. This is a known issue as seen on http://www.ie-vista.com/known_issues.html

3. Body of a bug report: support the report with screenshot or screencast

The best bug report I received was a 22 second screencast. It arrived via email from a user who used some code of mine but was really bad at English. A screenshot might be all it takes but a video is the ultimate bug report.

Happy bug squashing!