A little less than a month ago I made a podcast with John about how recruiters can find good developers. A small part of the podcast talked about reaching out to developers, and how adding something personal (ie, mentioning one of their projects) can really get some attention.

In the past few days, I’ve gotten two emails from recruiters: One awesome one, and a terrible, obviously automated one that I’d never, ever respond to.

First, the bad one:

Hi,
At some point in the past you contacted our firm directly or posted your resume on the internet.

You may not be qualified or even interested in this position but if you know someone in that may be interested in the position described below, please forward this email to them.

The good one:

Hey Kenny,

I work in Team Development (not a crappy tech recruiter spamming people) over at [company] and have hired over 50% of the team over the last three and a half years. In fact, I brought [person I know] on board straight from [place I used to work] a couple months ago. Your experience at Huge and LTech caught my eye because our dev team is growing and we’re looking to add a Software Engineer to the team.

[... The Rest ...]

Sh-bang! That second one is awesome. I responded (saying I was happily employed), but I appreciated the reach-out.

The first one is horrendous. In fact, I was going to click “Report Spam” in GMail, but I decided I would write up a quick post about it instead.

Is that how some firms actually try to recruit people? I can only imagine that the most desperate of job-seekers would actually follow-up on that. And the event that they are truly desperate, I’d say that the probability of the job-seekers being qualified for the job is a tad (just a tad) low [citation needed].

The worst part is that the email was framed as if it was from a real person.

Maybe they aren’t even looking for good developers.. who knows. But this is my point: If you want to increase the probability of someone responding, make it personal.

A comment on one of my favorite CodeFury posts, “How to Get a Job as a Programmer“, asks an interesting question. It was posted by Kyle Carter, the head of HR at Better Advertising. He posed the question, “how or where do I find good developers?”

At the time that I’m writing this, the NYC tech market is picking up fast. More startups are getting funding, big corps are relaxing the budgets, and good developers are jumping ship left and right in search of cooler projects, awesome teams, higher positions, and big checks.

So, to put that question in context: How exactly do recruiters and HR departments find and compete for the best talent right now? John Crepezzi (my startup partner) and I put together a podcast going over a bunch of different things, like identifying good developers, finding them, keeping them and why you want them in the first place. Listen to it here:

http://podcasts.oconf.org/episode1.mp3

If you would rather listen to it streaming online via the HTML5 player @ Tumblr, check out it out here.

The basic gist is this: Good developers are people who like to build/improve and learn. They are very active with both consulting and open-source projects, often outside of a regular full-time job.

They like to work with other good developers, which is why great engineering teams attract more great engineers.

You can find them on GitHub, SourceForge, and Twitter, by reaching out to them (once you’ve identified them as ‘good’). Include a personal note (maybe mentioning some of their projects), which is a big deal — it will likely get you a response at the very minimum. Once you know a core of good developers, it’s not difficult to find more by asking them.

The podcast goes into much more depth. If you’re a recruiter or HR guy, take this podcast not so much as if it’s from an authority (despite the tone), but from developers who love what they do.

If you have any comments, drop’em.

It seems that for the better part of my life, America’s economy has been in murky water. I was born into a Reagan economy (good), graduated to Bush Sr. (bad), did my time with Clinton (good), and started looking for jobs as a developer during Bush Jr.’s tenure (bad). And while I’ll abstain from the more political conversation, Obama’s reign doesn’t look much better in terms of economic health (of course, he inherited a lot of trouble).

And throughout those recessions of the last ten years, there doesn’t seem to be a much more exciting topic for news anchors to talk about then joblessness. The unemployment rate is up, it’s down, this year’s graduates can’t find jobs, and here’s the story of Marty McNoJob, who has been unemployed for 62 years. Many people (grandmas in particular) eat it right up, and try and convince you to get into whatever field is hot at the time.

And accordingly, mountains of advice articles (like this one) try and give you a good idea of how to get a job in this tough economy. Put these words on your resume, wear a suit, get a minor in management, send thank-you notes, get a degree if you don’t have one, and talk about how much you raised revenue at your last job, etc.

But here’s the startling truth about one-size-fits-all advice like this (which you can find almost anywhere): These rules do not really apply to software development. Software development is a completely different ball game.

So now that I’ve given you a fairly lengthy segway into the actual topic of this post, let me be clear about my background:

• As a freelancer, I’ve been to a hell of a lot of interviews
• Almost all of those interviews resulted in job offers (yes, in this economy)
• I’ve interviewed plenty of people for employers and as a business owner
• I’ve written plenty of resumes for co-workers and friends that have gotten them interviews

The number one rule to getting a job as a programmer is to be good at what you do. This applies to recent graduates too.

When you go to school for a computer science degree, there’s a good chance you went somewhere that offered other engineering degrees such as Mechanical, Civil, and Electrical Engineering. Think of those other majors. How the hell is a Civil Engineering major going to get any real field experience before his first job? He can’t. But programmers have it completely different. Programmers can get field experience as early as they want. If a young programmer in middle school wants to write a website or a video game, he can learn how. He can read up on the vast, free resources on the internet and build up his awesomeness. If a Civil Engineering major wants to build a bridge in high school, he better like playing with Legos.

The programmers who get jobs in a tough economy are those with experience and projects they can associate their names with. That leads me to my next rule.

The second rule to getting a job as a programmer is to have a portfolio.

Software development is a wacky world in that good companies hire people based on talent, not on “years of experience”. In fact, 15 years’ experience in the world of software development could mean absolutely nothing. This is something that recruiting firms have yet to grasp (which is why programmers should probably stay away from headhunting firms, which is for another post). Good hiring managers know this.

So you may be thinking, “I’m a recent grad, how can I possibly have a portfolio this early?” If you became a software developer because it supposedly paid well, you’re out of luck. You likely don’t love the craft, and you might lack the ambition to have done anything significant as a developer up until this point. But developers who love what they do can:

• Get an internship
• Get involved in an open-source project
• Roll your own project

The point is to have something cool to talk about at your interview. If you’re being hired out of college, for the love of god, make sure that you have something that your interviewer can talk about other than what your favorite classes were in school.

The third rule is that you can’t look like a rookie.

Forgive the l33t talk, but in a tough economy, companies don’t have the money to risk on hiring a noob. They want to hire someone who can jump in on a project and hit the ground running. There is little to no “on the job training” in the world of software development.

So what can you do to avoid looking like a noob?

• Chances are, you shouldn’t wear a business suit to the interview. The goal is to look well put-together, but fairly casual.
• Bring a nice stack of screenshots which showcase projects you worked on. Don’t unnaturally force the interviewer to take a gander, but if you’re explaining a project you worked on, it can be much more effective to put an image to the description.
• Don’t use idiotic jargon on your resume. Example resumes online have absurd phrases like “goal-oriented, motivated individual seeking position in a fast-paced agile environment where they can grow, learn, and advance”. All I see when I read that is “n00b, noob, noob, I’m a fat scrub.”
• Don’t use acronyms that you can’t back up. If you list both Ruby and PHP as languages that you know, be sure that you can answer thorough question on each. And expect to answer the fraud destroyer questions like, “So can you tell me about some of the ways that PHP and Ruby differ for both good and bad?” This is truly an open-ended question, and the interviewer is really just trying to gauge your expertise.

The fourth rule is that it’s okay to say that you don’t know.

“I don’t know.” — A wonderful phrase used by millions of students in the world to get teachers off their backs when they’re called out because they weren’t paying attention. But in the business world, apparently ”I don’t know” is an invitation to disaster.

Guess what? If you’re pitched a cut-and-dry question like “How is garbage collection handled in C#?,” and you don’t know, just say so! Essentially, be calm and say something like “that’s something I’ve actually never looked very deeply into, so I’m not entirely sure.” The interviewer may ask you describe how you think it works. This is when it’s okay to say something that might be wrong.. He just wants to hear you think out loud.

The worst thing you can possibly do is act like you do know, but be wrong. In software development, admitting when you need help or you don’t know how to do something is key to the success of the team. Project managers want someone with a “can do” attitude, but they don’t want someone who is going to throw the project off schedule because of his pride and his refusal to admit he needs help.

Also, saying you don’t know does not make you look like a rookie (see rule #3). Software development is a gigantic, always-changing field, and it’s impossible to know the ins-and-outs of everything.

The fifth major rule is that you have to build street cred.

Expect to be Googled (especially if you have a unique last name like Katzgrau). For me, no one’s name is safe from The Google. Whenever I’m about to work with another developer, I check up on their internet rep. Why?

Because if they have a website, blog, github account, stackoverflow account, sourceforge page, etc, I can begin to verify their authenticity. Suppose I get two resumes, and one of them has a GitHub account listed. If I can see some of their code contributions online, I have a much more realistic sense of who they are as a developer — not the actor that walks in the door trying to impress me. I would absolutely feel much better working with someone who’s code quality and contributions I can verify.

Get a website, blog, or some other public account where the smart guy that you are can really shine.

A word on having a college degree:

College degrees are not always required for some of the best development jobs. You can easily make 100k+ if you’re great at what you do, and you don’t have a degree.

That being said, you should probably have one. I hate to think it, but some companies and hiring managers will actually check to make sure you have a degree despite other fantastic credentials on your resume. It’s practically a stamp of approval from another institution.

But in reality, what good is a degree? There are certainly some institutions out there whose Computer Science degree courses are fantastic, useful, and progressive. But the majority of them — and I think I’m safe to say this — suck. Students are usually stuck in a classroom with professors who haven’t worked in industry for at least 20 years, if ever. They can’t tell you about things like unit testing, design patterns, version control, agile development, code reviews, or other industry shenanigans like that. But that’s just my take, and certainly doesn’t apply to everybody.

It’s really interesting, because the development fields’ laxness in regard to degrees is in stark contrast to fields like Education. For many teaching jobs, you must have a Master’s degree. Did that Master’s really help any teachers teach more effectively? I don’t know the answer to this question, but I’m skeptical.

And a degree from a fancy-pants place like MIT will probably help you get in the door (if not from sheer prestige, than probably from networking), but it won’t carry you forever. Ultimately, it’s the work that you’ve done that gets you future jobs, and help you take over the world.

Lastly, some smaller, but important notes that don’t deserve a spiel

• Don’t pitch yourself as a language-specific developer. It’s important to list technologies that you’re really good at, but don’t make it seem like the only thing you’re interested in is one language. Java developers seem to do this a lot, but I have little basis for this other than observation.
• If you’re still in school, maintain a good GPA, and above all, read this classic on the Joel On Software Blog
• Know at least one language that is widespread. It’s cool to be a Python developer right now, but most job postings are looking for C, PHP, .NET, or Ruby devs. Python is something that is totally awesome, but it might not open all the doors that you’d like.
• Always make sure your resume is up to date. When you work with a new language or you are on a new project, make sure it gets a spot.
• Resumes, contrary to popular belief, do not have to fit on one page. If you’re a developer with a few or more projects, this can be somewhat difficult to achieve without sacrificing important information
• Prepare for the interview. Look up questions commonly asked on the interview on places like GlassDoor.com

Anyway, if you needed this advice, take it to heart, and build your cred. If you read it just to see what I had to say, pick out anything you agree or disagree with and comment. And if you think this is oh-so-absurd, start a flame war.