DEV Community

Cover image for React coding challenges - what & why

React coding challenges - what & why

alexgurr profile image Alex Gurr Updated on ・2 min read

Not interested in the background and want to jump into some code? Link here:

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:

If you're interested in the solutions, get access at

Discussion (6)

nans profile image
Nans Dumortier

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.

alexgurr profile image
Alex Gurr Author • Edited

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!

nans profile image
Nans Dumortier

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 !

gabriela profile image

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.

alexgurr profile image
Alex Gurr Author • Edited

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!


rakanshaker profile image
Rakan Shaker

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!

Forem Open with the Forem app