Prove, don’t say

Consider the following excerpt from the skills section of a resume:

AWS (EC2, related services), Puppet, load balancing

What does that mean?

Does it mean…

“I’ve got a lot of personal experience of lovingly setting up a whole bunch of immutable infrastructure with auto-scaling instances in the cloud, and helping my team migrate to it?”

Pssssst! Enjoying the article?

I'll email you once a fortnight with a summary of anything new I've written, and also send you the free How to write a developer resume that'll get you hired e-book.

… or …

“I was on a team where the Devopsy people had setup the infrastructure, but I wrote scalable applications that were deployed across all of them and occasionally debugged issues?”

… or …

I was on a team where they’d just started experimenting with some degree of deployment on to AWS?

… or …

I read some of the Puppet tutorial, and spun up two machines myself in my free time, and wrote some PHP with Elastic Beanstalk on the front-end as a hobby project?

… or …

I have heard all of those words at least once, pretty much understand those words, and could take a stab at describing what they mean in an interview?

I’ve personally interviewed (many) candidates whose anemic skills section or minimalist approach to describing technologies used in the past looked just like our example, and it could mean any of the above. As a result, I’m likely to be skeptical and assume the worst.

Just mentioning the magical skills on your resume may get you past keyword-matching internal and external recruiters, but the two technical gatekeepers who’ll read your resume will be left guessing. If they under-estimate your skills based on a few words, you won’t get an interview, and if they over-estimate your skills, you’ll fall apart in the interview when they dive in to it.

We can do better than that.

Bitter experience and war stories

A pet theory I have is that technical experience is most valuable because when you come across problems to be solved, you’ll have solved similar problems in the past, and you’ve got some good ideas of what works and doesn’t work.

Whether that’s true or not, it’s absolutely true that when you’ve worked with a technology you’ve also probably been bitten by it. You’ve probably formed opinions on which bits you like about it and which bits you’re not so fond of. You’ve probably touched auxiliary tooling around that technology. You may have used more than one version and seen improvements and upgrade issues between versions.

As a Perl developer, I’m acutely aware that There’s More Than One Way To Do It in many situations. The more experienced with any given technology you’ve become, the more different approaches to using it you’ve likely seen. You’ll have formed opinions on the benefits and drawbacks of those different approaches, and you’ll probably have picked up a deep understanding of what problems each approach is trying to solve.

if thou gaze long into the Puppet documentation, the Puppet documentation will also gaze into thee — Friedrich Nietzsche

All of these things form a body of evidence that you have Real Actual Genuine Experience In Production of the technologies you’re mentioning, and presenting this evidence allows you to prove it, rather than just saying it. To paraphrase the utterly unreadable Nietzsche, “if thou gaze long into the Puppet documentation, the Puppet documentation will also gaze into thee”.

These things make great content for the work experience section of your resume, and in prose form when talking about your skills.

A quick example

This topic will get covered in great depth on this blog, so we’ll stick with a simple example, and we’ll go with EC2 + Puppet as that’s what we started with.

We’ll kick off with what we started with:

AWS (EC2, related services), Puppet, load balancing

But we’ll add a bullet point for each of our types of experiential evidence.

If you like a piece of technology, you’ve probably been bitten by it; for me, with EC2, that was losing control of costs and who owned what:

  • Experienced using tagging schemes to accurately track costs and resource ownership

Opinions on which bits of the technology you’re fond of, and which you’re not so fond of; love my fine-grained access controls, but am yet to have an IAM role work first time…

  • Many hours spent fine-tuning IAM controls in conjunction with the documentation to provide secure minimal functional access

Auxiliary tooling; gotta find a way to have the same environments in dev and production…

  • Use of Hashicorp’s Packer to create both AMIs and Vagrant boxes to allow developers to code in an environment almost identical to production

Several versions and the differences between them…

  • Encryption of server-side credentials initially with `hiera-gpg`, migrating to `hiera-eyaml` very shortly after it was released

Different approaches to problems, and their strengths and weaknesses…

  • Decided where to draw the line between spinning up a new box for every service and consolidating machine usage to reduce costs

Putting it all together, we get:

AWS (EC2, related services), Puppet, load balancing

  • Experienced using tagging schemes to accurately track costs and resource ownership
  • Many hours spent fine-tuning IAM controls in conjunction with the documentation to provide secure minimal functional access
  • Use of Hashicorp’s Packer to create both AMIs and Vagrant boxes to allow developers to code in an environment almost identical to production
  • Encryption of server-side credentials initially with `hiera-gpg`, migrating to `hiera-eyaml` very shortly after it was released
  • Decided where to draw the line between spinning up a new box for every service and consolidating machine usage to reduce costs

 

And we’re much closer to having proven, rather than just said, that we have the skill-set we’re claiming…

One final advantage

There’s another useful side-effect of writing out skills with observations about the skill:

Many of the technical people interviewing you will have very little structured idea of how they should conduct the interview, and will mostly be just scanning your resume for interesting things to talk about.

Rather than simply inviting ad hoc questions about Puppet, we’ve laid out five specific things we know we can talk about to show off our experience. We’ll no longer get such open-ended questions like “So, uh, tell me about Puppet” — we’ve now set ourselves up for questions that allow us to show off our knowledge and setup discussions such as “So where is the line between spinning up a new box per service, and running many service on one box?”.

Remember, on your resume: prove it, don’t just say it

All done?

I'll email you once a fortnight with a summary of anything new I've written, and also send you the free How to write a developer resume that'll get you hired e-book.

Published by

Peter

Peter is a former developer and CTO turned recruiter who wants to demystify the recruitment process so that developers can find jobs and get paid more.