As a developer of Js - React, for me the topic is perfect on both channels, in fact now I'm watching the other on Clement's channel, so thanks for these two guys, great
Thanks Conner and Clement for another great interview video. I don't only learn the logic and how you approach the problem, but also the coding style. Please make more videos like this.
These kinds of interviews are way better than just your basic lazy l33tcode interview. These actually show someone can be productive in React on the first day of employment versus just memorized some algorithm.
Speaking of the addEventListener optimization at the end, you don't need React to be React-y with the values you're passing. The event listener itself is inherently (lowercase) react-y, and it's updating the state, which is (uppercase) React-y. I feel like optimizing that function would have been a great interview test, whether necessary in this particular situation or not, because it represents a whole slew of common patterns associated with event listeners and effect clean up, which frequently need optimization.
Yeah I spent some time after filming this trying to optimize it more out of curiosity (and it might be coming as a FrontendExpert problem 🤫😉) and it turned out to be a really interesting problem. I'm not sure there is actually a single "correct" solution since anything more performant than what I did in this interview would almost definitely be less readable, but it's an interesting discussion nevertheless.
@@ConnerArdman yeah it's a little difficult to say what the "correct" solution would be. Certainly using callbacks in your setState would do some good but it's really just putting a bandage on the issue, and only works in cases where you're not reading the state in the handleEvent function body. The proposed useEvent hook would also provide the same solution. Ultimately if you want to fix the redundant adding and removing of the event listener you'll have to rely on refs. I don't know if I'd say that it's less readable to do so either. With the recent React.StrictMode update people are needing to rely on certain ref/effect patterns to ensure their "run once" effects only run once(which only applies to development anyway). I think that unless React is planning to offer a built in solution, devs will start becoming more familiar with "initialized" refs, and even more complex methodologies like callback refs to handle problems like this(I would take on this particular problem with a combination of both probably 😉).
@@jcollins519 Indeed. A clean solution would be to use a ref with the callback using the "latest ref" pattern for the listener callback, and pass that into the event listeners; that way the listener always gets the latest state while the event listeners are only attached/detached once (in production). This is also how useEvent works somewhat. As an aside; StrictMode is only enabled in development mode. It is removed in production builds, so it's not going to double render. So it is not necessary to use refs to avoid double rendering; only if it becomes an issue during development; i.e. you're external network calls or doing heavy computation. But this is exactly why StrictMode is a useful tool to catch those issues, so that you see them and can act upon it. It's not really needed at the top-level of your app, but rather more useful to wrap about certain parts you think are important to optimize.
One can hate Facebook as much as they want but React is probably their greatest gift ever to the developer world :). All hail React, made me fall in love with Web Development :). Also nice interview sessions. So far I have watched two of them and in both sessions I felt I could solve those problems too even though I do web development mainly for fun :)
@@drizzletone9148 Theyre both tools for specific purposes and solve problems for a business. It's not an X > Y scenario. You either use one or you don't.
React sucks. There are many libraries/frameworks that are thousands of times better, such as Vue and Svelte. Thinking React is the best web development tool is like thinking Mcdonalds makes the best food or Windows is the best operating system. Facebook sucks even more than React.
I love watching these interviews! ❤️🍺 And I doubt if any candidate is able to give as fluent explanation as you😂, while writing solution on the go in tense interview environment. But ig you have an edge in explaining stuff because of past experience in making courses/tutorials.
Didn't understood anything in code (def not my level yet, hopefully one day) , but the way you solved this so easily... It just deserves "subscribe" button to be pushed 😀 Impressive!!!
I sat for 47 mins and watched this with only a moderate knowladge of html and css, just to see what it is like to code JS which I want to do. I was not disappointed. Great content, i didn't understand a syntax of it but I can read your body language and how you code. Thanks for the upload really. It helped me understand things.
I understand everything going on in this video and could definitely code this myself, could I do it while someone is watching......no chance! :D These type of coding challenges just don't work for me, I completely freeze, mistype characters, panic and just lock up, the last time I done a test like this I started crying after 15 mins lol take home tests and then a chat afterwards about my solution though I completely smash! Great video and solution :)
This exercise is very close to real day to day dev work so with project experience it should be easier. At least it isn't arbitrary leet code questions on a white board.
Conner, please make a video about how to learn Front end System design for the coding interview 🙏 I'm FE engineer currently learning FE expert and Algoexpert at the same time, and don't know about system design for the FE.
Amazing interview .. awesome thinking and problem solving! Skill is shown by both the interviewer and the interviewee .. thank u guys; i know u do this for a living but keep it up 👏✨❤️
yoo, awesome video! your solution was fantastic, I could never make wordle that fast under pressure lol. and clement is always on it, he's so good at keeping up with the people he interviews. thanks for the motivation to get better at react!
u can use one useEffect just for setting event listener and put letter into useState. and another useEffect with that letter in dependency array for the rest.
The LLLLL guess should not return 3 yellows and 2 greens, it should only return the 2 greens. Each time a color is added to the guess the matching letter in the original word should no longer be considered when determining future colors. One way to do this is to save the correct answer to a temporary variable. You then check each letter in the guess for green. If it matches then set the guess letter to green and set the answer letter to a space. Then check each letter again, but only the ones that are not green. If the original answer contains that letter set the guess to yellow and set the original answer letter that matched to a space (so that it won't be used again). LLLLL for HELLO will return 2 greens for the L's. LOOLL will return Yellow, Yellow, Grey, Green and Grey. This means there are only 2 L's in the answer, and one of them is correct and there is only one O, but the two guesses are both incorrect.
Well, when the name Clément Mihailescu showed up on my screen. I thought this was the "normal" interview and I wouldn't see this but some goddamn miracle I still clicked on it and watched it for 45 minutes. Thank god I still get it but because of coding I'm pretty sure I can't do it in 45 minutes.
I've been doing interviews for React positions recently and have been doing live coding as well. I am confident I can do the problem given in this video. And have been performing at this level for the interviews. But I run into issues when they start asking questions about hooks like useMemo, useContext which I have ignored until now. So if you are interviewing just make sure you study all the hooks as most senior react devs are expected to know everything. The hooks used in this video are not enough in my experience.
Yeah I totally agree that you need to study beyond just what you might use in "normal" everyday React projects. Oftentimes those less-used hooks are a good way to gauge the difference between someone who has used React and someone who has really studied it / knows it fairly deeply. And shameless plug, we do have videos on these hooks (useMemo, useContext, useRef, useImperativeHandle, etc.) as well as some hook-specific practice problems on FrontendExpert :)
Two hansome guy play a wet game. I just see the experiencer to communication with Java programming. This is the first time what I love when think programming languge can make a game and play with each other.🤓🤪
Yeah this is because the AlgoExpert servers don't expect requests from non-algoexpert domains, so the browser blocks the request for security reasons. Technically you can disable cors in most browsers with some extensions, and that would work (although I wouldn't necessarily recommend doing that, and if you do make sure to re-enable it when you're done). Alternatively, if you own FrontendExpert, we released a version of this as a problem over there today with the same API (and requests to it will work from the FrontendExpert workspace).
To eliminate the problem of adding and removing event listener again and again what if we use redux or something like useContext ? Then i think the guesses data we need can be handed to keystroke handler function inside useEffect without rerenders, so ultimately allowing us to remove the dependency.
Don't do that, this is definitely not a level you need to be at to get your first job. This would have taken me at least twice as long to do (if I could even do it) when I was first learning and applying to jobs 😊
Hey Conner! This is a really good video! I just sent it to my colleagues. Now I'm even more interested in optimizing this addEventListener issue. Are you going to try to make a video with one of the solution? Thing is many devs do not understand such things. If code works the job is done (no need to improve or optimize the code) - this makes me very sad.
I don't necessarily think it's a very big problem since the browser can add/remove event listeners so quickly, but the solution is essentially just to use useReducer, which would naturally remove the dependencies from the useEffect (because React automatically passes them to the reducer function which would handle the logic outside of the useEffect). I'm not planning on making a video on it, but we did add a similar problem to FrontendExpert with useReducer as one of the solutions 😉
I have been stuck on the same bug for 2 days and watched this vid and you had a syntax method I did not use that my boss did not catch either and now I can finally move on with my fucking project lmao.
Hey Connor, great video! Do you think you could share the project/source code with us? I would like to take look at the parts that I didnt understand too well.
Thanks! Unfortunately I don't think I actually have these files saved anymore 😔 I'll make sure to post the code for future videos. We do have a similar version of this problem coming to FrontendExpert soon though 😉
Please look up documentation. Using Fetch in "useEffect" is an anti pattern, you should avoid it and handle it by events. Especially look up beta/preview documentation
I would actually disagree with the idea that using fetch in useEffect is an anti-pattern. Event handlers should usually be the first choice where they make sense, but not all data fetching happens in response to an event. In these scenarios, there really isn't another good place to do it without needing another framework on top of React. In this case, the data needs to be fetched when the component is first mounting. Since a component mounting is a React concept, there isn't going to be an event that directly maps to it and allows us to easily rerender the component when the fetch completes. If this were a production webpage, then I would probably want the solution to be sent down with the initial page load, likely via server-side rendering. That said, for this problem in an interview context I think useEffect was the correct choice (although _maybe_ it would be slightly cleaner to add a cleanup to that effect to cancel if the component unmounts, but that is mostly a non-issue since the component cannot unmount in this simple page). For reference, here is the page of the beta docs describing fetching data with useEffect: beta.reactjs.org/learn/synchronizing-with-effects#fetching-data
Great video! I just kept wondering: wouldn't the array deps issue in the useEffect with the eventListener handler be solved if the state was stored together, as in the same useState or in a useReducer? Since the issue seems to come from the relationship between the different state values and previous state values.
You could also "revert" the dependency by creating a custom hook that listens to every key press event, stores the pressed key info, and returns it. Then in the main component have a useEffect that runs whenever the custom hook returns a new value.
Yeah I think useReducer is the best way to solve this if it is a problem you are concerned about. The custom hook you described could probably work also, although I'm not sure that's much better honestly, just because it creates a lot of extra code.
Thanks! It really depends (I know, that's not a very satisfying answer lol). In general, I wouldn't think of problems as having a direct mapping to a level, but rather there are different expectations for different levels in how candidates will solve the problem. I'd say this is probably in the slightly harder realm of problems, mostly due to it's length and ambiguity. I don't think I'd expect an entry level developer to completely solve this in less than 45 minutes without hints, but it might still be a good question to ask them to see how they approach it and to give them room to really excel if they can complete it. On the other hand, I'd probably expect a more senior developer with substantial React experience could probably get through the problem, and they might excel further by bringing up additional concerns such as accessibility or how this could have been improved with server-side rendering.
@@ConnerArdman Thanks for the answer, I asked because I have been working with react professionally for 6 months now, and I was looking to change my job but I still have no idea what level my current react knowledge is at. So this answer gives me everything I was looking for. Thank you a lot. Keep up the great work!
You should never use open array and do plain java script in react without holding something in the state or in block of the code. Also, react code need to be declarative, no imperative code and poly fills in open block inside the component. Always use function and block scoped logic (helper, handler function). Also, never use == in react or even in every java script code, its always ===. Next, to many if else if else running in to a if else hell. Use switch and code your cases if you have more then 2 if. In my react career, i never used for loop. Everything can be done in ES6+ way using higher order functions.
I'm not sure I follow what you mean by not using "open arrays" without state or the part about polyfills. If you're referring to the tiles array, there was definitely a cleaner way to do that, but I don't think the solution I gave was incorrect in any way, especially for a short interview. As for the function and block scoped logic, I'm not really sure what you're referencing here either. The only code scoped outside of functions were constants, which is a generally accepted practice. I agree about == vs ===, but there is a special case with == null. When you do val == null, it essentially is also checking for undefined. Some people prefer this while others don't, but it certainly is not incorrect. For instance, at Facebook my team (and I believe most if not all teams) preferred == for the null case. For switch vs if/else blocks, I wouldn't fully agree with the idea that anything > 2 cases needs to be a switch. If the conditions are more complex than checking a single value, then switch cases can get complicated in my opinion, since they are meant to switch on possible cases for a single value. That said, my logic around the event.key probably could have been more readable. As for for loops, I've used a few traditional for loops in production code but mostly agree that ES6 functions should be used instead in most cases. In the case of the tiles loop, it probably would have been better to make sure the guess string was 5 characters and use map as Clement suggested, but in the timed interview I just had to do what came first/most naturally to me.
There is nothing glaring bad about what he is doing for this type of interview scenario. Arrays are perfectly fine to use for operations that are needed for display logic or render logic, these aren't state, they need to be "computed" each paint. An improvement would be using useCallback to memoize handlers etc. Also memozing components that have heavy business logic needed in the renderer.
Spread and Splice is a waste because we're using react state, it's better to use slice() because modifying the original string is bad practice in general for "immutable data handling". The ideal way is setCurrentGuess(prev => prev.slice(0, -1));
99% of coders can't do this in 45 minutes. What would be a reasonable result here? It can't possibly be you don't get the job because you didn't build a full game in under an hour is it?
A good interviewer isn't too concerned with your ability to finish some problem in an arbitrary time frame. They're assessing your problem solving skills, communication, code quality, and domain knowledge (in this case, React/JavaScript). Of course finishing the problem and reaching an optimal solution is always good, but oftentimes it isn't necessary. For example, I once passed an interview where my code literally didn't work, and I've failed interviews where my code worked perfectly. But to more directly answer your question, I'd actually expect a large portion of more senior frontend developers with significant React experience would be able to finish most of this, if not all of it, in 45-60 minutes. On the other hand, a more junior developer or just someone newer to React likely wouldn't finish the whole problem. But of course the bar for them would be lower if given the same problem as someone more senior.
35:40 you must be a psychopath remembering regexp for anything. I'm googling that shit until I die. I'm of course kidding about the psychopath! Really informative video!
Could someone explain isFinal={!isCurrentGuess && guess != null} not sure exactly how it works in determining that enter was pressed and the guess was finalised
This is a really good question. React effects should always clean up after themselves. Each time the effect runs, a new event listener is created. But if the hook runs twice, we don't want two event listeners, so we need to remove the old one on cleanup before creating a new one. Additionally, if the component unmounts, we want to delete the event listeners so we don't have a bunch of useless event listeners when the user has navigated away from the portion of the application that needs them.
That was phenomenal! I am just a beginner web developer with 5 years of experience and no experience with React as it is quite intimidating for me but watching you just get this done is so inspirational. For the instance where the solution is "HELLO" and the user inputted more than 2 L's, I think we can handle that by just counting the number of instances of that letter in the word? I don't know if that makes sense. Hopefully it does. LOL
Yeah if he asked me to handle that, that's pretty much what I would have done. I'm not sure of the exact rules actual Wordle uses, but it should just be some basic string manipulation.
Just Dive in its man I swear on me you won't regret it it's like putting Legos together typing it out didn't sound as fun as it did in my head but react is lit and its beginner friendly
It was amazing to watch this!! You completed the logic around 34 mins, honestly I would try to clean the code post that becz the soln you got is little messy 😅 Thanks for recording this, really helpful :)
This is the nullish coalescing operator. If the value on the left side (guess in this case) is null or undefined, it returns the value on the right side (empty string in this case). If the value on the left is any value other than null/undefined, then that value is returned.
@@ConnerArdman Ohh I see. Got it! This is pretty useful ☺️ I'm wondering is there a ternary operator similar to this coalescing, that runs when value is true without the ":" Sometimes I only want something like true ? 'run this code' : ' ' I had to put empty string but isn't necessary. Idk if u get me but just wondering if there's something like that
@@pjguitar15 Maybe what you’re looking for is booleanValue && doSomething(); doSomething is run only when booleanValue is true. This expression does not use ternary operator though
In case there is confusion here, Clement is the interviewer and I am the interviewee in this one. But to answer your question, Clement learned to code in 2016 at a bootcamp and got his first full time job in 2017, so he has ~5-6 years of coding experience. I first learned frontend development in college in 2016, then I learned React at a Facebook internship in 2018. So I have about the same years of experience as him coding in JS/React, but with just under 2 years of that being time spent working full time.
@@ConnerArdman So what if I just started learning React, any suggestions how should I approach? Any bootcamps? Your help is much appreciated. Please do reply.
@@piyushchopade7878 Learn some basic stuff like useState, useEffect and components. Get your hands dirty. Start making projects. Start with mini projects(for example minig games like Tic Tac toe), portfolio websites or trying to clone websites you like(for example Netflix, Spotify etc.). (I assume u have basic knowledge of JS)
Thanks for watching! Make sure to also check out the JavaScript interview we did on Clement's channel here: ua-cam.com/video/Rs7ARD5TCFU/v-deo.html
Conner has an easier time building Wordle than playing the game. 😅
I was under a lot of pressure 😅 🤣
easier? maybe 😜
I was like huh Connor is on fire 🔥
@@ConnerArdman you wear really sweating from your butts. SMILES.. but you did so well
Do Angular
As a developer of Js - React, for me the topic is perfect on both channels, in fact now I'm watching the other on Clement's channel, so thanks for these two guys, great
You explained everything better than most of the tutorials on youtube. 😂 Great interview ! You own my sub.
Thank you!
@@ConnerArdman k
o
klo
I actually understood what was going on for the first 10 minutes. Very proud of myself 😂
I ain’t going to lie Conner. You making this game makes me so happy 😂. You are too good at react. Teach me your ways!!
I was dying inside since I haven't learnt react yet but I love the way you make up the logic so quickly
This is really hard-core live interview. If someone asked to make this live. I wouldn't have make it or write any of the codes.
Thanks Conner and Clement for another great interview video. I don't only learn the logic and how you approach the problem, but also the coding style. Please make more videos like this.
you are so chill and i learned so much from this video. you deserve bigger audience
Thanks, glad you learned something from the video!
You're an absolute beast Conner! Super inspirational🙂
Thank you!
These kinds of interviews are way better than just your basic lazy l33tcode interview. These actually show someone can be productive in React on the first day of employment versus just memorized some algorithm.
Absolutely. Hopefully they become more common over time 🤞
And many times interviewers ask garph/tree problems in the frontend interview 🤣
Speaking of the addEventListener optimization at the end, you don't need React to be React-y with the values you're passing. The event listener itself is inherently (lowercase) react-y, and it's updating the state, which is (uppercase) React-y. I feel like optimizing that function would have been a great interview test, whether necessary in this particular situation or not, because it represents a whole slew of common patterns associated with event listeners and effect clean up, which frequently need optimization.
Yeah I spent some time after filming this trying to optimize it more out of curiosity (and it might be coming as a FrontendExpert problem 🤫😉) and it turned out to be a really interesting problem. I'm not sure there is actually a single "correct" solution since anything more performant than what I did in this interview would almost definitely be less readable, but it's an interesting discussion nevertheless.
@@ConnerArdman yeah it's a little difficult to say what the "correct" solution would be. Certainly using callbacks in your setState would do some good but it's really just putting a bandage on the issue, and only works in cases where you're not reading the state in the handleEvent function body. The proposed useEvent hook would also provide the same solution. Ultimately if you want to fix the redundant adding and removing of the event listener you'll have to rely on refs. I don't know if I'd say that it's less readable to do so either. With the recent React.StrictMode update people are needing to rely on certain ref/effect patterns to ensure their "run once" effects only run once(which only applies to development anyway). I think that unless React is planning to offer a built in solution, devs will start becoming more familiar with "initialized" refs, and even more complex methodologies like callback refs to handle problems like this(I would take on this particular problem with a combination of both probably 😉).
@@jcollins519 Indeed. A clean solution would be to use a ref with the callback using the "latest ref" pattern for the listener callback, and pass that into the event listeners; that way the listener always gets the latest state while the event listeners are only attached/detached once (in production). This is also how useEvent works somewhat.
As an aside; StrictMode is only enabled in development mode. It is removed in production builds, so it's not going to double render. So it is not necessary to use refs to avoid double rendering; only if it becomes an issue during development; i.e. you're external network calls or doing heavy computation. But this is exactly why StrictMode is a useful tool to catch those issues, so that you see them and can act upon it. It's not really needed at the top-level of your app, but rather more useful to wrap about certain parts you think are important to optimize.
Great video. Connor talking out loud while coding makes me understand this better.
He was prepared. There is no chance to come with the structure of the game in like 2 minutes. Staged for views
Get better hater
Ohh man.. I feel like I know nothing after this. I have to practice hard. Great interview. I appreciate!
ur so chill dude i really want to be like u while solving coding problems
Haha in fairness I'm not sure I would come across quite as chill if I was talking to a stranger with a job on the line 😂
@@ConnerArdman still the way u pro coders think while solving any random problems given to u on the spot is just mind blowing for me.
learnt a lot about following good practices and this is also a good project for a begginer to build to test react
One can hate Facebook as much as they want but React is probably their greatest gift ever to the developer world :). All hail React, made me fall in love with Web Development :). Also nice interview sessions. So far I have watched two of them and in both sessions I felt I could solve those problems too even though I do web development mainly for fun :)
Vue (3 with script setup) is in every single aspect better than React. Well maybe besides job offers.
@@drizzletone9148 Theyre both tools for specific purposes and solve problems for a business. It's not an X > Y scenario. You either use one or you don't.
Svelte - compile time, no virtual dom
React sucks. There are many libraries/frameworks that are thousands of times better, such as Vue and Svelte.
Thinking React is the best web development tool is like thinking Mcdonalds makes the best food or Windows is the best operating system.
Facebook sucks even more than React.
Awesome guys ! thanks a lot for this high quality coding experiences!
I love watching these interviews! ❤️🍺
And I doubt if any candidate is able to give as fluent explanation as you😂, while writing solution on the go in tense interview environment. But ig you have an edge in explaining stuff because of past experience in making courses/tutorials.
Thanks! I think anyone can get with practice, but yeah I’ve had a lot of practice explaining while coding at this point.
That was amazing! Great performance Conner.
Didn't understood anything in code (def not my level yet, hopefully one day) , but the way you solved this so easily... It just deserves "subscribe" button to be pushed 😀 Impressive!!!
Thanks! And you’ll get there soon, it wasn’t that long ago that I was feeling the same way watching this type of video 😀
I love these, I love how Conner explains it, very nice! Subscribed to Conner as well.
Damn you crushed it, with only 40 minutes thats crazy.
I sat for 47 mins and watched this with only a moderate knowladge of html and css, just to see what it is like to code JS which I want to do. I was not disappointed. Great content, i didn't understand a syntax of it but I can read your body language and how you code. Thanks for the upload really. It helped me understand things.
Awesome! Good luck learning JS 😊
I understand everything going on in this video and could definitely code this myself, could I do it while someone is watching......no chance! :D
These type of coding challenges just don't work for me, I completely freeze, mistype characters, panic and just lock up, the last time I done a test like this I started crying after 15 mins lol take home tests and then a chat afterwards about my solution though I completely smash!
Great video and solution :)
Interested in collaborating?
Wow how do you guys get at this level where you can easily form the logic off the top of your head lol
it's all staged bro 😂
This exercise is very close to real day to day dev work so with project experience it should be easier. At least it isn't arbitrary leet code questions on a white board.
it was fun to watch, better than best tutorial on youtube
Conner, please make a video about how to learn Front end System design for the coding interview 🙏
I'm FE engineer currently learning FE expert and Algoexpert at the same time, and don't know about system design for the FE.
Amazing interview .. awesome thinking and problem solving!
Skill is shown by both the interviewer and the interviewee .. thank u guys; i know u do this for a living but keep it up 👏✨❤️
yoo, awesome video! your solution was fantastic, I could never make wordle that fast under pressure lol. and clement is always on it, he's so good at keeping up with the people he interviews. thanks for the motivation to get better at react!
Thanks! Clement really is good at following logic & finding errors in code he didn't write, definitely an under-appreciated interviewing skill haha
How can anybody be so so correct, handing the edge cases, without previewing output for the most part, in his first attempt?
u can use one useEffect just for setting event listener and put letter into useState. and another useEffect with that letter in dependency array for the rest.
What if you input the same letter twice?
@@vgerov1 save letter as reference type should solve it. array with one item or object with one property.
@@pEeLL00 That will work, thanks.
The whole solution will cause an extra render, though, which might be a problem in itself.
haha, the interview. create a game, but u will get hired if only u can win the game you created
@Conner Ardman 10 minutes into the video, you are really good. I like the way you are writing code.
Please upload this in Frontend Expert question list as well.
Coming soon 👀
I actually finished your video, impressive collab man, new sub!
Thanks!
The LLLLL guess should not return 3 yellows and 2 greens, it should only return the 2 greens. Each time a color is added to the guess the matching letter in the original word should no longer be considered when determining future colors.
One way to do this is to save the correct answer to a temporary variable. You then check each letter in the guess for green. If it matches then set the guess letter to green and set the answer letter to a space. Then check each letter again, but only the ones that are not green. If the original answer contains that letter set the guess to yellow and set the original answer letter that matched to a space (so that it won't be used again).
LLLLL for HELLO will return 2 greens for the L's.
LOOLL will return Yellow, Yellow, Grey, Green and Grey. This means there are only 2 L's in the answer, and one of them is correct and there is only one O, but the two guesses are both incorrect.
I am at my fiest year of react i hope i will become skilled like you as time passes
You got it, just keep working at it and you'll be there before you know it 👊
Ha! I'd have won on 5th try! haha
I'll be doing this myself as an exercise! Thank you for sharing this recording!
Glad you enjoyed it, good luck doing it yourself! 😊
this guy is a machine
Well, when the name Clément Mihailescu showed up on my screen. I thought this was the "normal" interview and I wouldn't see this but some goddamn miracle I still clicked on it and watched it for 45 minutes. Thank god I still get it but because of coding I'm pretty sure I can't do it in 45 minutes.
Wow.. imagine being able to come up with this kind of logic on the fly and put it into working code at the same time.. I don't even
I've been doing interviews for React positions recently and have been doing live coding as well. I am confident I can do the problem given in this video. And have been performing at this level for the interviews. But I run into issues when they start asking questions about hooks like useMemo, useContext which I have ignored until now. So if you are interviewing just make sure you study all the hooks as most senior react devs are expected to know everything. The hooks used in this video are not enough in my experience.
Yeah I totally agree that you need to study beyond just what you might use in "normal" everyday React projects. Oftentimes those less-used hooks are a good way to gauge the difference between someone who has used React and someone who has really studied it / knows it fairly deeply.
And shameless plug, we do have videos on these hooks (useMemo, useContext, useRef, useImperativeHandle, etc.) as well as some hook-specific practice problems on FrontendExpert :)
Man, you are beast) you made it look easy)
For the last problem you could just us useReducer and manage the state with it. the dispatch function is static
Yeah I think this is definitely the cleanest way to solve that useEffect problem, honestly not something I even considered in the moment.
Amazing video brother...
Keep up like this content...🚀💥
Thanks!
Two hansome guy play a wet game.
I just see the experiencer to communication with Java programming.
This is the first time what I love when think programming languge can make a game and play with each other.🤓🤪
4:55 LMFAO my exact thoughts when he just started typing that out instantly
Great job explaining everything as you go! Very impressive and you know your framework.
The other guy though.. was not impressed with him
Conner please make more videos like this.
More coming soon 👀
Great work, Connor! Very informative.
Thanks! Glad you found it informative! 😊
Wow!!! Very awesome skills!!
Hi. I am trying to follow along in my own codesandbox, but I get a CORS error when trying to use your API. How do you fix that?
Yeah this is because the AlgoExpert servers don't expect requests from non-algoexpert domains, so the browser blocks the request for security reasons. Technically you can disable cors in most browsers with some extensions, and that would work (although I wouldn't necessarily recommend doing that, and if you do make sure to re-enable it when you're done).
Alternatively, if you own FrontendExpert, we released a version of this as a problem over there today with the same API (and requests to it will work from the FrontendExpert workspace).
To eliminate the problem of adding and removing event listener again and again what if we use redux or something like useContext ? Then i think the guesses data we need can be handed to keystroke handler function inside useEffect without rerenders, so ultimately allowing us to remove the dependency.
That's just shifting what triggers the re-render. useContext will trigger re-renders where it's used.
Great developer you are !
Made it look easy, subscribed.
The reason why you doing like className +='...' thing is it because the css specificity can render the color you want?
OK I will stop applying to jobs, 4 years into self-studying and just realized I totally suck.
Don't do that, this is definitely not a level you need to be at to get your first job. This would have taken me at least twice as long to do (if I could even do it) when I was first learning and applying to jobs 😊
really enjoyed it, teach us big brother
Thanks, glad you enjoyed it! 🙂
** Insert subtle plug for frontend interview prep course linked in description **
Failed to fetch api
Hey Conner! This is a really good video! I just sent it to my colleagues.
Now I'm even more interested in optimizing this addEventListener issue. Are you going to try to make a video with one of the solution?
Thing is many devs do not understand such things. If code works the job is done (no need to improve or optimize the code) - this makes me very sad.
I don't necessarily think it's a very big problem since the browser can add/remove event listeners so quickly, but the solution is essentially just to use useReducer, which would naturally remove the dependencies from the useEffect (because React automatically passes them to the reducer function which would handle the logic outside of the useEffect). I'm not planning on making a video on it, but we did add a similar problem to FrontendExpert with useReducer as one of the solutions 😉
I have been stuck on the same bug for 2 days and watched this vid and you had a syntax method I did not use that my boss did not catch either and now I can finally move on with my fucking project lmao.
Glad I could help 😂
Hey Connor, great video! Do you think you could share the project/source code with us? I would like to take look at the parts that I didnt understand too well.
Thanks! Unfortunately I don't think I actually have these files saved anymore 😔 I'll make sure to post the code for future videos.
We do have a similar version of this problem coming to FrontendExpert soon though 😉
Great tutorial. I would try also.
Okay. If these are the types of question for a Bachelor Graduate or Intern or Entry Level Front end. Then I'm dead. Hahahaha
Good explanation
Please look up documentation. Using Fetch in "useEffect" is an anti pattern, you should avoid it and handle it by events. Especially look up beta/preview documentation
I would actually disagree with the idea that using fetch in useEffect is an anti-pattern. Event handlers should usually be the first choice where they make sense, but not all data fetching happens in response to an event. In these scenarios, there really isn't another good place to do it without needing another framework on top of React. In this case, the data needs to be fetched when the component is first mounting. Since a component mounting is a React concept, there isn't going to be an event that directly maps to it and allows us to easily rerender the component when the fetch completes.
If this were a production webpage, then I would probably want the solution to be sent down with the initial page load, likely via server-side rendering. That said, for this problem in an interview context I think useEffect was the correct choice (although _maybe_ it would be slightly cleaner to add a cleanup to that effect to cancel if the component unmounts, but that is mostly a non-issue since the component cannot unmount in this simple page).
For reference, here is the page of the beta docs describing fetching data with useEffect:
beta.reactjs.org/learn/synchronizing-with-effects#fetching-data
I cant fetch the api. Its getting blocked by CORS policy
Could you do an angular interview?
Probably not. I don’t know it very well tbh
fantastic vid man
Great video! I just kept wondering: wouldn't the array deps issue in the useEffect with the eventListener handler be solved if the state was stored together, as in the same useState or in a useReducer? Since the issue seems to come from the relationship between the different state values and previous state values.
You could also "revert" the dependency by creating a custom hook that listens to every key press event, stores the pressed key info, and returns it. Then in the main component have a useEffect that runs whenever the custom hook returns a new value.
Yeah I think useReducer is the best way to solve this if it is a problem you are concerned about. The custom hook you described could probably work also, although I'm not sure that's much better honestly, just because it creates a lot of extra code.
Great Video! Just one question, what level would the task at hand be considered at, like would it be for an entry level react job or maybe higher?
Thanks! It really depends (I know, that's not a very satisfying answer lol). In general, I wouldn't think of problems as having a direct mapping to a level, but rather there are different expectations for different levels in how candidates will solve the problem. I'd say this is probably in the slightly harder realm of problems, mostly due to it's length and ambiguity. I don't think I'd expect an entry level developer to completely solve this in less than 45 minutes without hints, but it might still be a good question to ask them to see how they approach it and to give them room to really excel if they can complete it. On the other hand, I'd probably expect a more senior developer with substantial React experience could probably get through the problem, and they might excel further by bringing up additional concerns such as accessibility or how this could have been improved with server-side rendering.
@@ConnerArdman Thanks for the answer, I asked because I have been working with react professionally for 6 months now, and I was looking to change my job but I still have no idea what level my current react knowledge is at. So this answer gives me everything I was looking for. Thank you a lot. Keep up the great work!
Please do a coding round on Java also
"generate random number without stackoverflow" hahahahaha
You should never use open array and do plain java script in react without holding something in the state or in block of the code. Also, react code need to be declarative, no imperative code and poly fills in open block inside the component. Always use function and block scoped logic (helper, handler function). Also, never use == in react or even in every java script code, its always ===.
Next, to many if else if else running in to a if else hell. Use switch and code your cases if you have more then 2 if. In my react career, i never used for loop. Everything can be done in ES6+ way using higher order functions.
I'm not sure I follow what you mean by not using "open arrays" without state or the part about polyfills. If you're referring to the tiles array, there was definitely a cleaner way to do that, but I don't think the solution I gave was incorrect in any way, especially for a short interview.
As for the function and block scoped logic, I'm not really sure what you're referencing here either. The only code scoped outside of functions were constants, which is a generally accepted practice.
I agree about == vs ===, but there is a special case with == null. When you do val == null, it essentially is also checking for undefined. Some people prefer this while others don't, but it certainly is not incorrect. For instance, at Facebook my team (and I believe most if not all teams) preferred == for the null case.
For switch vs if/else blocks, I wouldn't fully agree with the idea that anything > 2 cases needs to be a switch. If the conditions are more complex than checking a single value, then switch cases can get complicated in my opinion, since they are meant to switch on possible cases for a single value. That said, my logic around the event.key probably could have been more readable.
As for for loops, I've used a few traditional for loops in production code but mostly agree that ES6 functions should be used instead in most cases. In the case of the tiles loop, it probably would have been better to make sure the guess string was 5 characters and use map as Clement suggested, but in the timed interview I just had to do what came first/most naturally to me.
There is nothing glaring bad about what he is doing for this type of interview scenario. Arrays are perfectly fine to use for operations that are needed for display logic or render logic, these aren't state, they need to be "computed" each paint. An improvement would be using useCallback to memoize handlers etc. Also memozing components that have heavy business logic needed in the renderer.
at the minute 25; when you use splice(0,-1), can we just copy currentGuess using spread operator and change with splice and set the state again?
Spread and Splice is a waste because we're using react state, it's better to use slice() because modifying the original string is bad practice in general for "immutable data handling". The ideal way is setCurrentGuess(prev => prev.slice(0, -1));
99% of coders can't do this in 45 minutes. What would be a reasonable result here? It can't possibly be you don't get the job because you didn't build a full game in under an hour is it?
A good interviewer isn't too concerned with your ability to finish some problem in an arbitrary time frame. They're assessing your problem solving skills, communication, code quality, and domain knowledge (in this case, React/JavaScript). Of course finishing the problem and reaching an optimal solution is always good, but oftentimes it isn't necessary. For example, I once passed an interview where my code literally didn't work, and I've failed interviews where my code worked perfectly.
But to more directly answer your question, I'd actually expect a large portion of more senior frontend developers with significant React experience would be able to finish most of this, if not all of it, in 45-60 minutes. On the other hand, a more junior developer or just someone newer to React likely wouldn't finish the whole problem. But of course the bar for them would be lower if given the same problem as someone more senior.
35:40 you must be a psychopath remembering regexp for anything. I'm googling that shit until I die.
I'm of course kidding about the psychopath! Really informative video!
I had to teach regular expressions in a class I TA'ed in college so it has always sort of stuck with me lol. And thanks, glad you liked the video!
great video again!
On the randomising part, why not use Math.random(words.length), i belive math.random can take a int and counts from 0? (just a refactoring thingie)
This is true in a lot of other languages, but JavaScript's Math.random() doesn't accept any parameters unfortunately.
you actually dont need a random word, just a random indexOf number
I use stackover flow 🤣😂 for random numbers 😂🤣
Can somebody please tell me the name of the font they are using in the editor?
Could someone explain isFinal={!isCurrentGuess && guess != null} not sure exactly how it works in determining that enter was pressed and the guess was finalised
why did the event listener have to be removed?
This is a really good question. React effects should always clean up after themselves. Each time the effect runs, a new event listener is created. But if the hook runs twice, we don't want two event listeners, so we need to remove the old one on cleanup before creating a new one. Additionally, if the component unmounts, we want to delete the event listeners so we don't have a bunch of useless event listeners when the user has navigated away from the portion of the application that needs them.
@@ConnerArdman thanks bud!
@@ConnerArdman Wow thanks for the really good explanation!
My man! Good job!
Can anyone explain why we need isGameOver, solution and guesses on the dependency array? Mine works well without them.
That was phenomenal! I am just a beginner web developer with 5 years of experience and no experience with React as it is quite intimidating for me but watching you just get this done is so inspirational.
For the instance where the solution is "HELLO" and the user inputted more than 2 L's, I think we can handle that by just counting the number of instances of that letter in the word? I don't know if that makes sense. Hopefully it does. LOL
Yeah if he asked me to handle that, that's pretty much what I would have done. I'm not sure of the exact rules actual Wordle uses, but it should just be some basic string manipulation.
Just Dive in its man I swear on me you won't regret it it's like putting Legos together typing it out didn't sound as fun as it did in my head but react is lit and its beginner friendly
5 years of experience is no beginner xd
It was amazing to watch this!! You completed the logic around 34 mins, honestly I would try to clean the code post that becz the soln you got is little messy 😅
Thanks for recording this, really helpful :)
I've never encountered this code
guess ?? ""
what does this do?
This is the nullish coalescing operator. If the value on the left side (guess in this case) is null or undefined, it returns the value on the right side (empty string in this case). If the value on the left is any value other than null/undefined, then that value is returned.
@@ConnerArdman Ohh I see. Got it! This is pretty useful ☺️
I'm wondering is there a ternary operator similar to this coalescing, that runs when value is true without the ":"
Sometimes I only want something like
true ? 'run this code' : ' '
I had to put empty string but isn't necessary. Idk if u get me but just wondering if there's something like that
@@pjguitar15 Yeah there is a ternary operator in JS that works exactly as you described.
const val = isTrue ? trueVal : falseVal;
@@pjguitar15 Maybe what you’re looking for is
booleanValue && doSomething();
doSomething is run only when booleanValue is true.
This expression does not use ternary operator though
@@pierre-jeanmartin5621 Yeah this is what I'm looking for actually. Didn't know it's a thing. I'm still a newbie, thanks for this!
Conner went from candidate to god at min 36:00
Lol I do not recommend using regex in an interview 😅
@@ConnerArdman why dont recommend using a regexp in an interview Conner? just curiosity
Bold move! Clement expression says it all.
@@juanmanuellamperti3058 it's not recommended because it's very easy to get wrong.
good one👍
Out of curiosity conner, how many years experience does Clement have? He's doing literally flying at crazy speed in working out the logic!
In case there is confusion here, Clement is the interviewer and I am the interviewee in this one. But to answer your question, Clement learned to code in 2016 at a bootcamp and got his first full time job in 2017, so he has ~5-6 years of coding experience. I first learned frontend development in college in 2016, then I learned React at a Facebook internship in 2018. So I have about the same years of experience as him coding in JS/React, but with just under 2 years of that being time spent working full time.
@@ConnerArdman So what if I just started learning React, any suggestions how should I approach? Any bootcamps? Your help is much appreciated. Please do reply.
@@piyushchopade7878 Learn some basic stuff like useState, useEffect and components. Get your hands dirty. Start making projects. Start with mini projects(for example minig games like Tic Tac toe), portfolio websites or trying to clone websites you like(for example Netflix, Spotify etc.). (I assume u have basic knowledge of JS)
Awesome video!
Thanks!
proo u r savage❤
bro this is wicked
bro u r crazy 😍🔥
Anyone know what theme is he using?