You’re invited to a React interview with a live coding session? Your first reaction was 🎉 and your second “OMG, what am I going to do? 🤯”
Pair programming sessions during an interview are really scary. Much more scary than take-home assignments. Especially if you’re applying for your first React job. There’s a much more experienced and professional developer who watches you writing code? And asks questions?
But hey, when life gives you lemons make lemonade. As intimidating as they are live coding sessions can be a real opportunity.
In contrast to take-home challenges, they don’t take that much of your time and you can show off a much broader skill set:
Communication skills.AThought process.APersonality.
And these can help you land the job even if you didn’t ace the challenge from a technical perspective.
As you will see on this page, you don’t need to be a 10x developer to ace a pair programming interview. You don’t even have to finish the challenge. So don’t worry too much about the coding part itself. Instead, show the interviewer that you have a structured thought and problem-solving process. Your chances of getting to the next stage will skyrocket.
Read on to learn how.
Who would you select for a job?
Don’t get me wrong, the ideal candidate has both strong technical and strong soft skills. But even if you’re not a 10x developer from a technical perspective you can make a lot of ground with your soft skills
Just how to do so?
In this section, you’ll learn about a little framework that you can use when you go into a pair programming interview. It consists of four phases and is based on how work in a real-world developer team happens:
If you walk through these steps in a pair programming session you’ll signal a certain level of seniority in your thought process that many Junior developers lack. As you’ll see in a bit things that might look like annoyances or failures at first glance (e.g. asking questions or running out of time) are in fact opportunities to prove your professionalism and communication skills.
A mistake that many developers (especially inexperienced ones) make, is to read the task once and dive head-first into the code. But to the interviewer, this can be a sign of Junior’s mindset. Such a rushed approach is a sign that on the job you might head in the wrong direction and waste lots of valuable time.
So before you start coding you should clarify the requirements. Read the assignment again and ask the interviewer if you have any questions.
Even if you think everything is clear there might be hidden assumptions on both sides. To flush those out you can repeat the task step by step in your own words. Like this:
"I just want to make sure that I get everything right. I have to do ... Is that right?".
This might feel like you’re annoying the interviewer. But it’s an essential process in real-world teams that prevents developers from wasting lots of time building features that don’t work as intended.
When the requirements are clear you can make a rough plan. Tell the interviewer how you would approach the problem.
For example, a common task is to fetch data from an API and render it. You could start by checking the response of the API in the browser (if it’s a simple GET request). Then you’d say:
"There are two options to fetch the data: I could use a
useEffect and implement the API call there. But usually, I'd use a library like
react-query__. It’s very useful because it helps to handle a lot of overhead related to data fetching like loading state, error handling, caching, and so on. Then depending on the data structure I'd iterate over the array and render it in a component.”
This again helps to flush out hidden assumptions and misunderstandings. On top of that, coming up with different options and weighing them against each other is again a sign of seniority.
Note: even if you haven’t worked with
react-queryor similar libraries before you can still say that it’s a popular choice but you don’t have experience with it yet.
Now it’s time to write the code. Obviously, it’s good if you practiced similar tasks before (more on that in a bit). A pair programming interview is a very stressful situation already. And having the practice and ideally, a bit of muscle memory will help you stay calm.
While you’re coding it’s a good idea to talk out loud. Explain what you just did and what you’re trying to achieve next. This shows your communication skills and highlights your thought process.
When you get stuck or don’t remember something you’re often allowed to use Google. You can also ask your interviewer for help. This is not a sign of weakness. It happens to everyone (especially in a stressful situation like this). And on the job, a common mistake by Junior developers is to not ask for help when they’re stuck. They often rather dig down a rabbit hole and waste time going in the wrong direction when the solution is indeed simple.
Finally, if you know how to write tests definitely go for it. You don’t need to test everything or use a TDD approach. Just one or two tests will show the interviewer that you are comfortable with this. You’ll appear much more professional. It might be a good idea to ask upfront though:
"I'd usually write a test for this component. But since the time is limited should I write one now?"
Not many candidates write tests in coding challenges. So this is a great way to stand out.
From my experience, it’s often not that important to finish all the assignments in time. Especially if you take the time to clarify everything, talk the interviewer through your code, and write some tests, there’s a good chance that you don’t finish everything.
Let me share my personal way story: I was on a pair-programming interview. React hooks were still pretty new and I made the mistake of using
useEffect to fetch data from an API even though I wasn’t very familiar with it. In this stressful situation, I failed to finish the task. But the interviewer appreciated that I talked him through my attempts and I passed the interview anyway.
If you realize that you’re running out of time upfront it’s a good idea to be transparent:
“Hey look, it's obvious that I won't complete the task in time. I still have to style this component and make the button callback work. Is there anything you want me to focus on?”
Running out of time (aka underestimating tasks) is very common in real-world projects. The most important thing is that developers openly communicate this to their managers. This allows the team to cut scope and at least ship something.
Now that we talked about the importance of soft skills let’s move on to the technical part. Obviously, your tech skills are very important. Displaying a severe lack of React knowledge will likely cost you the job opportunity.
And, as always, practice is key.
Commonly tested technical skills are
useState, global or shared state with Context
useEffector a library like
react-query, handling loading and error state
Basically, you’re tested if you can write React components, handle (simple) real-world scenarios like data fetching, and work with CSS.
Interview challenges mostly aren’t too hard. At least if you would work on them in your usual environment. But in a stressful situation like a pair-programming interview, even simple tasks can turn very difficult.
So it can be helpful to know about common challenges and practice them upfront. This way you will have a general solution in mind already (and maybe even some pitfalls that you can discuss upfront).
Here are a few challenges that are common from my experience and what I read in different communities:
All these challenges test a variety of skills like CSS, state management, common JS array functions, API connections, and debugging.
While you practice these tasks don’t forget to practice the soft skills as well. Talk out loud while you’re coding and apply the framework in the previous section (clarification, planning, implementation, transparent communication when the time runs out).
I prepared a few React coding challenges that you can use for your interview preparation