This is Part #1 of the 3 Days To Building A Perfect Resume series.

One of the biggest mistakes I see in developers’ resumes is that fact that they get very granular in the details of their experiences. As I have said before, people think in terms of benefits over features. As a result, most developer resumes connect with developers, but create a very large disconnect with management.

Putting to much emphasis on technical terms and scenarios is just another form of dangerous geek speak. Some (but not all) developers do not attempt to “wow” the manager types by showing them benefits at their level, they instead attempt to “overrun” them with jargon thus thinking it will convince them that they are very experienced and the best logical choice. The opposite is actually true, managers will FUD on you and probably decide that (although technical) you are not what they are looking for.

In order to help interviewing managers connect the dots, work on a resume that outlines the diverse BENEFITS of the projects and people you have worked with, rather than the SPECIFICS.

What am I trying to say? Remember the styrofoam cup rant? People have never been interested in features (whether bullet points on a software box or on your resume), people are only interested in the benefits that those features bring.

The real “trick” is to write down your experience in ways that allow people to imagine what it would be like if they received those benefits and results. For example:

Common Resume Mistake:

• Built a ASP.NET CMS system for a high profile company that used it to monitor blood pressure machines. The client was very happy as it did 1 million transactions a day via AJAX.
• Managed a 100 person team dealing with C++ integration points to 3rd party products.

Result/Benefit Resume:

• Developed systems that significantly lowered the clients operating costs by maximizing the number of daily sales transactions
• Managed a large (100+) team that created a number of product opportunities and business partnerships by integrating with 3rd party applications and platforms.

Now which resume do you think will impress a manager? By presenting yourself as already solving problems that businesses continually improve on (i.e. increase sales, decrease operating costs, product development, etc…), the potential employer does not have to bridge the gap between your skills and the bottom-line benefits they will bring.

This simple resume tweak will take you from “AJAX blood pressure man” to “Team leader that can provide business opportunities”. Guess which one I would rather be…

Last week, I got a lot of great feedback and questions over the post – ‘Why New Developers Should Consider Contracting’. One of these emails stuck out of the rest, and was asking the question of actually how to move out of the consulting business.

Right after my undergraduate degree, I went to work for a consulting firm. I have gained tons of experience and have learned a ton about different architectures, organizations, and people. It truly has been a great experience.

In the past few months, I have arrived at a point where I am considering a career move that will allow me to move away from the demanding hours and stress that comes with consulting. Do you have any thoughts on how to make the move from the consulting world to a full time position?

Regardless of experience and job type, I do have some opinions and techniques that can greatly improve your chances of landing that dream job. Now don’t get me wrong, interviewing well is important, but Step #1 is ensuring your resume doesn’t get thrown in the trash.

This week, I will be doing a 3 part series called – 3 Days To Building A Perfect Resume. If you aren’t already be sure to subscribe via RSS or subscribe via email. I am handing out trade secrets here, and you won’t want to miss a single one…

A lot of young and talented developers are continually looking for new projects and problems to solve and gain experience with; however, there are very few single environments that provide the ability to diversify and grow. Most jobs consist of working on legacy code where there is very little architectural “wiggle room”. As a result, many developers feel the need to move to a different job or environment to get to the next level of learning.

While job hopping is one way to gain diversified experience, may I offer an alternative – contract work.

In hindsight, one of the fastest ways I matured as a software developer was through the experiences I had while working with a consulting company. Why is this? A few reasons:

Many New Projects (And A Few Old Ones)

Opportunity for a diversified workload is probably the biggest reason contract work is a great environment for learning. The opportunities for new projects and clients come fast and furious. In fact, in my experience I rarely was on a single project for more than 6 months (and even then, I was working on different client projects on the side).

The ability to start with a clean slate every 2-3 months is priceless. I always joke that the only code I am proud of I wrote less than 6 months ago. It’s for this exact reason, I got in the habit that I got to learn from every project mistake and continually get better.

Old projects exist as well (and this is OK) as it allows for developers to also learn how to maintain legacy systems. Brainstorming how to introduce unit tests into a Lotus Notes application can be a very daunting (but rewarding) task. Not every project gets a clean slate at the end, which is a great equalizer in terms of learning to write maintainable code.

Different Problem Domains

With different projects comes different problem domains. It is insanely fun to be building a restaurant’s blog, then to go to a meeting about blood pressure machines, and finish the day off with learning about retirement funds. Don’t get me wrong – it can be exhausting…but it is enlightening.

Probably one of the coolest domains I ever worked in was I had the opportunity to write an application that physically moved a HUGE dirt shovel for a coal mining facility. What an awesome domain! Physically coding with a hard hat on, in the middle of a strip mine, and my code is moving a 2000 ton machine around – can I get a hell ya?!? These opportunities do not present themselves often if you work for a company solely focused on one business domain.

Architectural Responsibilities

In most consulting shops, you are the lead developer, architect, and tester. Although being your own tester sucks, the trade off of being your architect provides unbelievable experience opportunities to implement the patterns and architectures you see fit.

Probably the hardest thing to gain is wisdom and insight of architecture. When to use them, when not to use them, when to use them but then break them. Different projects, different domains, and the responsibility to pull it all together provides the opportunity to gain this experience quicker than most job environments.

Learning To Deal With People

With consulting comes dealing with clients. Thankfully, I never had to deal with any assholes, but communicating with people is a skill that takes a lifetime to learn. If you do not learn how to talk to clients, you probably also don’t know how to talk to your boss, manager, or even spouse. Consulting forces you out of your dark corner, even if it is just in small doses.

Being a consultant is what you make of it. If you decide to be a hermit that never talks to clients and always decide to solve different problems with the same solution, you probably will not learn a lot. If you decide to sharpen your skills as a communicator while experimenting with different technologies, patterns, and architectures consulting might just be a good fit….