DEV Community: Barry McGee

What I learned reviewing over 300 web developer resumes

Barry McGee — Sat, 11 Jul 2020 21:07:43 +0000

We're currently hiring a remote front-end web developer for my team at Canonical, and I have spent a lot of this week reviewing over 300 applications.

As a result, I've moved 30 (~10%) of them to the next stage in our process, and I noted some reoccurring reasons why the other 90% were screened out at the first step of our hiring process.

If you're currently in the market for a new role, take these considerations on board in your next application and try not to make these same mistakes.

🧐 Did not read the basic requirements of the job spec

You must read the job spec, then re-read it again. Most job specs will have a "Must have" section and a "Nice to have" section. Requirements listed in the former are mandatory whereas those listed in the latter are optional. Failing to satisfy the first will result in you being immediately screened out by the hiring manager, if not the hiring software long before.

🌏 Did not have Right to Work

While many jobs are now listed as remote, for a myriad of unfortunate operational reasons, many companies will only accept candidates who do not need specific visas or sponsorship. Make sure you can legally work for a company under the circumstances stipulated before applying to join them.

📮 Did not provide a cover letter

If a job application provides an upload field for a cover letter, you should provide one - even if the field is optional. Covering letters are your opportunity to introduce yourself and put your skills and experience in context.

💌 Did not provide a tailored cover letter

Many of those who did provide a cover letter submitted a generic cover letter that they could send to any company. These paled in comparison to those who took the time to write a tailored letter referencing our company and more importantly, the role specifically.

🔤 Did not proofread their applications

Your cover letter and resume should be free of spelling and grammar mistakes. Simple spelling and grammar mistakes suggest sloppiness and a lack of care. It's easy to miss your own mistakes, so get someone else to proofread your application or utilise the many software options available to do this for you. Proofreading is essential if the language in which you're applying is not your native language.

🚧 Included links to incomplete or broken projects

If you're applying for a web developer role, any links to your work will be scrutinised. Do not link to your personal site if it has an "Under construction" banner or includes Lorem Ipsum placeholder text. Do not link to projects you started, then abandoned without finishing. Consider any links you put on your resume to be "in production" and ask yourself - would the company you're applying to deploy this quality of work to production under their brand? If the answer is "No", revisit and iterate until the answer is "Yes".

😑 Submitted a resume that's hard to read or understand

There seems to be a trend of using software to produce resumes that are keyword dense, so they are picked up by automated recruiting software. That's all well and good until it appears under the nose of an actual human. Remember that a hiring manager is likely reviewing a large number of resumes of which your carefully curated application is but one. First impressions count. Resumes should be kept to less than two pages as a general rule of thumb but not at the cost of readability. Your experience should be chronological with your most recent experience first. Only include your experience relevant to the role. Don't add your whole life story back to high school.

🥈 Forgot that their application is not considered in isolation

Finally, it's important to note that it's likely that not just one violation of the above will result in your application being rejection but a combination of them.

As a hiring manager scans your application, they are slowly forming an opinion of you based on the information you have provided but also by mentally comparing it to the other applications they have already viewed for the same role.

You might think it's not a big deal if you send a generic cover letter. However, when your application is viewed right after a person who spent considerable tailoring their cover letter - your generic cover letter is, relatively, a bit dull.

In short, take your time and take care to craft each application. You've got this. 👊🏻

.
.
.

(Photo credit: Charles Deluvio - Unsplash)

Get that Pull Request merged - today.

Barry McGee — Fri, 03 May 2019 20:39:11 +0000

You've done the hard yards, that new feature or bug fix now works just as you'd like - now all that is left is to submit your Pull Request, get it landed and everyone is in profit, right?

Not so fast.

It's two, three, four days later and you're still battling to land that Pull Request (PR) as you deal with suggestions to refactor your code, Quality Assurance (QA) bugs and merge conflicts. 😭

The feeling of accomplishment you had initially when proposing your change is now a feeling of resentment as you're forced to revisit your code again and again. 🤬

So, how can we avoid this scenario and ensure that your Pull Requests are landed quicker and with less hassle?

Limit the scope of your change

You should always try to keep your pull requests as small as possible. Focus on fixing or adding one thing at a time. The more changes you include in a PR, the higher the risk that you introduce bugs.
Avoid drive-bys

A drive-by is a change or refactor you make while browsing through the code and you notice something obvious that should be changed. It might be as simple as a missing alt\ tag on an image or updating the indentation of a code block. By all means, make these changes, but propose them separately.
Rebase before proposing your changes

Rebasing your changes on top of the branch you're proposing your changes to will reduce the chance of merge conflicts and also mean you're proposing your changes against the codebase as it exists in that moment, not as it was when you created your feature branch.
Make sure you run the tests locally

If the project has a test suite, which hopefully it has, be sure to run those tests locally before proposing your changes. This should help highlight errors or linting issues in your changes.
Siphon off non-blocking issues

Often when a person is reviewing your code, they will offer suggestions that are very valid but not strictly show-stoppers for the change you're proposing. These might be UI improvements, code abstractions or refactors to existing features. In my opinion, so long as your change does not exacerbate an existing issue, these recommendations should be syphoned off as separate issues to be prioritised accordingly.

Incorporating the above steps into my own work has really increased the cadence at which I get my PRs merged. Hopefully, it might help you too. 🔥

Visualising scroll position in your Gatsby site

Barry McGee — Fri, 15 Mar 2019 22:15:32 +0000

At the start of this year, I rebuilt my blog using Gatsby.

One of the stand-out features which set Gatsby apart from the rest as a static site generator is the plugin eco-system. Why re-invent the wheel if someone else has already designed a perfectly good wheel?

The beauty of web development is the ease in which we can easily peer over the shoulder of someone else, who may well be on the other side of the world, and quickly learn from them.

Working within a well-designed plugin eco-system, we can not only learn from other developers but also turbo-charge our own development by quickly adopting their work and adding it to our own projects to make something that is hopefully more than the sum of its parts.

I'm an impatient person by nature. Have you been stuck on a train or plane with no idea when you'll be moving again? Isn't it utterly infuriating? Others seem to agree.

Whenever there is any major transport disruption event, you'll notice that the first thing a frazzled interviewee on the evening news will complain about is typically not the cause of the disruption but the lack of information provided around it.

A little information goes a long, long way.

You'll notice as you scroll down a post on my blog, your progress is being tracked along the top of the screen from left to right.

This gives you an immediate visual indicator of how long you have left on your journey to the end of this page.

In our time-starved digital world, it's my theory that this little indicator makes it more likely you'll continue reading all the way to the bottom (the quality of my writing notwithstanding.)

I developed this little feature on my blog and saw that it was good. I then bundled it up as a Gatsby plugin for others to pick up and use in their own Gatsby sites.

To add it to your own Gatsby site, install using npm;

npm install --save gatsby-plugin-scroll-indicator

...or Yarn...

yarn add gatsby-plugin-scroll-indicator

...and then add the plugin reference and config options to your gatsby-config.js file:

plugins: [
  {
    resolve: `gatsby-plugin-scroll-indicator`,
    options: {
      // Configure your indicator bar color here
      color: '#BADA55',
    },
  },
];

Restart all the things, clear all the caches and you should now have a visual scroll indicator on your site too. 💥

Source code: Github

Making remote work, work.

Barry McGee — Mon, 18 Feb 2019 16:35:42 +0000

I have been working remotely from home full-time for the past two years, and I love it.

Previous to this, I had always worked in an office environment, and now I wonder if I could ever go back to working an office full-time again.

I simply love the freedom working from home brings - be that the freedom from a daily commute sitting in traffic or the freedom to roam around my favourite coffee haunts with just my laptop on my back and my phone in my pocket (for tethering if WiFi is patchy).

Friends and family will often say to me when this topic comes up; "Oh, I could never do that, I'd get distracted too easily." The alternate view sometimes offered is; "I could never do that, I'd still be answering emails at 12 o'clock at night."

People seem to worry that they'd never be able to start working or they'd conversely never be able to stop working. Others would love to work remotely but feel they don't have the culture within their work environment to support it.

Everyone is, of course, different and your mileage may vary but here are some tips I've found help me.

Establish and nurture trust

When working remotely, trust is crucial.

That is to say, your customers, clients or manager must trust that you'll consistently fulfil or exceed any expectations placed upon you.

Problems will inevitably arise if you start to fall short without a good explanation as those who have placed their trust in you will start to wonder how you're filling your day.

Create your ideal workspace

A considerable advantage remote workers have over our office-dwelling colleagues is the ability to control our work environment.

I have a home office which I've gradually crafted to suit my needs perfectly.

Picking out my ideal desk, chair, screen and wall-art makes sitting down to work every morning a pleasure.

Having a separate room in the house for this also helps me create a divide between work-life and life-life.

Eliminate distractions

Distractions are everywhere. Nearly all of us carry a shiny, beeping, vibrating unrelenting distraction device on our person everywhere we go.

You need to eliminate distractions both in your physical environment but also in your virtual environment.

In the physical environment, if, for example, you have other family members at home while you work, you may need to agree with them not to disturb you when your office door is closed.

Virtually, certain tools and techniques to help this. Some steps I have taken include;

Disabling the red notification indicator on all chat icons
I've installed a Gmail app called Adios which will hold back my emails and only deliver them in batches, three times a day - 9am, 1pm and 5pm.
Turning the sound and vibration on my phone off and placing it face down on the desk.
Disabling the majority of my iPhone apps from pushing notifications.
Muting all Whatsapp groups for 1 year
I use a website blocker on a schedule. A myriad of distracting websites are blocked between 9am-1pm and 2pm-6pm.

Create a routine

One of the temptations of remote working is to upend the traditional nine-to-five and work unconventional hours. You can do this if it suits your team, but I find it's essential to maintain a routine.

A routine creates structure and consistency, both of which are conducive to productivity.

This will not only give you a strong indicator of when to start working and also a strong indicator of when to stop.

Exercise

One of the more dismaying aspects of working from home is the realisation of how little you move in the course of the day when your desk is mere metres from your bed.

When I was previously commuting to the office while living in London, I was regularly clocking up about 12,000 steps a day.

However, once I moved back to Belfast and started working from home, that plummeted to about 3000 steps a day. It's therefore very important to inject some regular exercise into your day.

One thing I've found that has really helped to regularly get me out and about, and which was only really possible because I now work from home, is acquiring a canine companion - in my case, Murphy, an energetic cocker spaniel.

No matter how deep you are in a tunnel of code, a young pup will let you know he has needs too and a brisk walk in fresh air is infinitely preferable to mopping up a mess on the kitchen floor. 😫

Communication

When you're not visible in an office every day you need to find other ways to make yourself visible. you may even need to over-compensate a little bit. This may be daily status reports, piping up a bit more in team chat channels or taking on tasks not strictly in your remit but help remind others of your value to the team. Helping to clear a backlog of Pull Requests is a good example of this. You should also be mindful that if you're deep in the trenches of the particular task and but making any visible progress to your wider team, you should flag that up. You know you're working hard and making incremental progress but no-one else does unless you tell them.

In conclusion

Trust, discipline and communication are key to making remote work, work in my opinion. But, once you get it right, it's magic. 👌🏻

Formatting your code with Prettier

Barry McGee — Mon, 18 Feb 2019 14:17:58 +0000

For many years, I've spent a considerable amount of time squinting at my code editor and trying to decide if the curly brackets at the top of my screen align with the curly brackets at the bottom of my screen.

The reason for this is to make sure my code is tidy and consistent and thus easier to maintain - either by myself at a later date or by someone else.

I'm also tidy by nature - clutter stresses me out. I like a tidy desk, a tidy house, a tidy car and a tidy garden. There is a place for everything and everything should be in its place. If it doesn't give me joy - it goes in the bin!

Lint all the things

As front-end development matured rapidly in the early part of this decade, linters became more and more popular. We had JShint which evolved into Eslint for Javascript and Scsslint, latterly superseded by Sasslint, for Sass files.

HTML linters also came and went but the community never seemed to coalesce around one solution. This may be partly because HTML is rarely written in isolated .html files these days - it is typically moulded around template tags of various flavours to enable dynamic population of content.

So, this was great - up to a point. As these linters tried to be all things to all men, they shipped with a seemingly infinite array of config options. The advantage of this was you could persuade your linter to check your code to ensure it's was exactly as you'd check it yourself. This disadvantage of having a wide array of config options is each project could be set up very differently, even within small teams. This invariably meant that, despite best efforts, you would break your build when submitting a Pull Request by tripping the linter. Cue a git log littered with "Fix the linter" commit messages.

Many of these linters also mixed stylistic issues with code validity issues. Eslint, for example, can be configured to flag up incorrect indentation (stylistic issue) and also flag up duplicate const declarations (validity issue).

As a result, running Eslint over a codebase with the --fix option will not only format your code but possibly rewrite it. While this an excellent test of your confidence in your test suite, this is also an exercise of exponential risk.

A prettier alternative

Enter Prettier. By their own definition, Prettier is "an opinionated code formatter" with support for a wide range of languages including HTML, CSS, JS, JSX, Yaml and even HTML. Unlike Eslint, it is unconcerned with the validity of code, only the formatting. It integrates with most editors and can be triggered on file save which to me, is like a little magic fairy jumping in and cleaning up my code!

Prettier can work in conjunction with Eslint, it has the ability to ignore code blocks or entire files you want to preserve and can be set up to run as a pre-commit hook or build step.

Despite being a relative newcomer, Prettier has already been adopted by a wide range of popular code repositories and can already count Facebook, Paypal and Webpack among it's consumers. Prettier was built by core contributors to React and React Native so unsurprisingly, it's highly recommended by those teams also.

Central to Prettier's mission statement is the relatively few config options it offers. Prettier is heavily opinionated for a reason - you and your team should stop debating relatively trivial aspects of code formatting and concentrate on shipping value to your users.

That said, they have offered a few options such as tabs width to prevent landing on either side of very polarising formatting choices becoming a show stopper to adoption by strongly opinionated teams.

Adopting Prettier will introduce consistency across your codebases making it easier to onboard new developers, remove formatting lint errors from your life and ensure you never have to debate trivial code formatting opinions - what's not to like?

Dealing with rejection

Ok, so there are some things people won't like. After being convinced of the magic of Prettier, I pushed hard to have it adopted by our development teams at Canonical and quite a few developers were initially sceptical as for some, Prettier can be a little too opinionated.

The one solid piece of advice I'll impart for advocating Prettier is to run Prettier over your codebase and push it up as a draft pull request. This will ensure your fellow team members are discussing the actual impact on your codebase over the theoretical impact on your codebase, which can be wildly different.

After making my initial case, a lot of feedback I received from fellow developers pointed to a particular block of code and expressed an opinion on how running Prettier over it made it uglier, not prettier.

In some cases, I couldn't disagree but in other cases, I personally preferred the code after Prettier had formatted it. And therein lies the rub - beauty is in the eye of the beholder.

The prettiness of code is entirely subjective which is why formatting debates can be so divisive to start with. The power of Prettier is not that it can make all code pretty to all people - it's that it removes the opportunity to debate such subjective opinions and allows you and your team to channel your energy into more important matters.

You can also forget about squinting at curly braces morning, noon and night. ✨