Getting past the resume screen

One of the hardest parts of finding a job is actually applying to it. It takes quite a bit of work to prepare a resume and the last thing you want is for all that hard work to be immediately thrown in the trash upon arrival.

The perception: At first you might just think "I'm bad at taking tests" or "I didn't really want to do that job anyway". After waiting for responses from a few more companies that are not going to respond it seems like no one wants you. Then someone calls back, and wants to talk about your resume. For a minute you feel great, and they can hear the pep in your voice, but they never ask you to interview and it starts to feel like you're not good enough. Eventually you end up thinking you'll take anything, and after a little while longer you just become a .

The reality: There's good news though! You're probably just making simple mistakes in the way you present yourself and your accomplishments, and you can learn how to correct those mistakes. This series of blog posts is a crash course in getting past the resume screen for most programming jobs.

Understanding the employer perspective

Most companies have a simple set of requirements. The list is not always exactly the same, and unfortunately the way they go about hiring for these attributes is not consistent, but we will deal with that later. These attributes are the most globally important to any company who is looking to hire for a full time position.

Someone who can do the job.

The perception: This is often comes across poorly in job listings as long lists of alphabet soup, often accompanied by many years of experience in those technologies. You think the company is stupid for requiring 10 years of experience in a technology that's only been in existence for 7 years. Or worse, you think "shucks, this job would be awesome if I had 3 years of cold fusion experience".

The reality: Job listings are often not written by people who have much of a clue of what the programming terminology they are using. The HR person will either wing it from their experience or they will ask someone in the dev management chain for a brief job listing with requirements. The dev manager (for lack of a better term, HR people tend to be quite intelligent) tries to dumb down the requirements to something the HR person can verify before passing a resume along.

In truth, you should only worry about these lists of requirements for jobs that need to be completed tomorrow. Just about everyone else is willing to train you on the job as long as you show promise and the ability to learn quickly.

Someone who cares about the work this company is doing

The perception: They want power users to work on their product, or industry experts who are pushing the bleeding edge forward with their every commit.

The reality: Well actually that sounds awesome, and they do want those people. Unfortunately there just aren't a lot of those people, they tend to have great jobs they are way happy with already and the company has actually taken those people out to multiple lobster dinners to try to woo them already.

For everyone else who can do the job, it's important that they stick around for a while. It costs a lot of effort and money to get someone up to speed on a codebase. Having someone on board who already understands the thing they are doing makes it a whole lot easier to ramp them up, productivity comes a lot faster and they are less likely to jump ship when the problems get harder.

Someone who can make the team better

The perception: They want people who can come in and solve these problems that they are working on because they already know how to solve them.

The reality: Most companies have lots of things they want to do, but limited resources (man hours) in which to utilize. Hiring more developers increases that pool of resources. With some luck, as the new devs gets ramped up, they will also have some other good ideas for the tools they work on.

For most people, being the smartest person in the room gets old pretty quickly because you no longer feel challenged and you feel like too many of your personal resources are being used helping other people accomplish their tasks without getting the same help in return. Often the catalyst for changing jobs is exactly this and you need to find a new job with smarter people who you can learn from again.

At some point in your developer career, you'll find someone who knows one technology or paradigm far better than you could hope to learn in a good amount of time (say 6 months or a year). This is when humility starts to set in and it's a wonderful thing. It's especially wonderful when that same person comes to you for help on a topic you are much more familiar with. This is a very fruitful kind of relationship and good companies try their hardest to foster this kind of diversity on their teams.

What's next?

That's pretty much the gist of what most companies are actually looking for. In the next episode we're going to take a look at your resume from an employers perspective to make it clear where the problems are.