Interview Questions for Experienced React Frontend Dev

Here are the questions I used recently to interview React Frontend Developers with 3+ years experience.

  1. Front End/React Experience - Give an example of something difficult you had to overcome.
  2. Any Material UI Experience?
  3. React: Explain state/life cycle
  4. React: Explain Class Component vs Functional Component and when should you use which
  5. JS: Explain Arrow Functions and some common pitfalls
  6. JS: Explain Closures
  7. JS: Explain await/async and promises
  8. JS: Explain how to (deep vs shallow) clone an object
  9. JS: Give an example of something difficult you had to overcome.

Number 3 tended to be telling of how things were going to go. On 5 all but one missed this. Most of them did not realize how the arrow function affects the scope/binding of the “this” reference. No one got 8 completely correct even the one we selected. There seem to be two issues here. One, just understanding what it means to deeply clone and two, being able to express it. For reference, I did not dock anyone if they did not use the correct terms, I was specifically focused on their knowledge and the ability to express it. Heck, I’m not sure I know all the correct terms. :smiley:

I’ll keep this tab open for a couple of days and answer questions anyone has about the process we used and the questions. I would not be where I am today if it was not for freeCodeCamp.

7 Likes

I really like your questions. Concepts over things I can look up in a language reference. I see many complaints about whiteboards, but IMHO knowing the ins & outs of the language’s fundamental operations matters, especially when hunting down a bug on the clock. I would definitely have asked questions about #8 (problem parameters - can the object contain nested arrays? If so, can those arrays contain objects at any level? Or can we guarantee that the input contains only nested objects of arbitrary depth and primitives, or flat arrays?) I would have “failed” question 2 and 7. Fluency in async operations is clearly my biggest weakness. That, and total experience.

Btw, it’s truly awesome to see an FCC alum not just getting a job, but giving them.

Why the question specific to material UI? is it because that’s the company go to theme and design? Would someone explain their experiences implementating a different design philosophy, say Microsoft’s Fluent, be satisfactory?

What sort of level of detail do you get from some of the more straight forward questions and more importantly, what were you looking for? For example for the arrow function questions, I’d have been able to say that Arrow Function does not bind their own this and argument, rather they get these reference from their lexical scope, but I wouldn’t really be able to give you a common pitfall other treating as a regular function and misuse this. I feel like that may not be enough detail, although I am not sure I know much more.

Incredibly helpful thank you! I am interviewing now for Front End positions…kind of a boost in confidence that most of the questions came easy to me…and that the ones you mentioned interviewees had problems with were the same that had me scratch my head. Definitely going to research these.

Thanks, Michael, thats great information to have insight into what is expected!

I’ve been learning React for a month and i only don’t know question 8. :open_mouth:

That’s cool!

Only the first 4 questions were related to React in any way, others are either generic types of JS specific.
Have you been doing JS for a while?

Little more background for all. The position we hired for will be given a project right off the bat and expected to do 95% of the work solo as it’s a new project from scratch for the most part. They will work with me to provide them access to an existing API and to expand on that API as they need. Also, in the future, we are going to post links to our job postings here.

vipatron

On 8, yes nested ie other objects and arrays. The key here was to understand if you do a shallow clone that object a { sub1: { name: ‘test’ } } where b = a, b.sub1.name = ‘changed’ that a.sub1.name === ‘changed’. Additionally, if they mentioned b = JSON.parse(JSON.stringify(a)) I wanted to make sure they could explain when they might not want to use that, ie in a server-side function that is called frequently as it’s blocking and slow. Normally, the speed would not matter but in a REST endpoint, it can kill performance.

Question 2 was not a pass or fail. It was just getting to know them/we use it but not hard to learn. Also, 7 is not as hard as you think. I read an article on Medium a while back that I think was written by an FCC’er to get up to speed. While async/await is not perfect, once you go async/await you never want to go back, lol. We converted away from cb hell/promise tree’s this last year and want to make sure whoever we bring on will be up to speed.

As to FCC, thanks! I actually got my CS degree before I found FCC. The FCC material was FAR more valuable than what I learned in College.

psychometry

Why Material? Because we use it. Not a show stopper. I try not to go in with hard questions right off the bat. If you didn’t know it, which most didn’t, I didn’t really care. It was more of a nice plus.

The biggest thing to understand about Arrow, which you pointed out is that it binds this to the scope its defined in. This can cause major headaches when the calling code that the arrow has been passed to expects this to belong to a specific scope. Mochajs is a good example of where things can go wrong. https://mochajs.org/#arrow-functions Another, major spot is when you do something like onclick=(event)=>aObjInstance.someFunction(event). I don’t remember the specific details but someFunction was broken by the arrow.

cndragn

I don’t know if you are going after junior positions or something higher up, but if you could answer most of these questions as a jr. dev then I would hire you. I do throw some coding problems at jr. devs. Right now, I would make sure to have a coding problem using fetch / node-fetch. One of the API’s would return a JSON body normally, but on errors, it would return a string body. Dumb, I know, but that was a recent error we ran into. Another item would be to download a file from one location and upload it to another using node-fetch.

Dohn_Joe

I don’t know React well. All of our apps up to this point were internal facing only, so my level of React was fine, and the speed of getting it built was not an issue. We are going to launch a new external product in the next 6 months. So we decided to bring on an experienced React Dev. We mostly looked at their prior work and I asked them the basics of React just to make sure they did the work. Most failed these basic react questions to the point of not even having a clue.

vaidotasp

Yeap, as I wrote to Dohn_Joe my react skills are weak/jr level. On the other hand, my JS/Node skills are considerably stronger. I’ve been doing JS/Node/React for 4+ years, but the workload is 50% ops, 40% Node/Mirth Connect, 10% React/Frontend.

2 Likes

@MichaelLeeHobbs, @psychometry: I just hunted down this thread after running into an issue and remembering a second pitfall with arrow functions I had read about but not encountered “in the wild.” In addition to inheriting this, they are lambdas, which means they can be assigned, but not declared. And while function declarations get hoisted, function expressions do not, so this won’t work:

{
  sayHi();
  const sayHi = () => console.log("Hello, World!");
}

but this will:

{
  const sayHi = function(){ console.log("Hello, World!"); };
  sayHi();
}

I changed the second example to show the issue is about function expressions, not arrow functions in particular, but since this is the only way arrow fxns can be called by name, it’s a second pitfall.

1 Like

Oh, and Michael, the way this forum is implemented, if you aren’t directly replying to someone’s reply, they won’t get notified unless you “@” them by writing “@”, and manually typing in their username or selecting it from the pop-up that shows up. You can edit your mass-reply to do this, and everyone will get notified.

Also, pursuant to your initial reply about #7, i’ve been putting it off until I learn more server-side programming, but I look forward to it! I didn’t understand timeOuts until I read javascript.info’s discussion of scheduled functions, which made me wonder about async/await. I really liked their treatment, and a quick perusal of their discussion of Promises and Async/Await made me bookmark it for the relevant time. [Links included for others in my boat]

1 Like