There are many ways to conduct a technical interview, and they depend from company to company. You might get whiteboard designing of architecture system, writing an algorithm, or some coding challenge. After working with multiple companies and going through many interviews from both sides, I prefer coding ones. More specifically, making something like a to-do application. By doing it, in an hour, I can assess if a person is junior, mid-level, senior, or architect. In this text, I cover how I do it and what knowledge I expect for which experience level.
Application to build
I prefer a to-do application. The model for an item of it is straightforward. All you need is a text, a unique identifier, and some flag indicating its status. All to-do applications display the list of all items, enable input of a new item, toggle the item's status, and delete them. I don't expect to spend more than 45 minutes up to an hour. That is not a long time, so I don't expect candidates to do everything, just enough to show how they think and what they know.
Setup
IDE
There are many ways you can conduct this kind of technical interview, but I like codesandbox. There you can create an initial React application, and you can easily install other npm packages.
Data
I provide candidates with initial data. It is just a JSON file with few items located in the public folder. In React, every file located in that folder is available, and this one you can request by making a get request to /todo.json.
I am okay with googling for documentation, and I make it clear at the beginning of the interview. And this is also an indicator of candidate experience level. If the candidate checks documentation for some API, that is fine. But if the candidate googles everything, there is probably a significant lack of experience.
Interview
Task 1: Load data and display
I do give a walkthrough of all the setup, where data is, how it is available, and the end goal of the application. As a first task, I request to display all the items from my data file. In this step, I expect candidates to load data using fetch API in the effect hook. After they do this, they should store them in the state and display them in a list. Often, I hear from candidates they want to use some third party request library like Axios and are free to do so. Another variation is also how they are displaying it. Sometimes it is a list of divs, and sometimes, it is an HTML list element. I prefer an HTML list, but any other solution can be acceptable as long as the candidate explains. It is an excellent opportunity for discussion.
Senior vs. Junior
What separates senior and junior is looking ahead. Often less experienced developers set incorrect initial state data. They don't check if data already exists before rendering, and they do everything in a single component. Sometimes, senior developers can also make everything in one component, but what they do is they are evident in explaining what and why they are doing. In this case, they would say it is all in a single component for the sake of simplicity and that they are intending to split it once they have the display working. They have an approach to first make it work, then improve it.
Another thing in this task that separates junior and senior developers is fetching data. The experienced developer does it every day and should not have a problem working with fetch API and asynchronous code. A less experienced developer might struggle with it a bit. Struggling too much, or not being able to do it at all, might be a deal-breaker.
This task gives a lot of side questions opportunities. One of them is a key prop. In React, when you are displaying items in a loop, they need to have a key prop. Candidates with less experience won't pass it. Pointing at this error gives a great indicator of how much experience with React do they have, and it is an excellent opportunity to ask what it does. In this section, other questions that you might want to ask are about hooks and lifestyle methods, the difference between HTML lists, and the components' organization.
Task 2: Styling
There are many ways to do styling. There are CSS, LESS, SASS, bootstrap, and many other solutions. But I think that you need to know CSS. At this stage, I do not expect anything overly complicated. But I would ask to play around with margins and paddings, to remove list bulleting and maybe so some text styling. Junior might struggle because they are used to simple stuff or using a third-party library. But senior developer should be able to do it without any problem. It is also a perfect moment to ask for some comparison of different solutions and when to use which. Things like the difference between padding and margin.
Step 3: Updating status or adding a new item
If a candidate got to this part in under 30 minutes, it already does indicate good knowledge. Another task is to test more of their forward-thinking. The file is read-only, and they obviously can't update it. But they can work with the state. Here you can test the updating state in a parent component. It does show how deep is their understanding of components lifecycle - updating of status especially.
Step 4: Questions
After the coding part, it is always good to leave 5–10 minutes for theoretical questions. Juniors do get more straightforward questions, focused on their experience: tasks they had, and details on how they solved them. I like to do more comprehensive solutions for seniors, and I expect them to have questions as part of their answers. To consider requirements.
For more, you can follow me on Twitter, LinkedIn, GitHub, or Instagram.
Top comments (0)