A guide to hiring an ECMAScript 6 developer
ECMAScript is the standard behind JavaScript. ECMAScript 6, known as ES6 or ES2015, was the update that gave the language classes, modules, promises, arrow functions and many smaller tools. Nearly all modern JavaScript is built on it. This guide explains what an ECMAScript 6 developer does, when you need one and how to choose well. It helps founders, product owners and engineering leads who have JavaScript code that is hard to read or hard to change.
What an ECMAScript 6 developer is responsible for
This developer writes and maintains JavaScript using the features of the modern language. On a new project, they set the style of the code: how files are split, how data moves and how errors are handled. On an old project, they read what exists, add tests and bring it up to date in small steps. They also look after the tools around the code, such as the compiler, the bundler and the linter that checks style.
Why the language itself matters
Two programs can do the same job and still be very different to work on. One may use long chains of callbacks, global variables and copied code. The other may use modules, promises and clear names. The second is quicker to change and easier to hand over. A developer who knows ES6 well saves time for everyone who touches the code later. This is a skill about craft and care more than about any single library.
How this role differs from nearby roles
A JavaScript developer covers the browser, the server and often TypeScript, so that page is the wider choice. A React developer or an Angular developer builds on one framework. A Node.js developer works on the server. The ECMAScript 6 page fits best when your question is about the language and the health of the code, such as a codebase with old patterns that you want to bring up to date.
When an ECMAScript 6 developer makes sense
- Your code was written years ago with var, long callbacks and global variables.
- New developers struggle to read or change the existing scripts.
- You want to start using modules, classes or async functions without breaking what works.
- Your build is slow, fragile or hard for anyone but one person to run.
- You need someone to set a clear code style for a growing team.
If your main need is a new product built on a framework, a framework developer may be a closer fit.
What to look for in a background
Ask for examples of code that real users depended on. Good candidates describe an upgrade they led, how they kept the product running and how they proved nothing broke. Treat a long list of buzzwords with caution. Ask the person to open a small piece of old code and explain, line by line, how they would rewrite it and what they would leave alone.
Interview questions to try
- What is the difference between var, let and const, and which do you use by default?
- Explain what this means inside an arrow function and inside a normal function.
- How would you turn a function with three nested callbacks into an async function?
- What happens when one promise in a group of promises fails?
- How do you decide which browsers a build must support?
Clear answers come with examples and simple words. Be careful with answers that sound memorised but cannot be applied to a small piece of code.
A paid trial task
Choose a short, self-contained piece of your own code, such as a file of old helper functions. Ask each finalist to upgrade it, add tests and write a few lines about what they changed and why. Pay for the time. You will see how they read, how careful they are and how clearly they explain their choices.
Match the person to the job
A fresh start needs someone who can set simple rules for the code. A long-lived product needs a patient reader who moves in small steps. A team with mixed skill levels needs a person who writes code that others can follow and who is happy to explain it. Ask each candidate which of these they have done.
Access and routine
Set the weekly hours before work begins and review them every few months. Your engineer signs in with personal accounts to the code host and test servers, while the company stays the owner of each account. Every change should come with a short note on how to reverse it. Take away access the day the work ends.
Working with the rest of your team
Explain which parts of the code the engineer owns and which parts others may still change. Agree one style guide and one linter setting so everyone writes code the same way. A weekly review of open changes keeps surprises low. Ask for a short guide to the new patterns, so people who join later can learn them quickly.
Mistakes to avoid
- Rewriting everything at once instead of upgrading in small steps.
- Changing old code with no tests in place.
- Using new syntax without checking which browsers your visitors have.
- Adding extra libraries for jobs the language already does.
Want help on the server side too? See our Node.js developers, or look at our JavaScript developers for a wider mix of skills.