- Andrew Stratu
completed "Advanced SVG Animation" course on FrontEndMasters.com
attended SmashingConf in Barcelona with 15 other X-Teamers.
read "SurviveJS - React", a top resource on mastering React.
Hire developers who are motivated to always be growing and moving forward.
It’s the 21st century and web users expect full-featured, responsive web applications with intuitive interfaces.
Generally, great products are made of good code and good code is written by good developers.
So, one sure way to create a great product is to hire a good developer.
However, identifying a good developer amongst a pool of job applicants can be taxing.
Good coding relies on more than just the knowledge of a language syntax. You need someone who can turn your wildest dreams into reality, bring new ideas to the table and create stuff people love.
How can you tell this about a stranger by spending 20-30 minutes with them in a conference room or on Skype?
This helps you judge their abilities.
Here’s a quick way to explore:
Based on the answer, ask a slightly more detailed one, and continue digging in until you reach the candidate’s limit.
Nevertheless, if an applicant has good general experience beyond JS, that’s even better.
Here, you should look to see if:
They get the method signature right
Their algorithm is reasonable
They can explain its workings
They can give some pointers for improvement
They can find common line-break issues and so on.
But when doing this, be careful. The task shouldn’t necessarily be about solving some puzzles or problems.
It’s better to judge using functional code as opposed to abstract modular puzzles with no connection to the actual job in question.
The task should be simple, but practicable in relation to the job.
Whatever it is, don’t ask the candidate to write a code on paper or whiteboard.
The traditional whiteboard coding exercise is a poor indicator of actual coding prowess and a terrible strategy for recruiting devs.
People don’t write code on paper or whiteboard, they do it with computers using macros, context-sensitive help, auto-completion, and indexed API documentation.
If you think it’ll take time for candidates to create something during the interview, then it might make sense to ask them to do so before the interview and bring the code on a notebook PC.
But even then, do not rely totally on the code example. Instead, follow point #4 below to boot.
Most applicants will come prepared for point #3 above—performing a quick task.
And if you base your final judgment on how awesome they were at that, you might end up hiring an incompetent developer.
So before or after the interview, take a few moments to look into the candidate’s code portfolio. It could be open-source or hobby projects.
Review and discuss the design, coding style, and decisions that went into it.
If you like the projects, ask the specific features and functionalities the applicant created.
For example, did the person create the product from scratch or started working on existing code?
Looking at actual code tells you much more than having candidates write rushed-over, contrived five-liners they already crammed.
It tells if someone is good realistically, and not just at the interview.
To wrap up, here are a few hints to help you even more:
Developers aren’t all the same. A reasonable question depends on the candidate’s expertness.
Discourse is important. So, find a way to engage a conversation.
Finally, the developer’s personality is just as important as their professionalism, because one bad dude can destroy an entire team forever.
Join the 20,000 developers who subscribe to our newsletter.