Résumé Shortening (and other résumé advice)

I saw a tweet from one of the best tech follows on Twitter (@raganwald) earlier today about the difficulty of shortening your résumé to five pages. While my career in tech is quite a bit shorter than his (and doesn’t include being a published author), I’ve been writing software for a living (and building/leading teams that do) long enough to need to shorten my own résumé to less than five pages.

While I’m certainly not the first person to do this, my (brute force) approach was to change the section titled “Professional Experience” to “Recent Professional Experience” and simply cut off any experience before a certain year. The general version of my résumé runs just 2 1/2 pages as a result of that simple change alone.

Other résumé advice I’ve followed over the years includes:

  • If there is a quantitative element to any of your accomplishments, lead with that. Prominently featured in my latest résumé are the annual dollar figures for fraud losses prevented by the team I lead (those figures exceeded $11 million in 2 consecutive years).
  • Don’t waste space on a résumé objective statement
  • Use bullet points instead of paragraphs to keep things short
  • Put your degree(s) at the bottom of the résumé instead of the top
  • Make your résumé discoverable via search engine. This bit of advice comes from my good friend Sandro Fouché, who started the CS program at University of Maryland a few years ahead of me (and has since become a CS professor). I followed the advice by adding a copy of my current résumé to this blog (though I only make it visible/searchable when I’m actively seeking new work). His advice definitely pre-dates the founding of LinkedIn, and may predate the point at which Google Search got really good as well.

Speaking of LinkedIn, that may be among the best reasons to keep your résumé on the shorter side. You can always put the entire thing on LinkedIn. As of this writing, the UI only shows a paragraph or so for your most recent professional experience. Interested parties have to click “…see more” to display more information on a specific experience, and “Show n more experiences” where n is the number of previous employers you’ve had. Stack Overflow Careers is another good place to maintain a profile (particularly if you’re active on Stack Overflow).

Managing Your Tech Career

Episode #980 of .NET Rocks was an excellent 52 minutes on career management for developers.  Since turning 40 this year, I’ve been thinking a lot more about my career and where I want to take it from here.  The entire episode is well-worth listening to, but I would distill the essence of the advice from the guest (John Sonmez) down to this: market yourself.

When I gave a talk to some software engineering students back in February, I encouraged them to start blogs, give presentations and talks, and start podcasts (so far I’ve only done the first two myself).  I suggested all of these things primarily as a way for them to improve their knowledge, but a higher profile on the internet is certainly a positive side-effect of doing those things.  One point I didn’t add (which Sonmez brings up in his interview) is that consistency is very important.  He recommends a blog post every week.  That’s a goal I’m striving to meet (though not always succeeding).

Another related point Sonmez made is that developers need to set aside regular time to manage their career.  The amount of time averaged something like an hour every two weeks.  Consistency is especially important here as well–if not mandatory, given how quickly technology advances.  I’ve recently started reading The Pragmatic Programmer, and it makes a similar point but uses investment terminology.  Section 5 of the first chapter (Your Knowledge Portfolio) make this point:

“Your knowledge and experience are your most important professional assets.  Unfortunately, they’re expiring assets.”

Knowledge about specific programming languages, databases, etc can age very poorly.  Failing to consistently add new assets to your knowledge portfolio, to diversify and balance those assets among various technologies (of varying maturities), and to “re-balance” that portfolio over time can result in obsolescence.  Given the prevalence of ageism/age discrimination  that already exists in information technology, having old or irrelevant skills is a quick way to end up at the margins of IT, working in companies that are yoked to technologies that will make it increasingly difficult for them to serve their business goals (much less to serve your goals of having a fulfilling technology career).

I saw this first-hand in an unexpected way when I attended South by Southwest in 2013.  One of the shuttle bus drivers I rode with regularly between my hotel and the various conference venues was actually doing it for income between short-term software development gigs all over the country.  He was an older gentleman whose skills (at least on the Microsoft stack) hadn’t advanced beyond VB6.  While there are still a ton of software systems built in VB6 (I certainly built my share of them in the late 1990s and early 2000s), his knowledge portfolio means that contract work maintaining VB6 code may be all that’s available to him.

In my own career, I’ve been working to broaden my own knowledge portfolio beyond the Microsoft stack.  Microsoft itself is doing some of this by adopting external technologies like JavaScript, jQuery, and knockout.js for web application development.  Angular.js is a framework strongly supported by Google that Microsoft has made sure plays very well with ASP.NET MVC.  So building my knowledge of JavaScript, and platforms like node.js are also goals for me in doing what I can to remain an attractive candidate for hire–whether as an employee, or for a future of self-employment.

Another Year Gone

It’s annual review time again, which means this year has gone by even more quickly than usual. Filling out my self-assessment was a good reminder of all the work I had a hand in completing.  I’m still deciding on goals for 2012, and I’m posting all of them here so I can look back on them over the course of next year and track my progress.

  1. Learn jQuery.  I got a bit of exposure to it this year through a couple of projects that I worked on, and a .NET user group presentation or two, but haven’t done the sort of deep dive that would help me improve the look-and-feel of the web applications I build and maintain.
  2. Learn a functional programming language.  I’ve been thinking about this more recently since some of our work involves the implementation of valuation models in code.  I also came across this article in the November Communications of the ACM advocating OCaml.  Since I work in a Microsoft shop, picking up something like F# might have a slightly better chance of making it into production code than OCaml or Haskell.  Part of my objective in learning a functional programming language is to help me recognize and make better use of functional techniques in a language like C#, which has added more and more support for the functional programming style of the years.
  3. Give a few technical talks/presentations.  This year, I presented on NuGet at my job, and on Reflector at RockNUG. Having to present on a tool or technology to group has always been a great incentive to do some deep learning of a subject.  It’s also a chance to exercise some speaking skills (which developers need a lot more than they might think in order to be successful) and to handle a Q & A session.  I haven’t developed any new presentations yet, but some prospective topics include: LINQPad, elmah,
  4. Take more online training. We have access to Pluralsight .NET training through work.  I watched quite a few of their videos over the course of the year.  2012 shouldn’t be any different in that respect.  I recently came across free webcasts on a variety of topics from DevelopMentor.  Since they’re downloadable as well as streamable, I’ll definitely use my commute to watch some of them.
  5. Write a compiler. It’s been awhile since I’ve cracked open “the dragon book”, so I’m probably overdue to exercise my brain in that way.  I found that suggestion (and a number of other very useful ones) here.
  6. Practice.  I’d heard of the “code kata” idea before, but hadn’t really explored it.  Dave Thomas of Pragmatic Programmers has nearly a couple dozen here.

The problem with exit interviews

The biggest problem with exit interviews is that they’re too little, too late. I had an exit interview recently (since I accepted an offer to go elsewhere), and there wasn’t anything wrong with the questions–it was just that nothing could be done about any of the concerns I raised.

The second major problem with exit interviews is that they focus too narrowly. All the feedback from exit interviews comes from people who’ve decided to leave. Assuming a company has had relatively low turnover for awhile, the feedback could be leaving out information from as much as 90% of its workforce.

If a company is serious about employee retention, they need to get feedback from as much of their workforce as possible on a regular basis. In my exit interview, I got questions about benefits, commute, holidays, and other issues. Regular, anonymous surveys on those issues would probably reveal a lot of useful information about ways benefits could be improved. Gathering this kind of information regularly will mean that at least some (if not most) of the answers you get will be from people who still have a stake in the company’s future.

Can Google Find You?

Recruiters use Google.  Whether you’re actively seeking a new job or not, it’s important to use this fact to your advantage.  My friend Sandro gave me this advice years ago, when he told me to put my resume online and make it “googleable”.  For me, the result was contacts from recruiters and companies I might never have heard of otherwise.  In addition to putting your resume online, I would recommend blogging about your job–within reason.  Definitely do not write about company secrets or co-workers.  Putting such things in your blog doesn’t help you.  Instead, write about what you do, problems you’ve solved, even your process of problem-solving.  At the very least, when you encounter similar challenges in the future, you’ll have a reference for how you solved them in the past.  Your blog post about how you fixed a particular issue might be helpful to someone else as well.

There are many options available for putting a resume and/or blog online.  Sandro hosts his, mine, and a few others on a server at his house.  But for those of you who don’t have a buddy to host theirs, here are a couple of readily-accessible free options:

There’s a ton of advice out there on what makes a great resume, so I won’t try to repeat it all here.  You can simply put a version of your 1 or 2-page Microsoft Word resume on the web, or you can put your entire career up there.  Having your own blog or website means you aren’t subject to any restrictions on length that a site like Monster or CareerBuilder might impose.  Consider linking your resume to the websites of previous employers, technologies you’ve worked with, schools you’ve attended, and work you’ve done that showcases your skills (especially if it’s web-related).  I don’t know if that makes it easier for Google to find you, but it does give recruiters easy access to details about you they might have to dig for otherwise.  Doing what you can to make this process easier for them certainly can’t hurt.

Don’t forget to Google prospective hires

One of my colleagues reminded me of that today.  The developer we’re interviewing tomorrow was the #1 result from Google when I searched on his name, thanks to his blog.  This works a lot better with uncommon names, of course.

My name (Scott Lawrence) is fairly common, so it’s only the #6 result on Google.  The result is probably that high because one of last month’s blog posts referred to Scott Hanselman.