5 Super Simple React Screening Questions For Recruiters

React is definitely the most popular client side JavaScript framework I see these days in terms of job postings. But it can be hard to tell if someone has a lot of experience with it. And honestly, React can get pretty complicated to work with. When a new feature comes out in React, entire books are written about it.

I have been repeatedly asked for help with evaluation and screening questions so I am going to go over a few that are at a pretty high level.

I do think there are definitely things recruiters can ask to gauge general experience, even though when talking to technical candidates the possibility of misunderstanding might be high. Sometimes when candidates answer it might contain so much jargon it would be best to take notes and get a second opinion.

I wrote this post for recruiters and to be clear I'm not saying recruiters with a non-technical background should be doing deep technical screening. Not at all. These questions are just to help roughly gauge experience level.

But, with that said here are a couple of questions and answers you could use to start a conversation at least.

1. Why Use React?

React is a very popular client-side JavaScript framework. People like React for a lot of reasons, but here are a few good reasons why somebody would want to use React:

1. Component based architecture
2. A large community of plugins, modules, projects, and people.
3. It's under active development and has cutting edge features coming out.
4. It's flexible, moreso than Angular. You get to piece together things they way you want.
5. One-way data binding.
6. Virtual DOM.
7. They like JSX (the component language you write react components in).

A candidate should be able to intelligently talk about some of these things if they have been doing React with for any length of time.

2. Tell me about a hard problem you had to solve in React?

I almost always ask some variation of this question just to get background information and to see how good a candidate is at explaining tricky technical concepts.

When you ask this they might compare React to Angular, or jQuery or some other JavaScript library, and how they would solve a problem a different way using something else. These might be good answers, but it could be hard to evaluate unless you have some first-hand knowledge of the thing they compare React to.

The conventional wisdom with the "hard problem" question is that if a person goes into great detail they actually solved this problem, not somebody else. Also, if they keep your attention they are probably great at communicating technical concepts, which doesn't necessarily make somebody a great engineer but it does make them a great coworker on a software team.

So this question is good for a number reasons and you can change it to be "tell me about the hardest problem you had to solve on your last project" and use it for anything, again just using the clarity of their explanation as a proxy for communication skill.

3. How do you test your React code?

There are a couple of very popular libraries, one of which you might expect to hear mentioned from a candidate:

• Jest
• Enzyme
• React testing library
• Older libraries: Tape, Mocha, Chai, Sinon or Jasmine

However, anything specific they mention is fine. The only bad answers are "I never test code" or confusion or evasion. If they don't know how to test code or have never done it before this is likely an inexperienced candidate.

I was once interviewing someone and the response I got to this question was:

Testing? Uh, my shit don't break.

Needless to say, they were a hard pass.

4. How is React Different from Other JavaScript Frameworks

This is an open-ended question to get the candidate talking. If they can't make clear points about this then it means they probably are not actually very experienced in React, or they probably are not very experienced in client side JavaScript development in general.

I don't think there is much value to go into any detail here in this short blog post because you would actually have to learn quite a bit of information about other frameworks (e.g. Angular) to really evaluate this. This would be a great time to write down what the candidate says and have a technical resource evaluate it.

You should get a specific clear answer from the candidate, it's a red flag if they stumble through this basic question.

5. How have you managed state in your React applications?

This question is about how the candidate has managed the client side data in building a react application.

Here is the key takeaway: the candidate has likely not built a large React application if they cannot answer this question in a concise way.

Here is an example how I would answer this question:

I have used Redux and more recently, Apollo Link State.

Here are some libraries people use for state management:

1. Redux
2. Apollo Link State
3. Flux
4. Sagas
5. Mobx

The only bad answers would be things like "nothing", and "what is state"?

Conclusion

I hope some of these are useful in understanding how you might be able to begin to get a feel for a candidate's experience in React without having to know the technology itself backward and forward.

I think the risk of miscommunication is high when a non-technical person is evaluating a technical role so it might be good to have a technical resource on hand to get a second opinion from.

Let me know if you try any of these out, and what your favorite ways to gauge experience are when talking to technical candidates.