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.
The first (and hopefully obvious) thing to consider 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.
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.
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.
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.
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 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.
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.
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!