First time interviewing candidates – what are the best React/frontend questions to ask?
Posted by No_Illustrator_3496@reddit | ExperiencedDevs | View on Reddit | 11 comments
Hey everyone,
I am a senior software engineer at a small company (\~50 people), and we are currently hiring for a senior frontend developer. I have been asked to take the frontend interview, but I have never actually been an interviewer before.
Our interview process is not very structured yet, so I am trying to figure out how to best evaluate candidates especially their React and overall frontend knowledge.
For those of you who’ve been on either side of the table:
1. What kinds of questions do you find most effective for assessing React skills?
-
How do you evaluate real world frontend problem-solving vs. just theoretical knowledge?
-
What are some of the best or most memorable questions you’ve been asked (or asked others) in frontend interviews?
ziksy9@reddit
Explain prototypical inheritance.
Pick 3 hooks and explain what they do and when you would use them.
What is XSS and why is it important?
If I needed to count how many users hovered a button hourly and didn't click it, how would you build that? What edge cases are there? What if we had 100 million concurrent users?
If you can answer those, and your candidate can't, look for a new candidate.
If you can't answer those, look for 2 new candidates.
xpingu69@reddit
Wow do you work at Meta?
BearyTechie@reddit
Do you have the job description with list of things you are looking for from this React developer?
originalchronoguy@reddit
My interview is adhoc but it works.
I ask how they parse data from an API and how they handle multiple states in a UI. If they click on a button and click on it multiple times; I ask about race conditions. About state management. So if they are building something like an online spreadsheet, a survey tool, a video layering track that syncs to a timeline to spin an audio track.
A good scenario question is: "How do you design a UI that allows two concurrent users to edit a row of a spreadsheet. Mary updates column A;Name, and John updates column N: email address" and how do you handle the conflicts and notifications.
Those kind of questions tells me how advance their skills are. If I can talk back to back on how to design a video timeline that syncs tracks, animates title, overlay and fades transitions, I then know I can speak with something who has the skills I can be comfortable with.
TruckHangingHandJam@reddit
The data on interviewing is… not great. Basically whatever you poison, the ability to predict on-the-job-performance is dogshit. That said the less smelly dogshit is “realistic work”, ask them to do something similar to what you expect them to do on the job.
For frontend, I would set up a free stackblitz with a project, and either:
A. Break it and ask then to debug it and fix it.
B. Set it up and ask then to add a feature of my choice.
The interview would be a call, with screen sharing, and I would let them use any reference they want (Google, documentation) except AI.
Also I wouldn’t necessarily focus on whatever technology as much as good fundamentals. I mostly hired for angular roles, but I set up stackblitz in react, plain JS, angular of course, vue, and even svelte. Then I’d like the candidate pick their poison. One of the best people I ever hired for an angular team was this lady who did the interview in plain JS.
psyyduck@reddit
As a general rule, the interview should resemble the actual day-to-day work as closely as possible. Like anywhere from "here's a couple tricky problems we ran into last quarter" (good), to a 3-month probation period (better). If you want someone who can build chairs, test them on building a chair. Don’t test them on “who invented the pentalobe screw” or “can you juggle with dowel rods”.
edgeruntime@reddit
been on the candidate side of this a bunch recently so here's what actually showed me the interviewer knew what they were doing.
give them a small broken component and ask them to fix it. not algorithmic bs, a real thing. like a useEffect that fires on every render, or a form that loses state on rerender, or a list that doesn't update because someone mutated an array instead of spreading it. stuff that happens on tuesday afternoon in a real codebase. you'll immediately see if they've shipped react code or just read docs about it.
for senior specifically I'd ask about tradeoffs. when would you not use react context. when is redux overkill. when do you reach for a ref instead of state. there's no right answer but you can tell fast if someone thinks about these things or just grabs whatever the last tutorial told them to use
NightSp4rk@reddit
On top of what others have mentioned - remember that personality is often as important if not more, than technical expertise. I'd pick someone with average technical knowledge who has a flawless character and a willingness to learn and figure things out, over someone who has deep knowledge but can't work nicely in a team or has deep personality flaws that affect the rest of the team. Any day.
TheAnxiousDeveloper@reddit
This. 100%
No one wants to work with assholes that are not proactive and that become a dead weight after a few months
BoBoBearDev@reddit
Have them explain memo, useMemo, useEffect, useCallback.
farzad_meow@reddit
i used story style approach get them to write a simple solution to a common problem then tell them they can close the editor and we do a story about the code.
a month later we found a bug, here are the details, what else do you want to know? how to fix it? see of they add logs to monitor the result.
3 month later we need to add x feature. how long do you expect it to take? and blockers?
a year later, we need to migrate, how to do it without downtime, minimize user impact.
i evaluate their mindset and problem solving. not they ability to write clean shiny code.