REAL React Interview Questions - Live Coding
HTML-код
- Опубликовано: 28 фев 2022
- Get the project code here: peterelbaum.gumroad.com/l/rea...
--
Follow Me Online Here:
🌏 My website/blog - peterelbaum.com
✉️ My newsletter (weekly on Sundays) - peterelbaum.com/subscribe/
🤓 My courses: peterelbaum.gumroad.com/
🗣 One-on-one mentoring - superpeer.com/peterelbaum
🐦 Twitter: / peterelbaum
💻 GitHub: github.com/elbaumpj
☎️ Office Hours: calendly.com/elbaumpj/saturda...
--
My gear:
Main Camera: amzn.to/2Tv1WBe
Tripod: amzn.to/2t570AH
External HD: amzn.to/2t1UphI
Memory card: amzn.to/2UEQfIn
Computer mic: amzn.to/2t7mUue
--
Who am I?
I'm Peter Elbaum, a software engineer living in Raleigh, North Carolina. I make videos about code, software engineering career development, and self improvement. I also have a newsletter (peterelbaum.com/subscribe) and tweet my thoughts on money, work, and being a great dev. Feel free to get in touch! 
Наука
I believe there are a few things that I would have done differently and I am sure that implementing them could win you bonus points:
1. One of the wrapping elements can be replaced with a element and then the handleLogin can be passed to the onSubmit prop of the form. The then becomes a type="submit" button and doesn't need the onClick prop.
2. Probably it makes sense to clear the error if the user starts to change one of the fields again.
3. Also, I would use a nulll value when there is no error - it makes more sense for it to be null as this means that there is no error. An empty string for an error might indicate an error that doesn't have a description or some kind of an unknown error. I know that probably won't happen in real life, but it's a good practice to differentiate between null and an empty string.
4. setLoading(false) can go at the bottom, after the try/catch, instead of repeating it in both the try, and the catch. There's no need to place it inside. Alternatively, it can go in the finally clause of the try/catch block.
5. I personally take naming very seriously. disableButton sounds more like a name for a function that when called would disable the button. Probably would be better to call it isButtonDisabled.
yeah you could also put the setLoading(false) at the finally section
but you're not allowed to add any HTML elements, so I think it's the same with updating existing ones?
I guess that's why it said "Not allowed adding HTML Elements"
Instead of adding setLoading false in two places in both the try and the catch, you could've added a finally block and added it to that.
Thank you Peter. I tried solving the challenge before you did it and was able to solve it in 16min 30s. I had a bunch of hiccups which slowed me down but I'm glad I was able to solve it.
This is so helpful!! I’m busy completing an advanced React course and this is such a great way to measure where I’m currently at! Please don’t stop making these vids, it has so much value!
Glad it was helpful! You got this!
really good content Peter..it is helping me a lot to learn front end technology because you deal with concepts and understanding more than routine tutorial walkthrough
Thank you! This is exactly the type of react content I’ve been looking for. Appreciate it
Glad it was helpful! :)
Awesome exercise Peter, thanks a lot!
thank you! this is super helpful :) especially the trick with 'disabledButton' variable, I've been using conditional rendering based on 'loading' value, but that's a lot more neat, thanks again!
Glad it helped! :)
After doing a few take-homes and live interviews lately; I've thought that it would make a cool youtube series/channel to collect them from devs doing interviews. Maybe with two formats. One video where it's new to the dev and then a second video with a "designed" solution.
Cool to see a little peek of your freelancing progress too! 👍🏼👍🏼
Interesting thought! May have to implement something like that...
great, I've go over the 15min but I got it. If you have more like this, it will be so helpful! thank u very much for sharing
I've been looking for a video like this, thanks
Glad you liked it!
Keep them coming Peter!
Thanks for your encouragement! :)
Thank you ... please make more videos on real react coding challenges
this was a quite chill and easy challenge, managed it in roughly 8 mins (including fixing the dependency tree which was outdated for today's standard due to node major version change)
for those wondering, just input these commands on first install if you're running node v17+:
>npm i
>npm audit fix --force
>npm update
then just do the normal npm start and it should run fine.
cool stuff that i find better than what was shown on vid:
i did the button disabled by:
which is way quicker than declaring a whole ass const.
and the div was only shown by doing this:
{error !== '' ? {error} : null}
which is the most appropriate way of doing what was asked.
great content, more interview live challenges like this are really helpful👍
You got it! :)
good to see these videos
Well done Man can you upload more React Interview Questions like that but more harder?
great video!
Hey Peter, Thanks a lot for making this video. I would request you to please release more such type of live coding vide. It is very useful. Once again Thank you so much.
Will do - thanks for watching!
I really like this exercise.
great video man thank you. all well and good!
Glad it helped!
Good one! Thank you for the content.
Glad you enjoyed it! :)
So good! Thank you@
Thank you. Your content is amazing! 🤗
You're very welcome! Thanks for your support :)
This is fairly simple and I can probably do it in that amount of time, but I'm sure to fail if you give me time limit and have someone watch me code. 😢
Hi, thanks for the video. I saw that you have 4 declaration of useState(). Would it be recommended that I use useReducer() for this problem instead?
Thanks a lot. Dope, spot on, practical.
You're welcome!
absolutely fantastice content. please make more
Thank you! You got it :)
Hey! Thank you for uploading this, very useful :) Could you please tell me where to find such challenges?
That was great!!
thanks!! :)
SetError("error, something went wrong") could be a quick interview fix I guess...
Awesome video mate , thanks
You're very welcome! :)
useState seems unnecessary for the email and password? why can't you just access the email and password inputs from the html element on button click?
Great video ❤️
Thank you!!
Awesome stuff! The zooming is completely unnecessary and super dizzling hahaha but cool stuff absolutely, thanks! And by the way, what software do you use to do that? Can it write on screen while you are recording?
will keep in mind for the next one. software = Loom (loom.com)
great!! thanks!
You're very welcome! :)
Amazing
Great, Thank you
Welcome 😊
this is amazing
thanks :)
Want more of this type of video
You got it! :)
interview for entry or junior right
Impressive.
How is the disableButton variable constantly being updated on input change?
Everything in component's body gets executed again on each state change
Just do final{setLoading(false)}
how do you start the project on the browser?
npm start :)
Why am I the only one who loves Blazor?! It's React but statically typed in so no more imports, boiler-plate, intellisense is kosher, etc..
I feel so alone :(
Is this junior dev interview?
Thankfully this is just a question. For me i won't recommend it on production.
Since if i'm correct you are re-running the state every time.
Also technically you can set the initial state of error to null or something.
Hooks are still cool? Or something changed?
grreat
Just a little suggestion.. Maybe do a little less zooming in and out of the screen, it can get somewhat frustrating especially on higher playback speeds.
Thanks for the feedback, will take this into account on the next tutorial video. Cheers!
what is a COOING challenge?
these are all things you learn day one
useState causes re-renders on every keystroke for email and password. Wouldn't useRef be better in this example over useState? Also, if keeping handleLogin inside component like that, I would place it inside a useCallback since you're re-rendering and redefining the function on every keystroke.
it doesnt matter react is faster than you think
One of the criteria is you can't use refs.
why not just put useCallBack and useMemo in everything? it's important to know when it's necessary. React is very fast and these small micro performance gains isn't worth the overhead of looking at all the useMemo and useCallBack and the potential bugs that might accompany it.
The question is fundamentally flawed, the correct html would be to encapsulate both inputs in a form element, and add an onSubmit event handler instead of onClick
This.
The problem is the interview question not the applicant.
This is why the interviewer should know what they are questioning.
Well, this takes like 20 minutes from me...
You have used disabled attribute and setting it using variable...cant we use something like events.target.disabled = true?...what is the difference in these 2 approaches
Bro, I think the reason he did it this way is because of its simplicity, the question had conditions where the button should be disabled, so he just created a variable with those conditions and passed it to already existing property (disabled) of the button. Its just simpler than having a eventlistener and passing the conditions into it, dont you think so? Im still learning so i might be wrong here
i don't know what position you have actually interviewed for, to get this kind of problem set, but from my experience, real life interviews are nothing like this. This is basic beginner stuff, that a technically versed guy, that played with React for a weekend would nail. Once again, not trying to be negative, just sharing my personal experience, both as interviewee and interviewer.
There's a lot of ways to interview, so it would make sense to me that our experiences aren't perfectly aligned.
This was a second step technical screening - there were some algorithms questions included with it, but I didn't include those as I'm just focusing on React here.
I like your solution but it is very verbose.
You took way longer to solve it, not only because you're obviously explaining what you're doing (which is expected in an interview), but because you're defining a lot of useStates.
I merged them all down into three single useStates and was able to do it extremely fast:
const [{ email, password }, setInput] = useState({ email: '', password: '' });
const [loading, setLoading] = useState(false);
const [{ hasError, errorMessage }, setError] = useState({ hasError: false, errorMessage: '' });
Then I handle the error like this instead:
function handleLogin() {
setLoading(true);
login({ email, password })
.then(() => {
alert('Successfully logged in');
setLoading(false);
})
.catch((e) => {
setError({ hasError: true, errorMessage: e.message });
setLoading(false);
});
}
So notice how everything is just bundled up together so I can use them as I please.
Now I despise JavaScript so I would've preferred for it to be in TypeScript haha.
His code is actually more readable and good luck doing that in 15 mins
Why inputs attributes are inside parenthesis {} and double quotes "". SHouldn't they be inside double quotes only ""?
Great man! Just a tip, I think you could use finally clause on try catch to setLoading() in it. So, it will be called every time independent of the result
nice catch !
@@thebattinson1278 thanks man 👊🏻
Great, thank you
Glad you liked it! :)