Not interested in the background and want to jump into some code? Link here: https://github.com/alexgurr/react-coding-challenges
Our interview process used to look like this:
1) Initial 15 minute phone call, 'the basics'. Did the candidate research the business? Are they aligned with what we're looking for? Some basic information about their experience.
2) One hour technical interview. Questions about various bits of our tech stack, JavaScript, React, GraphQL, testing, clean code. General technical assessment.
3) Tech test/challenge. Takes anywhere from 2 - 8 hours depending on the candidate. Full stack JS - front/backend test.
4) Final interview to talk through the test/candidates code and next steps.
A month or so ago a colleague of mine suggested adding a new step in our interview process. His suggestion was to add a pair coding exercise in the early stages that was relatively short, but would help us identify if a candidate had the following qualities:
- Ability to think on the spot
- Communication skills and ability to talk through their code with others
- Logical thought processes
I introduced a coding challenge designed to be completed in 15 - 30 minutes. The scaffold of the app would be provided for you. You'd have a set of requirements and off you'd go. It was coupled with the initial 15 minute phone call.
The technical challenge? It had to be remote. We didn't want to waste anyone's time if they were the wrong fit. We ended up using VSCode and a live collaboration plugin alongside ngrok which allowed me to share my local development server to candidates over the internet.
It worked surprisingly well. The feedback I've had has been excellent and the challenge I was told, was fun. The lesson to be learned is that you can provide small, fun challenges that give some serious benefit.
I've published the challenge to GitHub. I've also added a new one to the same repo. The plan is to build more and more over time. I'm super open to feedback/suggestions/ideas! Reach out! Each one has a difficulty level, time to complete and a set of requirements.
Repo here: https://github.com/alexgurr/react-coding-challenges
If you're interested in the solutions, get access at solutions.alexgurr.com.
Like my article and want more? Come and follow me on medium.
Top comments (7)
in the dark theme exercise, how should the interviewee answer ? I've always been told that it's not best practice to alter the root html tag, so I would have started by going the "simple react way" and adding the className to another element.
Howdy! Excellent point. Directly modifying is frowned upon and in fact, directly modifying the DOM in general is considered bad practice. In saying so, I've definitely had times in my career when I've been forced to alter the class list of a top level element directly, for example, when setting a global cursor during a drag. I would say changing classnames is low impact. I might tweak this task/scss and suggest it to be applied at a lower container level (ie. render a div in the app container instead), which would probably be more representative of a real application. Not a bad idea to know how to manipulate the DOM anyway.
These tasks are not so much designed to be 'answered'. It's an opportunity for an interviewer to assess a candidates skills and their communication. I would expect my candidates to be thinking through the problem and talking through their solution.
As long as the candidate demonstrated knowledge of the problem and solution and could justify what they're doing, I wouldn't be as bothered about their final technical solution. For example, if you could justify what you just posted in relation to the HTML tag and made a decision to apply the class lower down (not at the component level) then I'd give that a tick.
Hope this answers your question!
Great answer, thank you 😀
The whole idea is really interesting, and I like the idea of watching the candidate evolving through a codebase, and communicating throughout the exercise. I might try and use that kind of test for my upcoming interviews !
We actually experimented. We tried stand-alone, but as you said, it made the process too long. We actually turned our 15 minute intro chat into a 30 minute session with the pair exercise at the end of that.
You need to choose a process that fits your company. In a small team I’ve found someone has much more impact so I personally like to be more thorough. In a bigger team it’s usually less of an issue.
Long interview processes aren’t to be a pain in developer’s butts, but to try and give us as interviewers/leaders as much opportunity to make sure they have the practical skills and are the right fit for the team. Even more of a challenge in the current time where market rates for developers has shot up to a ridiculous amount and you don’t want to take risks on people.
Thanks for sharing about this. I don't know why the need to add the pairing step in the interview process. I am sure most devs know -or they should know- that not everyone has paired at work, and some that did had horrible experiences. Thinking on the spot is great, but don't you ignore people that are nervous? Did you find that the candidates that applied didn't meet your company's standard? Thanks for answering.
Hi Gabi, I’ve only just seen this!
When I say pairing i mean more were both on a video call and looking at the code together. We’re not “pair programming” which some people might not have done. Having said that, we do pair program at Shootsta and expect our candidates to have good communication skills so they can engage in it confidently and productively.
I’m usually pretty good at telling the difference between nervousness and lack of skills/knowledge so it’s never really been an issue. Most complement interviewers are quite lenient with interview nerves. I for one, tend to treat every stage quite informally to increase candidate’s confidence. Relaxed conversation, cracking jokes etc. Part of interviewee skills is being able to control being nervous and reduce the amount it affects your interview performance. Everyone gets nervous, myself included! It’s all about practice.
In terms of applications, we get plenty that we filter out for not meeting the standard. I would say a high percentage of people who get to the first round though usually continue through the process.
Hope this helps!
Alex
Hey Alex, thanks for these. I'm looking for some guidance/solutions for these as I work my way through them. I emailed you asking for access to the private repo. Thanks in advance!