I’ve seen a fair share of tutorial links floating around in newsletters and Twitter and the like recently. They all promise the same thing, namely how to use React to create a résumé.
I mean, I get it. It’s important to have something to build towards when learning a new skill, especially with development.
At first blush a résumé seems like a good thing to build towards: They are relatively small in terms of complexity and can probably use content that already exists on your LinkedIn profile. If you’re looking for a job, it’s also a handy way to double-dip on a skill that is in high demand.
I checked out a few of these tutorials, and after noticing some patterns, I’d like to mention a few things you could do to your résumé instead. I’m not going to link to the ones I tested because I don’t want to give bad advice more exposure than it is already getting.
Use semantic markup
Each of the tutorials I audited did a terrible job at markup. Correlation isn’t causation, but there has to be something to the fact that framework-utilizing homepages show a greater degree of detectable accessibility errors when compared to non-framework utilizing homepages.
Rock-solid, semantic HTML markup is the foundation that you build the rest of your experience from. In the context of a résumé, the lack of semantically-described content would tell me:
- You don’t know about these foundational skills, or
- Don’t care about why they’re important.
This might sound harsh, but in the tech world this would be the equivalent of handing in a résumé printed on colored construction paper. Consider that there’s a decent chance someone doing the hiring may be checking your work out with this level of detail, as it's an example of what level of craft you’ll be bringing to their team.
How to do it
What you want to do is familiarize yourself with the HTML elements made available to us.
We want to use paragraph elements for content such as your summary statement. Anchor elements—not clickable
divs—allow you to link out to pertinent information such as your GitHub profile, personal website, email address, and even your phone number. If you’re looking for a job, making yourself easy to get in contact with is a good thing.
Unordered lists can help with the listing of skills an accomplishments, and ordered lists can help with timelines. Wrapping accomplishments in
strong elements—not spans—can call attention to important career milestones.
How to prioritize it
First, you’ll want to use heading elements to structure your content in a way that makes sense hierarchically. For a common résumé format, it’d be something like.
h3Job title and company
This structure clearly communicates:
- Who you are
- How I can contact you
- What you’re looking for
- What you’ve done previously
- How you did it
- Who taught you
Since this helps me quickly and clearly understand you as a candidate, I can easily dip into those third level headings to really dig into the nitty-gritty.
How to section it
You’ll also want to use HTML’s landmark elements to divide up your content. Use the
header element for your name and summary, the
main element to describe your skills, work history, education, etc. The
aside element can house your contact information, since it’s only pertinent if the person reviewing your résumé likes what they’re reading.
Why should I care?
In addition to making the document easier to scan through in code, it helps people who use specialized technology to help them sift through applicant’s résumés. Some of this technology might be assistive technology such as a screen reader, but it could be any number of other things.
Hoppers, scrapers, translators, and other automated solutions are commonplace tools for many HR departments. Semantic HTML is interoperable HTML. It can maintain meaning when translated to another medium—say some choice information copy and pasted into an email sent to a decision-maker.
Need a little more convincing? Outlook uses Microsoft Word to render email. Making your content simple and straightforward will do wonders when something that absurd, yet so important is in play.
The point is, you don’t know how someone will be interacting with your résumé, or what they’ll be doing with it, so you want to make sure it is as robust as possible when putting it out for the world to see.
Make it portable
Inline as much as possible into your document’s
Normally this is bad advice. However, when everything is self-contained in a single file, that file becomes incredibly fault-tolerant, cacheable, and compact. It can be saved locally and passed around confidently, with almost no failure points.
As résumés are mostly text and really shouldn’t have much in the way of interactivity, there’s also a good chance you can get the whole thing to render within the first round trip.
Make it printer-friendly
This one is easy. Webpages can, and will be printed. CSS can style printed pages. CSS supports absolute measurement units. When that HR manager inevitably prints your résumé to show someone, make sure it shows up looking good.
Make it machine-friendly
In addition to semantic markup, you can enhance your document with Schema.org microdata.
When scraping and search services such as Google index a website, they use complicated code to “best guess” what the website is about.
By using microdata, you are able to speak directly to this code and say, “This is what this content means.” Removing this ambiguity means showing up for relevant searches becomes that much easier for all involved.
Schema.org has a way to programmatically describe yourself. It also has a way to communicate organizations, events, and products. I don’t know about you, but those all seem to me like things you’d commonly find on résumés.
Make it responsive
You want your résumé to look good on a device the same way you want it to look good when printed. Since you can’t know the circumstances where it’ll be viewed, make sure you start with a mobile-first mindset and test how it looks on a variety of screen sizes.
It’s easy to imagine a scenario where an overworked hiring manager is reviewing your résumé on their phone over a lunch break. It’s also not too far a stretch to envision a scenario where it’s loaded onto a large conference room TV to discuss.
Make it performant
On a less powerful device, say a locked down, provisioned, bulk-ordered budget company Dell laptop still running Internet Explorer, this privilege may not exist. Do you want your résumé to be the thing that crashes a prospective employer’s browser?
Consider what React and other SPA frameworks are good for: stateful, extensible, component-driven applications. Now consider what a résumé’s goals are.
Not every problem requires a hammer. Part of being a good developer is being able to pick the right tool for the job. Being able to weigh a technology’s strengths against its weaknesses, and articulate them, are incredibly valuable skills.
While React and its ilk definitely are capable of performing much of what I discussed, it is not what they are focused on. As such, the time you’d spend on these considerations needs to compete with the time you’ll need to invest to setting up and working in your framework of choice.
Just because the job market is demanding a certain buzzword doesn’t mean you can’t be critical of its faults and limitations. It also doesn’t mean that buzzword will be in favor forever—today’s React might become yesterday’s Gopher.
Résumés are all about making yourself seem attractive to a potential employer, demonstrating what skills and abilities you can offer their organization. All the enhancements described above signal depth of knowledge and consideration of circumstance, which goes a long way to standing out and getting that first interview lined up.