My cofounder and I are looking to bring on a junior developer to help expand a product offering that we haven’t expanded since we had someone build the MVP. The only problem is there are a lot of available developers on freelance sites and we don’t trust the reviews. We know quite a few people who have had quality issues on these sites. Is there a common coding test that we can administer to make sure our candidates are quality developers?
Two words: trial period.
If he/she is really junior, he/she probably won't have a portfolio you can look at, so that's really the only way.
Some people may have their own projects though, even if they are young (I sold my first software at 15), so you can look at those.
Hiring a freelancer when you're not an expert comes down to being lucky - and the odds are not in your favor.
Lots of companies that provide this service - hire one of them.
Keep in mind that junior is synonymous with inexperienced. A junior will need a lot of oversight to deliver quality.
Can you interview in person? A simple test, similar in complexity to Fizzbuzz, is a good gatekeeper; if they can't pseudocode that in person, show them the door.
Can you get recommendations from people you trust?
Check references. Then verify that the person giving the reference is the person is who they claim to be by contacting them through other means (e.g., through the company they work for). That way they can't fake references.
The original developer(s) isn't available any more? I usually suggest starting there. I like the sound of Gabor's trial period or even better, pick a small feature you want to add and do a trial project for just that feature with one or more developers who provide a fixed price for that feature and then pay them all and take the one that provided the best communication and relationship along with the product (feature) requested.
There's also a good book out there by a friend of mine.
The questions should be able to be answered in one or two short paragraphs and should start from easy to hard. Some of the questions are open-ended like, "React is relatively new. What are the strengths and weaknesses of React today and what do you do to mitigate its shortcomings?" These questions are not meant to be brain teasers; they are designed to demonstrate competence.
I ask them to return their answers in 48 hours, and if they have any questions, please place a comment in the Google Doc, and I will respond quickly. I also remind them I'm looking for one or two paragraph responses, not essays.
Here is what I found: the excellent candidates answer most of the questions quickly, and a number ask clarifying questions. They may spend more time on the last few, harder questions where they revise their answers until they are comfortable. Short paragraph responses can demonstrate to our team how they think and approach problems.
For many engineers, English is not their native language, but they are superb at expressing themselves in written form where they are less self-conscious. Written communication is particularly important for us because Slack/Jira/Github as our primary tools and if they write well in English, then communication can be a very effective.
Yep, there are many coders who consider themselves as ninjas in web development even in the beginning of a career, but when you see their code standards, the only thought "Oh, horror : )
Richard Giraud is quite right regarding small experience of the juniors.
If you're interested, I can help you with searching a good coder.