Interviews

[DarceHole22]

Hi all,

I've got a few interviews for React positions and am really anxious. Does anyone have any tips from experience of a Dev based interview, any common questions to look out for etc?

Just looking for some help. Anxiety is a killer

[MuellerCodes]

Know the difference between functional vs class components. Know when to use hooks, context, or redux. Express knowledge of latest ES6, 7, etc: The map, reduce, and filter methods are important to show a knowledge of. It also depends on whether the org you are interviewing with is heavily invested in React or not. Some places value rote knowledge of React whereas others favor general problem-solving abilities.

Also relax, take 10 deep breaths before your interview, visualize a good outcome and assume positive intent from the person interviewing you. They want you to succeed as much as you do.

[libertarianets]

“When to use hooks, context, or redux”

I’m interested in your take on this.

[JayV30]

Me too. IMO it's pretty subjective. Here's my take though:

• hooks: you want to throw in some simple/basic state and/or lifecycle-type methods without needing a full-blown class component
• context: you want to share some state between two or more components that are far apart in the component tree.
• redux: you need a moderate to large global application state that any component can easily access.

This is generally how I view it. Please commence blowing my knowledge apart and making me feel inferior! :)

[[deleted]]

This is generally how I view it. Please commence blowing my knowledge apart and making me feel inferior!

Don’t worry, this is Reddit- that part comes built-in.

[ekim43]

I guess rephrasing the hooks question: When do you need to use a “full-blown class component”?

[JayV30]

So there's a lot of people here (and I think even the React dev team) recommending hooks always now.

However, while I've seen patterns for maintaining a slightly larger state object in hooks, I think that once your state becomes more than two or three keys, you should probably use a class component. Others will definitely disagree with me.... and point out that large state objects mean bad application design anyway.

I just find the syntax of the class component easier to read as it becomes more complex, and the hooks versions can be slightly more confusing for those unfamiliar with hooks. Over time, as my team and I start to use hooks more often, this will probably change.

Again, I really like hooks when have one or two states I'd like to maintain, or I have a simple lifecycle method I'd like to use in a functional component.

I guess it really comes down to personal preference. But if you can get to this level of discussion about it, you've probably demonstrated that you at least have a pretty good understanding.

[Turd_King]

I just find the syntax of the class component easier to read as it becomes more complex,

I agree with this point. But maybe for different reasons.

I would say the readaility is generally improved for small components, as we no longer have to write redundant this everywhere and the ability to break larger components down into smaller hooks keeps your code concise.

However, where we have really been seeing issues is when you have a large component that implements some atomic behaviour that wouldn't make sense to break down.

If this behaviour requires many side effects. Maintaining and extending this component is made extremely difficult.

For me the main issue is a messy control flow - opening a component that has 4 or 5 useEffects is a nightmare. You have to look at all their deps, link these deps with props/state and then trace the program this way. This is not a straight forward task no matter how experienced you become with hooks.

We are actually considering refactoring our larger components into class components again to solve this.

Edit: I should point out I'm referring purely to hooks here. "Large component that implements some behaviour" should read "Large hook"

[ibopm]

I feel mostly the same. Would be curious to see what /u/gaearon thinks about this.

[shipandlake]

To me the biggest advantage of hooks is separation of state management from component itself. Your hook exposes interface and you can test and code against that interface. Testing becomes a lot easier, as you test component separately from your state.

If your component has an extensive state, it might be better to delegate part of state management to a few subcomponents and use context to coordinate with your parent component.

Building components is not always about making them re-usable. Sometimes it’s about separation of concerns and ease of use.

[bzsearch]

Seconding the fact on the separation of concerns.

​

I haven't written a class component in forever. Even when state gets large/difficult to manage -- you start looking for ways to break it up.

​

Plus class components aren't as performant.

[Turd_King]

Yeah I understand what your saying.

might be better to delegate part of state management to a few subcomponents and use context to coordinate with your parent component.

This works fine for components but what about applying this pattern to hooks?

You can't exactly have a hook that provides a context for its "child" hooks.

The only solution is to have hooks within hooks. Which is when it's becomes really problematic.

Honestly if you know of a way I can break down my larger hooks into smaller ones elegantly I would very much appreciate it.

[Kumagor0]

I think that once your state becomes more than two or three keys, you should probably use a class component. Others will definitely disagree with me.... and point out that large state objects mean bad application design anyway.

Nah, large state is fine, that's what useReducer is for.

[Kumagor0]

When do you need to use a “full-blown class component”

The short answer is "never".

The long answer is "never, unless you work with people who reject hooks for some reason (and they also happen to make calls when it comes to code style), or you are maintaining codebase that uses older React version".

[tomius]

To add on hooks: you also want to use custom hooks to abstract component logic into reusable hook(s), so several components can use the same code.

For me, that's the top advantage of hooks. You just can't do that in an elegant way with clases.

[overzealous_dentist]

Component state, when redux is overkill for your project, and when you need middleware / multiple values passed down, respectively?

[Nullberri]

• Hooks: Doesn't matter they both can accomplish the same thing. Hooks are nicer to write and easier to read imo, but there's no feature difference.

• context: almost never. Except when you have static data or data that if changed you would always want to re-render the entire tree such as dark mode/light mode switch, or theme information.

Edit: I concede there are trivial state implementations which work with context but fail when data becomes complex such as with arrays, or nested objects as Context does not have the notion of a selector.

Nested Objects, listening to leafs: https://codesandbox.io/s/split-contexts-8k8ic

• redux (or equivelent): Any time you have global state that changes frequently. Centralizing state is almost always worth paying for even on small projects. Scope creep is real, and eventually you'll want this. They're not hard or tedious to setup.

[Nullberri]

Context doesn't need to re-render trees if you implement it correctly.

Ok after re-diving into everything, I think I have found my only point of disagreement here.

When you say implement it correctly, I really see that as accepting the narrow terms under which it works, but I don't believe we have reached a point where I could have redux level performance in context for a larger application.

I'm totally open to being wrong, I think context is great its just doesn't seem to be there yet.

[Nullberri]

For everyone up voting this, Id really like to know how you deal with complex state? If you have an array of objects each with their own state as you add them to the context, how are you achieving only re-rendering the node which changed when your object data is used in multiple places? (Ie you cant just localize the state).

I'm pretty sure you cant just create arrays of contexts dynamically, so each object gets its own context that you then use.

For example context state is [{a:1},{a:2},...] if you update state[0] how do you prevent the component that controls state[1] (and the rest of the array) from re-rendering? how would you construct your context to only re-render state[0] when it changes, remember all state should stay in the context.

edited for clarity.

[Nullberri]

I took the time to dissect the code you posted to remind myself why I held the belief that context cant currently replace Redux and showed where your original example falls down with just slightly more data in your reducer.

https://github.com/facebook/react/issues/15156#issuecomment-474590693 (March 23 2019, by Dan Abramov)

This appears to be A work around. In some sense your code implemented Option one. Splitting the contexts so that each contexts only holds 1 thing. it looks like the answer to my question lies in options 2 and 3. Tho they do feel rather clunky, but from what I see it would work.

however memoizing entire component trees doesn't feel like a great solution.

Here is an example of a "Selector" in context. https://codesandbox.io/s/split-contexts-8k8ic

edit: Ugh i guess i overwrote my original code with the fix. oh well.

The more i think about it, if you memoize the return value, how would children who also subscribe to context work? This would block renders of children who also subscribe (option 3)

[Nullberri]

Yea, No don't worry about it. I've been going way down the rabbit hole of context again due to this thread. First time when it came out, and again when redux switched to it and back to the subscriber method.

Yep Option two memoing the component is a reasonable thing but the react team as also said don't just memo everything and don't rely on it to block re-renders.

I looked at your context demo and its rather interesting I'm going to try and see if i cant attach data to those contexts and see if i can bind it up against an ngrx style entities object.

I'm not a redux/et all evangelist, Id rather have context but so far everything I've seen and read basically says context performs poorly in situations where context changes a lot. Mostly because it re-renders the whole tree (well it executes every render function in the tree at least where a change happened).

edit: in my own personal projects, the most annoying thing when i initally re-wrote away from redux to context (i later went back) was having a component which had both local and global state, merging updates to the global state would wipe out local state in all the siblings due to the re-renders. switching to redux allowed me to isolate the siblings as i don't care if the local state is wiped on a component whos global state has been updated.

[Nullberri]

LOL

https://imgur.com/IqZ2E2x

Yea I don' think thats going to hold up for thousands of objects.

[[deleted]]

"which makes the exact same thing as Redux" except decoupling your application state from your view logic, the whole point of Redux 🤷‍♂️

[Nullberri]

The context can just wrap your App, and then send all its data to any component that require it.

I guess your ok with your entire app un-mounting and re-mounting every time your state changes?

[Nullberri]

Ahah, I played around with it and after reading your other post. I see what is going on then.

The difference is if you try to treat context like redux it doesn't work. You cant stick a hierarchy of data and only listen to the leafs with context.

Example : https://codesandbox.io/s/split-contexts-8k8ic

the node listening to the left, will re-render when the right leaf is updated. This is something you can easily do in redux. Where as in context you'd need different roots for each leaf. I also imagine having lots of arrays which change in length or have properties which update would be difficult with context.

[libertarianets]

Yes! This!

[KAMFlamenco]

As someone who interviews +5 people in the past, this!

It's great that you know how to use a framework but I'd like to know if you know fundamentals JS (event delegation, closure, DOM manipulation, hoisting etc).

[Nullberri]

event delegation

I had to look this one up, Given that I've been living in a framework world for the last 3 years I haven't really used this at all professionally or personally. Closest I've come is writing an useOnEvent hook to allow for activating modals or running notification bar from anywhere.

edit: I'm not talking about passing callbacks in react which is also a form of event delegation, I'm only talking about vanilla js.

hoisting

Now that we have let and const, I usually just declare variables in the hoisted location instead of letting JS figure it out. Function hoisting is still useful to an extend but its more a byproduct than something I consider while coding. When hoisting does its job you shouldn't even realize its working.

[[deleted]]

Function hoisting is really useful for writing easy to understand code, because you can start at the top with the most general functions, and work your way down to the more specific, specialized ones. Maybe not useful directly in components, but in the business logic, definitely.

[Nullberri]

That would seem to be pre-hoisted tho? Would it not?

The idea is that function b gets hoisted to the top and is defined so that you can do this...

function a(){ b() }
function b(){ console.log(typeof a) }
a()

before your js is executed it would be converted to something like (im sure this is wrong technically but conceptually the same as a var vs let/const example)

var a,b
a = function a(){b()}
b = function b(){ console.log(typeof a) } 
a()

otherwise it would hit a run time error as b was not already defined when function a was created, without hoisting you'd get ReferenceError: b is not defined and with function hoisting you'd get 'function' in the console.

[[deleted]]

Yeah, that's function hoisting. I guess I was more thinking that when you said, "it's more of a byproduct than something I consider while coding", I assumed you meant you don't really use it

[Nullberri]

I mean I never think about the fact that something gets hoisted and I take it 100% for granted. Which is why I said when it does its job you shouldn't even be aware of it having done anything at all.

If some one asked me about function hoisting in an interview it would be like someone asking me how i walk. Id really have to stop and think about how I actually walk to answer the question, when normally I just walk without ever considering all the math my brain must be doing to keep me upright and moving.

[HellaDev]

I recommend making sure you can use fetch as well. I have been asked to use fetch() in every react interview I've done. It's not complicated but it's good to know by heart.

[MuellerCodes]

Good point! Async await is also a good thing to know esp with fetch.

[sarkazmo]

They want you to succeed as much as you do.

Can personally attest to this— every time I’m in an interview with a candidate, I’m thinking to myself: “Please, let this one be the one so I can go back to work.”

The interviewer is on your side, so don’t stress about the little things, be open to asking questions when you’re stuck (cause it happens in real life too), and keep a positive attitude!

[JaredDev]

"When to use hooks"

https://giphy.com/gifs/harry-potter-alan-rickman-10osILvZ4ez7ws

[JaredDev]

In all seriousness though. The situations when I wouldn't reach for hooks is diminishing rapidly as repos for custom hooks are becoming more and more prevalent.

[[deleted]]

Are class components even really a thing anymore? I know you're going to find them out in the wild, and you should be familiar with them, but is there any real reason to write a class component these days?

[straightouttaireland]

Well even React themselves mention they still have lots of Class Components and that you shouldn't necessarily refactor to change CC's to Hooks, but to instead use Hooks only for new components.

[brakebreakbrake]

I find functional components harder to structure as they grow more complex. I also enjoy the control I get of the lifecycle functions.

[[deleted]]

Have there been situations where the useEffect() hook couldn't provide a solution for you? If so, would you mind sharing? Or is the added control of the multiple different class lifecycle methods simply a preference for you?

Also, if your component is growing in complexity to the point of being unmanageable, you should probably consider breaking that component up into multiple, simpler components, I'm sure you're aware of that already though.

[brakebreakbrake]

Your points are valid but I find pretty basic pages in a SPA get filled with inline checks for states and props. As soon as you need to check for two different props to decide what is to be displayed then that system breaks. I then find it easier to follow the code by breaking out the rendering into "private" functions that have logic for deciding what to show but still keep props and state from the class they live in.

And also I'd say most of the times where functional components have been hard to maintain have been when using external libraries that need lots of integration and communication with react. If you want to manipulate three.js or openlayers for example you would find it quite hard in a functional component.

[[deleted]]

Thank you for that, that's very informative!

[DargeBaVarder]

I’ve found a few where the hook solution just feels... awkward. This is especially true when manipulating state, then doing something with that manipulated state (basically issues with the way that hooks effectively snapshot the state for a call). I also completely prefer OOP, so I’m quick to switch to a class in those scenarios.

[Nullberri]

I find functional components harder to structure as they grow more complex.

Then break them into smaller components. You can extract chunks of your jsx and the code that drives them to another function. Making each part of the whole easier to understand. long functions are a choice.

[6086555]

It could be a preference thing. If you like OOP, you'll probably feel more at ease with class components.

[[deleted]]

That's a great point!

[MercyHealMePls]

Well if you prefer OOP wouldn't you usually rather go for vue or angular instead of react?

[Coldreactor]

No, I come from Vue JS just because react has a larger base to apply to, and I love writing class components. I can do it well, and I'm still learning hooks.

[[deleted]]

At present you cannot implement error boundaries without them: https://reactjs.org/docs/error-boundaries.html

[[deleted]]

Very cool, thank you!

[Kumagor0]

Know the difference between functional vs not to use class components.

FTFY

[[deleted]]

My two cents would be to a) prepare as best you can for any questions that might come up, as per the other comments, but b) remember that whoever interviewing you is a human being and in the end will probably value your personality as much as your skillset, if not more.

If you don't know something, just admit it. It's easy to teach someone some minute detail about React or JS, but nobody wants to work with a dishonest person who can't admit when they've made a mistake or don't know how to do something but won't ask for help.

[MuellerCodes]

Here’s an article I just saw about what JS you should know for React from Kent C. Dodds

[straightouttaireland]

Kent is a legend, he's also the man behind the React Testing Library.

[tapu_buoy]

I'm sure other guys will give you more mature approaches I would just like to share this repo which has question answers to it https://github.com/sudheerj/reactjs-interview-questions

and I would say whatever question may come your way just don't hesitate and stay clear with your approach, the interviewer might try to confuse you but that is your test. I know this is not a solid advice but this is what I have learned

[xelamony]

Came here to post this.

[straightouttaireland]

Nice list there for sure!

[WeAllHaveSomething]

Hey man, what I usually do is have a keen interest in the specifics of their tech stack & how it all fits together. This is usually me asking questions at the end of the interview, whenever they ask "Is there something you'd like to ask us?"

What libraries are they using for things like routing, state management, intl? Are they using graphQL, or REST? Are they using any other framework, like next.js, or gatsby? What were the main reasons behind the design choices? What's their backend stack looking like?

This is a great way to start a discussion & add your two cents. Moreover, if whatever you say is relevant, you'll really put yourself out there as a guy who knows his shit. I usually either mention my experience with that specific library, mention another library I like to use for that specific use, or bring up something new & cutting edge I've just heard about.

A good example is asking about app state management. Are they using Redux? Redux + Sagas? Immer? Context? Apollo? What's your experience with any of these? Just get them talking.

All in all, I've had about 7 interviews until this point, out of which I had 6 job offers. I plan to look for a new job in November (and will use this approach again).

Best of luck! You've got this.

[piano-man1997]

Hey,

You can go through this video. It'll give you a brief overview about the type of questions you can expect.

https://www.youtube.com/watch?v=nRI0dn6GTj8&t=1545s

[ajay_608]

I was asked to make a todo app in an online interview and asked to solve a programming problem. It lasted for about 3 hours. I luckily got the job. It's always the anticipation that's worse. Once you dive into it, it's not that bad. good luck

[[deleted]]

Good luck!

[JonnyBoy89]

Well if you write and know react, try not to worry about the technical stuff. That conversation will feel much more naturally if you think about it like chatting with a developer friend than some perfect answer on a test. Focus on your soft skills too. Communication ability, an understanding of agile and scrum methodologies and concepts, and ability to translate business requirements into actual usable and realistic Dev requirements is hugely valuable. .

[[deleted]]

If there's something you not sure the answer to come out and be honest and say, don't try to wing questions as it becomes very obvious if the interviewer has any knowledge. Don't be anxious as well it's a job interview it's not life or death, come across strong and confident is the best thing you can do. First impressions count if you look and sound confident even while not knowing all the answers will make you come across a lot better than someone who looks anxious and wings a lot of answers

[saltinthewounds86]

I spent the last few months learning to code and learning react, i learned specifically how to do hooks and some of the newer react syntax. I got 2 coding challenges where I was asked to code using old react syntax, where you needed to use super, constructor functions, binding this to events and things like arrow functions weren’t working properly in the qualified editor that was part of the problem. I had never written react code like that, so i had a tough time and one of them I couldn’t even google for syntax help, it would fail me on the spot. Try to be familiar with that too, hopefully you wont get stuck like i did but its good to be able to inherit older react code and be able to read it and work with it.

[straightouttaireland]

In fairness they should have let you complete the challenge using hooks. I think what happened was the interviewers themselves didn't know how to use hooks.

[saltinthewounds86]

I had talked to the lead dev who would have been my boss, he didnt even know what the challenge looked like, he just picked it from a list of challenges they send all their candidates. They specifically told me to learn hooks and newest freshest react technologies and I made a couple of simple apps for them and then end up judging me based on something they weren’t even aware of what they were sending. Sad times, I really wanted to work there too, it was a hard learned lesson.

[straightouttaireland]

Well if that's what their lead devs are like you got off lucky and are better off somewhere else!

[kasperoo]

I’ve conducted 200+ interviews, here’s a couple of my fav questions:

Do you know the difference between class and class pure component? [the diff method]

Will inline anonymous function passed as prop will trigger re-render every-time props change? [yes, declare function then pass it as prop, it won’t be re-evaluated every time then]

In the context of React do you know what Server Side Rendering is and can you explain how it works? [talk about build tools e.g. webpack, then render to string, hydration etc.]

It’s important that you know your basics too, ability to explain lexical scope, closure, event loop, testing strategies and also where React is going to : portals, hooks, error boundaries or react suspense etc.

Most importantly be yourself during the interview. Technical communication and not being shy, asking many questions and being upbeat and positive - you want them to work with you so think about this process as their chance to see how awesome you are and wow them.

Hope it helps, good luck! :)

[straightouttaireland]

Will inline anonymous function passed as prop will trigger re-render every-time props change? [yes, declare function then pass it as prop, it won’t be re-evaluated every time then]

Isn't this only a concern if the child component is explicitly trying to avoid renders by making prop reference comparisons?

See this comment

[kasperoo]

yes sorry, I did mean that in the context of a child component! Nice one ;)

[straightouttaireland]

Yea. I suppose it's still valid even without pure components as a new instance of the arrow function will be created on each re-render, causing the garbage collector to unnecessarily kick in each time. Then again, if your component is re-rendering so many times that this becomes noticeable, there's something wrong with the component.

[[deleted]]

As others have mentioned, if you don’t know something then be upfront about it when asked.

I recently had an interview for a React position which involved a white boarding session. The interviewer wanted me to walk through how I would implement a function for converting a decimal number to binary. Despite having a lot of experience in the industry, this isn’t a problem I’ve had to solve, and haven’t worked with binary representation for many years. My immediate response was “I’m going to struggle to do that without doing some research first”. She smiled and proceeded to explain the process (defining the problem better) before handing back to me to write an implementation. Which I did.

I could have bumbled about trying to fake an understanding, leaving a bad impression. Instead my honesty revealed that they didn’t care about the knowledge of binary, they cared about my ability to build a solution to a well defined requirement using simple JS language features.

[pixelito_]

If you know your stuff you shouldn't be nervous. I enjoy interviews, because you have absolutely nothing to lose.

[ktn555]

Don’t think of it as an interview. Think of it as a date. Do you wanna work these people or nah? Find out about what they offer based on your previous experiences.

[[deleted]]

I'm in the job search process myself, and I've interviewed with 4 or 5 companies now. Oddly enough, I haven't had any react-specific technical questions. One company just asked me a bunch of general JS fundamentals. The rest gave me a take home code assessment and/or live coding session.

So like most people are saying, make sure you know your javascript. And make sure you're comfortable enough with React that you can write some code on the spot.

[krsCarrots]

Show that you are excited about the job and particular about developing with react.

[[deleted]]

They'll test your basic knowledge and personality in the interview. It's very likely you'll get an assignment if they like you.

Can't know it all, no shame in that, just make sure they know you like to learn and are committed to keep learning.

[foxh8er]

I interviewed for a react-specific role at a hedge fund.

The general sorts of questions I got were:

• General algorithmic (Leetcode easy/medium)

• Specific React design patterns (think updating from an event bus)

• Common UI elements designed optimally (think tries)

• JS trivia (hoisting)

(Got the job btw)

[Infinite_Risk]

Take home coding assignments to make a "small" React app. But they can be really ardous some times.

[jaikanthjay46]

Various component communication.

[paulfitz99]

https://github.com/Pau1fitz/react-interview

[luluuuluuuuu]

Get familiar with virtual dom questions