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.
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.
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.
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.
There are a couple of very popular libraries, one of which you might expect to hear mentioned from a candidate:
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.
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.
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:
The only bad answers would be things like "nothing", and "what is state"?
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.