A React job interview — recruiter perspective.

Image for post
Image for post
Photo by rawpixel via unsplash

Important
This article is not a list of questions to expect on an interview and complete answers to them. The point of this post is to show what questions I ask, what I’m looking for in an answer and why there are no bad answers.
If you want a list of “best react interview questions 2018” check out https://github.com/sudheerj/reactjs-interview-questions

Part of my job is performing the so called “technical interviews” during which I evaluate potential candidates that are applying for a “Frontend Developer with React” position.

If you’ve ever Googled “react interview questions” (or any other “[tech] interview questions”) you’ve probably seen countless results of “top 10 react interview questions” which are either outdated or rehash the same “what’s the difference between state and props” or “what’s virtual dom” questions.

Knowing answers to those questions should not be the basis on which the interviewer decides to hire or not. That’s something a candidate needs to know, understand and implement in his daily work. If you’re a candidate being asked those questions either the person interviewing you has no tech background (a HR person or “linkedin headhunter”) or they see this as a formality.

The interview should not be a waste of time. It should give you an idea about the candidate past experience, past knowledge and development opportunities. The candidate should learn about your organisation and project (if possible) and get feedback on his performance vs. your expectations. There should be no bad answers in a job interview (unless the questions is strictly technical) — an answer should give you an insight into the person thought process.

The article is written from the perspective of the person conducting the interview!

Let’s get to know each other

Can you tell me a bit about your previous job, how did you fit in the team? What were your responsibilities?

What’s the main selling point of React to you. Why did you chose to go with React?

Was it because of the “easy to learn, hard to master” API (which is quite small when you compare it to other solutions)? Good — say that, it means you’re willing to learn new things, and learn them as you go.

Was it because of the “job opportunities”? Good — you’re a person that can adapt to the market and will have no issues moving on in 5 years when The Next Big Framework comes. We have enough of jQuery developers already.

Think of this a bit like an “elevator pitch” scenario (you are in an elevator with your boss and need to convince him to use new technology before they get out on his 20th floor). I wan’t to know you know what React has to offer that can benefit the client and you, the developer.

Let’s start to get a bit more technical

What is JSX and how come we can write it in our JavaScript code — how do the browser recognize it?

Why do I ask this question? I want to know if you understand the technical side of JSX and all the limitations that come from it: why do we need to import React from 'react' on the top of the file even if we don’t use React in our code; why can’t the component directly return multiple elements.

Bonus question: why do the Component names in JSX start with capital letter?
Answering that this is how React knows to render a Component, and not a HTML Element should be good enough.

Bonus points: there are exceptions to that rule. E.g. assigning a component to this.component and then doing <this.component /> will work.

What are the main 2 types of components you can declare in React, and when would you use one over another.

A proper answer should mention life cycle methods and component state.

Since we mentioned life cycle — can you walk me through the cycle of mounting a stateful component? What functions are called in what order? Where would you place a request for data from the API? Why?

If the answer contains componentWillMount you can assume that the person has been either working with an older version of React exclusively, or has done some outdated tutorials. Both cases should rise some concerns. getDerivedStateFromProps is what you’re looking for.

Bonus points: differences in the way the process goes on server-side is mentioned.

Same goes for the question about data fetching — componentDidMount is the one you want to say/hear.

Bonus question: why componentDidMount and not constructor?
Two reasons you want to hear are: “the data will not be there before render happens” — although not the main reason, it shows you that the person understands the way components are handled; “with the new asynchronous rendering in React Fiber …” — someone has been doing his homework.

We mentioned fetching data from an API — how would you go about making sure the data is not re-fetched when the component is re-mounted?

I ask this to see if the candidate understands the idea of not-coupling the UI and other layers in an application. An API that’s external to the React structure can be mentioned.

Can you explain the idea of “lifting the state up”?

Answers ranging from “it allows to pass data between siblings” to “it allows you to have more pure-presentational components, which make re-usability easier” are preferred. Redux might get mentioned here, though that could as well be a bad thing, because it signifies that the candidate just goes with whatever the community recommends without understanding why they needs it.

Bonus question: how would you go about passing data across multiple levels of depth, without passing it from component to component?
Context has become mainstream ever since React 16.3 — it was there before, but the documentation was lacking (on purpose). Being able to explain how context works (and at the same time showing knowledge of the function-as-child pattern) is a plus.

If Redux / MobX gets a mention here, it’s also good.

React ecosystem

How would you go about debugging an issue in React code; what tools have you used? How would you go about investigating why a component does not re-render?

Using RDT to debug the issue by checking if the component state/props are properly set is a good answer, mentioning using the Developer Tools to setup breakpoints is also a good one.

What testing tools have you used to write unit / E2E tests? What’s snapshot testing and what are the benefits of it?

The snapshot testing part also depends on what you use in your project; if you don’t find it beneficial, don’t ask about it. But if you do, fast and easy regression tests for the UI layer (generated HTML + CSS).

Small code challenges

/** * What is wrong with this example, and how would you go  
* about fixing or improving the component?
*/
class App extends React.Component {
constructor(props) {
super(props);
this.state = {
name: this.props.name || 'Anonymous'
}
}
render() {
return (
<p>Hello {this.state.name}</p>
);
}
}

There are multiple ways to solve it: remove the state and use props, implement getDerivedStateFromProps or (preferably) change to a function components.

/**
* Can you explain the differences between all those ways
* of passing function to a component?
*
* What happens when you click each of the buttons?
*/
class App extends React.Component {

constructor() {
super();
this.name = 'MyComponent';

this.handleClick2 = this.handleClick1.bind(this);
}

handleClick1() {
alert(this.name);
}

handleClick3 = () => alert(this.name);
render() {
return (
<div>
<button onClick={this.handleClick1()}>click 1</button>
<button onClick={this.handleClick1}>click 2</button>
<button onClick={this.handleClick2}>click 3</button>
<button onClick={this.handleClick3}>click 4</button>
</div>
);
}
}

This one takes a bit more, because there’s just more code. If the candidate answers correctly follow up with “why?”. Why will click 2 work the way it works?

Not a React question, if someone starts with “because in React …” it means that they don’t really understand the JS event loop.

/**
* What's the issue with this component. Why?
* How would you go about fixing it?
*/
class App extends React.Component {state = { search: '' }handleChange = event => {/**
* This is a simple implementation of a "debounce" function,
* which will queue an expression to be called in 250ms and
* cancel any pending queued expressions. This way we can
* delay the call 250ms after the user has stoped typing.
*/
clearTimeout(this.timeout);
this.timeout = setTimeout(() => {
this.setState({
search: event.target.value
})
}, 250);
}
render() {
return (
<div>
<input type="text" onChange={this.handleChange} />
{this.state.search ? <p>Search for: {this.state.search}</p> : null}
</div>
)
}
}

OK, this one will need some explaining. There’s no error in the debounce function. The way the application is expected to work, is it will update the state 250 ms after the user has stooped typing, and then render the string “Search for: …”.

The issue here is that the event is a SyntheticEvent in React, and if the interaction with it is delayed (e.g. via setTimeout) it will be cleared and the .target.value reference will no longer be valid.

Bonus points: the candidate is able to explain why that is.

We’re done with the tech questions.

What was the biggest problem you’ve faced on your past projects; what was your biggest achievement?

If you had unlimited time budget and could fix / improve / change one thing in your last project, what would it be and why?

Reversing the tables and feedback

Carl Vitullo wrote some good articles on the topic of what questions to ask your potential employer, I’ll refer you to those — be ready to answer them, or say that you can’t on given step due to NDA requirements etc.:

Give feedback

If the rest of the recruitment process is up to you, tell them you will get back o them in X days, if not, tell them that someone from your company will do that. If you know the process will take longer than 2–3 days, tell them that. IT is a big market at this point, and the candidate might have done multiple interviews — they might not wait for you to get back before accepting another offer.

Do not ignore the candidate — that’s literally the main complaint people share on social media.

The opinions expressed in this blog post are those of my own and do not reflect the opinions of any of my past or current employer, client or collaborator.

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store