How to hire a JavaScript developer

That Javascript, it’s so hot right now.

Time to hire a JavaScript developer? Honestly, that’s probably a good idea. JavaScript doesn’t just run on the front end, but has become a powerhouse for creating full-featured and full-functioning web applications. Users expect snappy, responsive sites and intuitive interfaces. If it’s on the web, JavaScript is there.

Whether you’re trying to find a front-end designer type, a full-stack generalist, or a node.js back-end engineer, I’ll cover some high-level tips that will help in your selection process.

Before the JavaScript: What do you want?

The first (and hopefully obvious) thing to consider before hiring a JavaScript developer is what you want to accomplish with this project. In a time where everyone has an idea for an app, it helps to be specific about what the app does or at least the reason for the work being done. This doesn’t mean you have to completely spec out the technical details, but the more information you put into what you are trying to do, the easier it will be for someone to put that into code. The more you hash out internally, the less time you will have to spend explaining to a developer what you want and the less money you waste on unnecessary process.

For example, instead of simply expressing “I want a menu bar” you might say “I want a dark colored menu bar at the top of the page with dropdown elements on the rightmost side.” The things that you might think are obvious might not be so transparent to someone coming to the project with fresh eyes.

The many faces of a Javascript developer

Once you have the idea and the project sketched out in detail, it’s time to start considering which type of Javascript developer you need. There are a ton of frameworks and libraries out there, so I’ll cover important themes with examples rather than deep dive into the technical details.

Hire a front-end Javascript developer if:

If you already have a back-end engineer, then you probably don’t need someone to write the business logic. A simple website with a basic contact form is completely in the realm of a front-end developer with only a small amount of experience. The work done in Javascript will be limited to polish, and responsiveness. They should at least know the JQuery library. (People that specialize in this are often called web designers, though the definitions have become very blurred.)

A fully interactive user interface will require more experience. You’ll likely want to go with a Javascript framework. Generally speaking, the primary thing to consider is not one’s experience within a single framework, but the understanding of what problems each framework solves. If you see that someone has extensive experience in Angular, they will be able to pick up something like React or Ember.js fairly quickly.

Most of the time, you can first look for specific experience in a framework. Know that it isn’t a disqualifier as long as they know a similar framework. The contradiction is in the case that speed is your primary focus. If you need to get something done rapidly, hire for very specific framework experience to cut out the learning time. A front-end developer should understand user experience, design, and should be assumed to know html and css on top of Javascript. They should make things look good, and should be able to convert mock-ups to working interfaces.

Hire a back-end Javascript developer if:

If you have someone to build the front-face of your app, then you are looking to a Node.js developer to build the backend. This experience is harder to measure in demos, because the most impressive technical feats are invisible. This kind of specialist will surely know another server side language. If they have already built apps with Node.js, great.

A back-end person is going to be responsible for any functionality that runs on the server. They will need to be familiar with databases as well. This will be either some kind of SQL database or MongoDB. (There are other schema-less databases, but mongo is the most common.) They will be able to connect data to the front end. A back-end engineer is great for writing APIs. They should understand the strengths and weaknesses of Node.js. If starting from nothing, they should be able to choose a database based on the project requirements. Don’t ask them to draw you anything or design the look of the site.

When to look for full stack Javascript Programmers for hire

An app built from scratch will require understanding of how data is going to be stored and moved on top of pure Javascript knowledge. It will also require pretty strong front-end chops. A full-stack engineer should have a breadth of experience. This will include either knowledge of Meteor.js, or a stack that uses Node.js on its own supplemented by frameworks. Most common of these is the MEAN stack (MongoDB, Express.js, Angular.js, Node.js).

This person really needs to be able to handle any part of the application, and their experience should reflect that. Projects completed with Javascript frameworks are primary indicators of capability. Projects completed in other full-stack frameworks such as Ruby on Rails or Django are also good indicators that someone knows their way around web apps.

A full-stack developer is the most versatile, but not necessarily an expert in any one part of the stack. Perfect for prototyping, great for building apps from start to finish, but it would be unwise to hire a generalist full-stack developer for pure database architecture or for very specific design requirements.

Communication is Key!

The most common bottleneck to a project is not an ineffective developer, but a lack of communication.

Current tech culture would have you believe that an amazing developer can take the idea that you scribbled on the back of a napkin with ketchup and come back in week with the exact thing that you imagined perfectly tested and ready to scale to 10 billion people. This is a lie. There are amazing developers. They can build exactly what you ask them to build, but only what you ask them to. If they’re good, it will be ready to ship and can scale pretty well.

The thing in your head will not end up in the world exactly as you imagine it unless you can make it by yourself completely while predicting how the user will use it. You will have to communicate that to someone who understands it enough to make it.

For this reason, the most crucial part of hiring anyone (and especially one who must translate a set of ideas and drawings into a functioning tool) is that you can get what you want into their head. Communicating what you want is largely in your court, but finding that person who can grok things quickly can make a project go from frustrating-to-the-point-of-insanity to that-feeling-of-spreading-soft-butter-on-bread (ahhhh yiss).

I’ve seen many litmus tests for technical talent, but not much in the way of technical communication. The best way to test for an ability to communicate is to ask people to reiterate instructions. This often seems silly, which is maybe why people don’t do this simple test, but it is worth the time.

Another test is to ask questions on the edge of your knowledge with a focus on understanding rather than vetting. Maybe you know a little bit about JavaScript. In that case, try asking about some more complicated JavaScript specific ideas like closures or how the object model works.

If you know absolutely nothing about programming, ask something that you’ve heard about but don’t understand. If you can’t think of anything to ask, inquire about what new thing in JavaScript seems exciting. If you find that it’s easy to learn things from the person that you are asking, they are probably good at understanding and communicating abstractions.

How to vet and hire a JavaScript Developer if you’re not one

Okay, this is probably what you were hoping for to begin with. At this point, being specific in what you want helps immeasurably. The question is, “how can I tell if someone is good at JavaScript when I am not?” You could use a service with the toughest vetting in the industry to find, vet, and hire JavaScript developers for you. But if you’re a lone wolf here, the first step is to try to find projects that the applicant has completed that are similar to yours. If they haven’t sent you anything to look at, ask them to do so.

Portfolio

These days, there is not necessarily a need for a static portfolio or personal website. A set of links is usually more than enough to get an idea for what people have worked on in the past. The portfolio is a great weeder to determine if pursuing more conversation with a person is valuable.

Live projects or demos are best. Look at what kind of functionality each of them has. Click around and get a feel for the style. If you like the projects overall, ask what features the applicant has built. This will give you an idea of what they are capable of.

For example, if one is built in a framework you want to work in, ask if this person created the app or started working on existing code. This is the most important factor in determining the technical skill of the person: if they can build what you want. If they have a set of projects that have parts of the functionality that you are looking to build, then they can probably build yours. It is really important to get a very clear idea of what features they are solely responsible for. People who have solved specific problems will be able to answer in pretty granular detail.

Github

Github is the go-to for most projects. If you are building anything more robust than a basic website, you should be (or get) familiar with it.

You want to look at the projects that they have worked on by checking out the repositories that they have created or forked. If you are not already familiar with the organization of different kinds of JavaScript apps, it might be hard to figure out the file structure. At the very least you can look at their most recent commits and pull requests at the bottom of their profile page.

Inside of any given repository, you can see what languages are used by clicking the thin, colorful bar at the top. (hint: look for a lot of projects that have javascript.) You can also look at the commit logs to see what parts they have written. See if they have actually made changes to code in their commits.

If they have made meaningful contributions to open source projects, then they are golden. These projects are also a great discussion point. If they don’t have a Github ask them why and if there is another place where they push commits (like bitbucket). Something to note is that you won’t be able to see their commits to private repos. Their public profile might under represent their contributions.

Talent over trivia

If an applicant seems to have a strong grasp on the language and a lot of general experience, don’t fret if they haven’t done too much in the specific framework you want to use. People that have a deep understanding of the problems and patterns that show up in a variety of frameworks will be able to adapt to how a specific one handles them.

The projects that they have completed and how well you can communicate with them should dictate whether or not they get the gig. Good luck!