This is a brief summary of best practices to adopt when testing a developer's skills.

The general idea

Tests should be as similar as possible to real-work activity.

Have the developer work on real issues with a member of your team is preferable to timed questions and quizzes.

It's likely that, if you use the tests listed below as to avoid, you actually get a bad developer or one who has never actually written code.

Tests to prefer

Fix a bug

The candidate works with a team member to find and fix a bug. The candidate will be conducting the activity.

Pair programming

The candidate works on an issue or function to implement with a team member.

Ask for input

A team member talks with the candidate about an actual problem the team has and asks for input about it.

Questions about experiences

Ask the candidate technical details about an experience on their CV.

Project assignment

The candidate is assigned a small project lasting 1-2 days. It has to be something you find in a real working situation. It may be the implementation of a React component that can be used in a real project. Candidates work on their own.

Long project assignment

The project in this case takes a week to be completed. It's paid work. The project will implement a function that will be actually used for development or even in production.

Review GitHub account

A team member reviews the candidate's GitHub account and talks with the candidate about the code she finds there.

Articles

A team member reviews articles the candidate has written. They can be topic of conversation as well.

Tests to avoid

Timed questions

The candidate has to answer theoretical questions about languages.

No actual developer answers theoretical questions when doing actual work.

Timed writing of small pieces of code

There is a small function to write and you have to remember instruction syntax by heart.

You don't do this when actually working.

You use tools that fetch syntax for you so that you don't have to remember it and can concentrate on making the solution work.

When actually working the most important activity you perform is not to quickly write a function, but to evaluate many solutions to find the one that is easier to maintain and less likely to cause problems later.

You are unprofessional if you stress your mind to remember syntax instead of using the many tools available that remember syntax for you.

Quizzes

These are quizzes about theoretical aspects of a language.

These are of no use when doing actual work.

Whiteboard coding

You have the candidate write code on a whiteboard whilst answering questions.

Nobody writes code on a whiteboard when actually working.

Puzzles

You have to solve puzzles that have nothing to do with software development.

You never do this when writing software.

Algorithms

You have to write an algorithm you could find in a standard library like a quick search algorithm.

You never do this when building a real application. You fetch a ready-to-use library.

Your job is to evaluate the library to see if it's easy to use, how many bugs it carries, if it's supported and popular.

You would be considered unprofessional if you wanted to reinvent the wheel every time you need a well-known algorithm.