Look, interviewing is hard, I get it. But just like other things in our lives, it’s worth doing right. Because it’s not just about you. It’s about your future coworkers, their first impressions of you, and the work culture you want to make. As an employee, contractor, or founder you may not have control over everything, but this is one thing you can control.

Hiring React Developers is Hard

So here’s the situation a lot of us have been in a time or two - your boss gives you good news! You’re getting a new team member. Human resources just posted a job, and you’ve started getting resumes for a brand new React developer. Now what? How do you choose? What happens if you choose wrong? What happens if you mess up? The implications of hiring are huge. The next developer you hire could be the person that makes your project successful. They could also be the person who gets you or your company in trouble, or on the news in a bad way. 

Hiring is risky, so obviously we can’t pick a developer at random. You have to talk to them and test their knowledge to mitigate the risk of hiring someone that isn’t a good fit for the position.

Developers Interviewing Developers

The ironic part is, we overwhelmingly as an industry don’t apply that risk mitigation to the interviewing process itself. Developers are dropped into interviewing without a script, training, or questions to ask. We often have to improvise the whole process when adding a new team member.

I remember the first interview I conducted. It was scary! Thinking back, I can’t believe how lucky I was. Not only did my first hire turn out to be a fantastic choice for the project, but he’s still a great friend. We exchange pictures of homemade pizza frequently. In reality, he and I both were at a huge disadvantage. It was my first interview, so I did some searching on Google for questions to ask or tips on how to interview. But in the end, I had basically nothing beyond a copy of the candidate’s resume and the job description. 

He was at a disadvantage because of my inexperience at interviewing. This could have cost him a job that I only now know that he was EXTREMELY well qualified for. 

The Other Side

After 3 years of consistently interviewing 1-2 technical candidates a week, I went shopping for a new job. For the first time in years, I was on the proverbial “other side of the table.” It was truly fascinating to see my mistakes and lessons learned thrown back at me. Not just by one or two companies, but almost every one of them. 

Since I’m a JavaScript/React developer, this is most of my experience in interviewing from both perspectives. So I will frame my good, bad, and ugly rant in that context. However, these are transferable concepts and could apply to a wide variety of other job roles. 

Good React Interview Questions

When designing interview questions, the first thing you must consider is the job description. Be careful not to deviate too far from it. Next, consider the experience you’re looking for - senior, mid-level or otherwise.  But this changes once you talk to the actual candidate. You must gauge and accommodate the experience of the person you’re talking to. You have to take an educated guess at first, but as the interview progresses, you can “calibrate” the questions to the person you are talking to. 

My first example of a “good” React interview question is:

 “What are a few ways to help fix a React component that users describe as slow?” 

I personally use this question a lot. It’s fairly applicable to React developers of any skill beyond entry-level. It also strikes a balance of many possible answers, ways to show knowledge, but not overwhelming for a candidate to answer. It can tell you a lot about a developer’s areas of expertise and focus. They might talk about devtools, measurement, and profiling. Maybe also lifecycle methods, hooks, and their mentality about performance optimization. 

In my opinion, the answer should center around a measure, change, measure cycle. However, even if they don’t hit that concept, it will still provide value. It could gauge their general JavaScript experience, browser API knowledge, even CSS understanding. It can tell you about their understanding of React’s internal model (Virtual DOM and render cycle). Perhaps also some common mistakes developers make. And it can do that without resorting to asking specific questions that will make the interviewee feel uncomfortable. Overly specific questions feel like trivia and are hard to say "I don't know" to. 

The fact is, the surface area of APIs that a developer needs to know to do their job is so vast that it is impossible to know it all. So, demonstrate a combination of breadth and depth of knowledge in specific areas, and you will do well. Give your interviewee the chance to do this, and they will.

Other good questions to ask, center around the realities of working on a team and writing code together. I love to ask the following React interview questions:

“How do you go about reviewing a pull request?”

“How would you mentor a newer developer on a difficult-to-understand subject like closures?”

“What do you do when a Product Manager or client requests something seemingly impossible or unreasonable?”

These situations can and will happen, and are pretty universally applicable. 

Bad React Interview Questions

On to the bad questions. We’ve all had them, but we answered them anyway. There’s really no avoiding it. The questions that make you wonder what the interviewer was thinking. I maintain that a lot of tech interviewing is hazing, unconscious or not. So many bad interviews come from interviews being so bad for so long; We tend to repeat the questions that we heard. This stems from a lack of training, discussion, and incremental improvement. We value these concepts so much in code but forget in other aspects. 

Trick questions like “how much dirt is in a hole,” should be banned. Puzzle questions like optimizing a search algorithm might be appropriate in another field, but not here. Bad questions are questions that are not applicable to the job or don’t reflect the working environment. For example, if a developer will be working on component design, don’t ask them to invert a binary tree. Instead, ask them about how to design a component API to withstand continuous feature additions.

More bad questions show up in articles found when searching Google for “React interview questions”. Someone who is not a software engineer could memorize these answers and pass the average bad interview. All it would take is good language skills and memory. These are questions that check memorization but don't prove any level of understanding or usage. 

One example is the below question:

 “What is a hook?” 

This is asking for what is essentially a dictionary definition and isn’t very helpful. Do our customers care that we know the academic definition of what we are using? Probably not. Questions like this could lead to many false positives or false negatives. This means someone who is not qualified could pass, or someone that is qualified could fail. I know many developers that are fantastically smart that could not give a “Dan Abramov” answer to this question.

Another one might be:

“What is the difference between a function and class component?” 

While this one on the face of it seems harmless, it's really just the lesser form of a better question. This better question might be more applicable if you are hiring someone to help you refactor. For example, refactoring an antiquated codebase from React 0.14.x to React 17. The better question might be as follows. “Can you tell me about refactoring a react codebase from components to hooks? What would you do differently or recommend?”

This is better because it allows the interviewee to implicitly answer your previous bad question. But it also gives you a story about their experience. They can dive into other areas that they learned, and possibly teach you something. This is also an effective way to ask someone, “teach me something”.

Ugly React Interview Questions

Now here’s the ugly. These are questions that you should never ask.

Do not ask a React developer with a UI design focus to define Microservice Architecture for you. Especially when there is no mention of backend or full-stack on the job description. Do not ask code review style “spot the gotchas” questions. This is like asking someone “Where’s Waldo?” when they don’t know who Waldo is, and have only ever heard a vague description of him. This is not to say that some people might not be able to do it, but there are better questions to ask. 

DO NOT ASK: 

“WHAT IS YOUR GREATEST WEAKNESS?”‍

Even if you are framing it in the context of code. It’s meaningless. Does that actually have any bearing on their value to the team or company? No? I didn’t think so either. These types of questions drastically increase the chances of false negatives in testing for a position. You don’t want to recommend, or exclude, a React developer based on bad or irrelevant criteria. 

“Show me how to invert a binary tree.”

Ok, this one isn’t even a question, but like most whiteboard questions is basically pointless. I’ve been working in this field for a decade and have never once even dealt with a binary tree on the front end. This question is awful because it is famously anxiety-inducing, frustrating, or humiliating. You’re never going to get a good read of a candidate if they are sweating through their shirt out of nervousness. Even if it wasn’t anxiety-inducing, the interviewee would not have normal affordances. Affordances like an IDE set up the way they like, and unquestioned access to search engines, are important. Not having these have a very negative effect on the candidate. Again, this could lead to incorrectly losing an otherwise great candidate. 

So what is the best way to interview a React developer? What are the perfect interview questions? I can’t say for sure, as developing interviewing skills has been an iterative process that may never be complete. I can say for sure, however, that this has been best as a collaborative process. It is not something I’ve learned on my own. It is important to get together with your team and decide on hiring criteria, questions, and processes. Put together a repository of good questions to ask. Keep your interviewing script available internally. It should be editable by anyone in management, human resources, or engineering. 

We review code all the time, why not review and optimize your interview questions too?

Good luck with your next interview, no matter which side of the table you’re sitting on.