Dear Dan, Thank you for taking the time to meet with our team about the [role title] role at [company name]. It was a pleasure to learn more about your skills and accomplishments. Unfortunately, our team did not select you for further consideration. I would like to note that competition for jobs at [company name] is always strong and that we often have to make difficult choices between many high-caliber candidates.
How many companies would pass on Dan Abramov - THE Dan Abramov - based on his inability to quickly track down a rabbit in a contrived puzzle? This video *perfectly* captures the problems with front-end software interviewing today. Also, huge props to Dan for agreeing to do this. And for all he's given to the community. What a great guy. Also thanks to Ben. This kind of content can only improve the interview process in our field.
@@_nimrod92 It’s not that the world is dumb and we are smart. Companies would rather have a person who’ll execute on their roadmap than unrelated things. They’re less likely to fail that way. People who can create, like Dan Abramov, would rather work for a company than make their own. Because they don’t have money.
The questions isn't really about finding a right or wrong answer, it's about seeing how they problem solve. Do they just completely shut down? Do they break the problem up into smaller steps which can be tackled? Can they work through with the interviewer to sense through the problem? That's really what interviewers are looking for on these type of questions. Of course, it is massively contrived and they can almost feel like the interviewer is trying to show off how smart they are. It's a hard balance.
Technically Dan himself tweeted about it. he asked random people in the world to interview him and Ben was probably one of the guys who was like yeah cool i’ll do it
@@alimaxion2005 no, hes referencing one time when Dan called out one of Ben's videos mocking Angular saying something like it wasn't funny nor good for the programming community to have that kind of videos that only cause infighting
Huge respect for this man. He just came casually and did the very honest thing, knowing that he could get possibly judged by everyone literally for the div centering thing. Imaging having Dan as your co worker, I would never leave him as a colleague.
1:05 let & const question 3:15 when to use redux 6:40 What is dangerouslySetInnerHTML and when to use it 11:00 Center div 16:00 Binary Tree Question 21:05 Bonus Question 50:00 Bonus Question Best Solution
You can just see how excited Ben is for being able to have an interview with someone who created some of the libraries and frameworks he has used for so many years.
Sometimes I forget that not all frontend/js devs are necessarily well versed in CSS. I remember the time that this center was actually a valid challenge
Yeah, it greatly depends on what you are working with. And how many projects you do. In big projects sooner or later you have utility classes for most important things. Even if you written them yourself you just use them and forget what exactly was needed.
It wasn't that hard even in the past. If I couldn't use flexbox then I'd do it like this in CSS: html { height: 100%; } body { position: relative; background: red; height: 100%; } div { width: 300px; height: 300px; background: white; position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); }
@@brianruff3066 Yep, that was basically the solution, the only thing is that we had to use negative margin instead of translate. Also, we had to write JS to get the width/height in case it was not fixed =/
What an interesting video to watch. Really appreciative to have Dan Abramov willing to share his approach and thought process, as well as being willing to stumble with things on the fly - not easy to do at all! But seeing such an expert have some of the same stumbles as I do, as well as getting insight into a possible different approach to problem solving, is really valuable. Thank you both!
I love Dan... I love this interview. This has helped me so much with my impostor syndrome. I've been coding all my life and always dreaded algorithm questions in interviews. This truly helped me. ❤❤
Thanks for both of you guys creating this unique collaboration content. I currently work as a front-end dev, and Ben's contents (React, TypeScript, libraries, and the list goes on) had helped me a lot along the way when I was studying to change my career as a developer. And Dan is my role model. I'm taking the course "Just JavaScript" that Dan recently released, and it's fantastic. I'm more than happy to see you both here in one vid and wish you all the best. Hope to meet you Dan in the near future as dev-to-dev if my dream ever comes true. I'll keep on studying and never stop learning :)
The problem with tech interviews is that recruiters find problems like these (bunny) which are designed to gauge your thought process and instead using it wrongly to reject candidates. That's when you hear news like there's not enough talented developers, that's because you're gauging them wrong. If Dan can't solve this interview question then there's a good chance that a lot of bright minds might not be able to either, but that doesn't make them bad developers.
Been an engineer for 11 years and never encountered anything like this. I had a brief idea of how it could be solved, but I would probably have rambled on about it and bombed it. It's. It's not reflective of life as a software engineer.
Agree. Software developer in multiple languages for over 15 years here. Questions like this don’t really prove much - would you ask a mechanic to work through a very abstract scenario to prove they are a good mechanic? Nope. Programming is art and science…it takes time and many iterations to get to a solution to many challenges. Very rare you just come up with an immediate answer on the fly - takes hours to fully think things through before even coding some times. All this question does is show that the interviewers are novices and are likely seeking junior people as that’s what other companies do to hire their junior staff.
100%. The fact that Dan couldn't solve this is probably reflective of most of us here. And, also, Facebook would assess you on these questions during their process yet Dan works there and can't solve them himself so that's interesting to me. You're right though; they're gauging candidates on algs and ds that you wouldn't ever use in the day to day job. I've been in software for over 10 years and have never applied any of these dumb sorts of questions. When I was good at them I was studying them in university...11 years ago 🤣
Some people who interview could be looking for things that aren't entirely related to the passing experience. If everyone interviewed were to "pass", the one who brings up something about say Coffee (when no one else did) wins, I made it up but hope you all get the picture.
Finished the 'Just JavaScript' course, made by Dan, about month ago. It helps me a lot, I was surprised, how many missconceptions there were in my understanding of JS. Thank you so much Dan, for this course and for your blog! Thank you Ben, for the great guest!)
For the bunny question, you can do *slightly* better by doing a pass from index 1 to n-1 and then a reverse pass from n-1 back to 1. That gives you a worst case of 2*((n-1) - 1) = 2n - 4 guesses. Verifying this is left as an exercise for the reader.
@@Daniel-rp4sx What about this: same solution as explained in the video, but instead, start at the center and make the reverse pass, then return to one hole prior to the center, and pass to the right. The idea being that you have a 50/50 shot at correctly guessing the side that the rabbit is in. I figure this provides the same benefit of the video's solution, namely, the benefit you get from passing through odds and evens, that is: having a 50/50 shot at correctly guessing the "side" (odd/even "side") the rabbit is in.
Based on my experiences with interviews: 1. Dan would have already not been considered since it took him so long to center the div. 2. That invert binary tree function would error out when reaching a leaf node, and if by some miracle you had a binary tree that didn't have any leaf nodes, it would enter an infinite loop because there is no exit clause (checking for a null node).
If that is really the case then the interview system is very broken ;-) 1. It was obvious Dan actually knew how to center a div in a "modern" way. Obviously you only do html,body style once per project. 2. The function would break, yes. On any tree. So in practice it would be super easy to notice and to fix. BTW trees without leafs are not trees ;-) There would have to be a cycle in the graph. I'm guessing you know that, but just in case ;-)
@@eccenux i agree with this. interviewers dont tend to hyperfocus on edge cases that are common best practice unless that it the point of a trick question
@@eccenux Yes I know that trees without leafs don't exist and that's why I used the words "by some miracle". (maybe someone messed up the code and let one of the nodes point back to the root or something, but that's very silly and would never happen.... I hope). I agree with 1. But as I said, the issue was that it took him quite long. All of my interviewers consider it as something very basic that you should be able to do in negative 10 seconds.... I live in Beijing, China by the way so maybe that gives some context as to what expectations interviewers have. It's very competitive. You need to pretty much be able to create your own operating system just to land that job where you will mostly be googling and copy pasting stuff. Also, all of my interviews are in Chinese and my Chinese is quite poor (foreigner living here).
@@Voidstroyer it's quite a bad interview question. what did you just write someone off for? for something that they most likely google in seconds and then move on to the actual work that you're paying them for? like problem solving, understanding requirements etc. remembering how all of these "basic" things work in every language, stylesheet, framework etc just isn't as relevant as being able to find their documentation, understanding it and actually producing good implementations. In fact why even explain it that much, a guy on the react team of all things getting written off should already explain why it's a bad interview question
@@sqfzerzefsdf It's a problem with tech interviews in general. To be honest, a lot of these interviewers don't know what to ask, so they just use something as some leetcode problem because it's easy to do it that way. Of all the interviews I have done, only a handful of them actually asked me about my prior experience (I already had 3 years of experience when I did those interviews) and out of those, a few of them let me do some leetcode style questions before the actual interview. Some of them literally ask questions such as "What is the lifecycle of vuejs", which is something that you can literally google in 3 seconds. I dislike questions that have clear googleable answers. Leetcode questions aren't bad in that they can determine how the person thinks and the process of how they solve problems. But more often than not it is the interviewer that lacks the skills to do anything with that information. I also don't like not being able to google for answers during an interview, because you use it all the time during your actual job. I think that it should be allowed. Just don't ask stupid questions to which the answer can be googled.
In the last problem, you also need to check if the length of the array (holes) is even or odd. If the length is odd, you have to loop again with even indexes.
thank you, I know I was missing something because I started with an array of odd holes and the solution of the video doesn’t assure you the right answer.
@@MrThiteixeira if the bunny is at 3, you check 1 it moves to 2, you check 1 again, the bunny moves to 1, you check 2 for the first time and you've missed it.
@@MrThiteixeira you can omit pos=0. if you check 1 and then 1, then if the bunny were originally on 0, you would always catch it the second time you check 1. same for pos=n. once you do n-1 twice, you can stop searching.
The rabbit problem, it can be simplified down to 3 states as indexes: h, h+1, or up to h+n where h is the first index and n is the total number of holes minus 1. We can check for the rabbit at h. If the rabbit is at h, done. If the rabbit is at h+1, it can either go to h or h+2, so we check h again. If the rabbit isn't at h we know that the rabbit must be in h+1 or h+n, so h+1 becomes our new h while h is less than n. Basically just check each hole twice from the first hole, and you find the rabbit in less than 2n tries. EDIT: This assumes the rabbit can't jump from the first index to the last index and vise versa EDIT 2: This solution breaks at when the rabbit starts at h+3 as there is no first index the rabbit is forced against: | is a guess, ^ is the rabbit, & is the caught rabbit. h+0 h+1 h+2 | ^ | ^ ^ | & h+0 h+1 h+2 h+3 | ^ | ^ | ^ | ^ ^ | ^ |
Yes! I figured it out within a few minutes: start at pos=0 and check each hole twice. If wrong on the first try, rabbit is to the right. Check again, win or rabbit is still to the right. That way you are "pushing" the rabbit towards the end Probably much simpler to code
I thought this at first too, but if the rabbit starts at h+2, you check h and the rabbit moves to h+1, you check h again and the rabbit moves to h, you check h+1 and you've missed it.
@@tobyealden7263 You'll miss it the first time you check h+1, yes, but the second time, the rabbit has to jump back from h to h+1, so you won't miss it. This is assuming it can't jump from the first index to the last index. Remember that h+2 is just (h+1)+1. EDIT I've just tried it out and yes you're correct, but it's at h+3 it breaks, not h+2. | is a guess, ^ is the rabbit, & is the caught rabbit. h+0 h+1 h+2 | ^ | ^ ^ | & h+0 h+1 h+2 h+3 | ^ | ^ | ^ | ^ ^ | ^ |
@@jdpt- Yes, you're right in that edge case where the rabbit is at h (i.e. has nowhere else to go on the second check). So instead consider you start at h and the rabbit is at say h+4. You check h, rabbit moves to h+3, you check h again, rabbit goes back to h+4, you: h+1, rabbit: h+3, you: h+1, rabbit: h+4, you: h+2, rabbit: h+3, you: h+2, rabbit h+2 - and you've missed it. The subtly is that the rabbit can jump into the hole you just checked.
I solved the rabbit problem a little bit differently: I check the holes one by one sequentially starting from the 1st hole, but I stop before the last hole. I don't check the last hole at all, instead I check the last-1 hole again and then I start to check the holes sequentially backwards. If I reach the 2nd hole, then I'm 100% found the rabbit. How did I come to this solution? My idea was to take the worst case scenario: checking the 1st hole, but the rabbit is in the 2nd hole. Then I check the 2nd hole and the rabbit jumps to the 1st hole. Then I check the holes sequentially and the rabbit "follows" me until the last-1 hole. If I check the last hole then the rabbit can swap again the same way it did at the beginning. By skipping the last hole check and instead checking the last-1 hole again, I can know for sure that the rabbit is not in the last hole, otherwise with this 2nd check I would see it. If the rabbit followed me all the way, then it should be in the last-3 hole when I check the last-1 hole the 2nd time. If I start to go backwards from here and the rabbit would still follow me, then we would end up in the same hole at the next stop. But I'm thinking of the worst case here, so I assume the rabbit is running away from me at this point. If the rabbit would turn back at any point during this backwards chase, then we would end up in the same hole at one point. If I chase the rabbit all the way back to the 1st hole, then it has no place to go, but to the 2nd hole, which is my next hole that I check, therefore I don't have to check more holes.
I compared this to the solution shown on the video. I ran both solutions 100k times with a new random position on each iteration and on a set of 100 holes. Your solution found the rabbit with an average of 98.5 attempts, and the video's solution had an average of 99.6. Both solutions had a 100% success rate if anyone's wondering.
3 ปีที่แล้ว +1
@@Italiafani can you check this solution with starting from the second index instead of first? I wonder if it's going to improve
3 ปีที่แล้ว
That's exactly how I imagined and found the same solution. Glad I found you in the comments and see you already explained it better than I'd haha
i was thinking of just starting from zero and check each hole i step on twice until n-1 and if i didn't find it until then i will find it at n-1 since he jumps back because he's at the end.
One thing everyone seem to miss out, you have to have an exit condition on the recursive function call, right? Like checking on node.left exists before calling the invert function, since it would just be called infinitely often
Since he didn't check for null/undefined, the function will be halted by an error. invertTree(node.right) will never be called because an error will be reached when invertTree(node.left) recurses to the bottom of the tree and finds that it can no longer access 'left' of undefined/null. He's very close to the solution... he would surely realize what is needed if he were to run it.
that is a huge mistake, I am impressed this guy(interviewer) did not care about it, one of the main features of recursion is the stop condition no matter the programming language..
Regarding the rabitt problem, you can use four pointer starting from the corners to the middle (two couple of poninters) then iterate each pair of pointer until they find each other, in that way you can find the rabbit in a O(n/2) complexity, I wonder if we can do it in log(n), not sure about that
8:50: 'At Meta ... there's a match for dangerouslySetInnerHTML someone from security will be tagged on the PR for review' A lot of React's design decisions make more sense in the context of building facebook
This was amazing to watch. I somehow had the impression that seniors or highly highly experienced programmers have no problem figuring out almost anything and that brought up some anxiety in me because I know I struggle with some aspects of programming.
@@LuckyTechy dude this guy is literally a god full stop, lol. people so gifted often dont even think about the easy parts to an answer, because it is to trivial to them. This guy is the head behind react, cra, redux, and hugely influencial in the entire js eco system.
Great video, that bunny question was really something. When I heard the hint I thought about the same idea but the implementation was a bit different. I thought to double check each even number (skipping odd ones), and if no luck then start again but double check odd numbers (skipping even ones). Not a huge difference but I feel a bit proud of myself))
my first idea was to double check every number, that should work but checking even numbers first and odds second is better, but does not reduce time complexity, because the worst case is still the same.. am i right?
@@vitorwindberg4212 Doesn't work. The rabbit starts at 2, you double check 0, then the rabbit jumps to 0 before you check 1. I do think there is a single pass solution but it is more complicated than this.
Well, with the bunny you can just keep looking in one hole (the best choice is the middle one - 49). Eventually it will get there. Yes, I know it’s O(Infinity), so what? 😜
Full disclose, only started watching the rabbit question. Initially, I thought checking the same index twice before moving to the next one would work, but the rabbit could be on the adjacent index when we check a particular index twice and jump over to the one we just checked, and we would miss the Rabbi. Now, the terms have changed and we know the rabbit starts off on an even index. In that case, start sweeping from 0 to n, and we should catch the rabbit. If the rabbit starts on an odd index, start from 1. This is provided the array is not looping, and once the rabbit reaches each end of the array, it has to jump back.
Yes you can solve it if you check the same index twice, but start at an edge So check twice in 100.. if not found then the rabbit has to be at 99 or less Check twice at 99.. has to be at 98 or less.. etc til you find it.. Probably not very efficient but it took me less than a minute of thinking to come up with this? Am I hired? 🤩
@@RobertFranksPlus initially, I thought the same too. But it won't work. Say the rabbit is at 98 and we checked 100, no rabbit. Then the rabbit moved to 99, and we checked 100 again, no rabbit. After that, the rabbit moved to 100, and we checked 99. No rabbit. So even if we do a sweep of the array, the rabbit can still jump through. But since we know the rabbit starts on an even number, we can start on the first even number index of the array and do a single sweep and always find the rabbit because we are looking for where the rabbit is.
@@RobertFranksPlus That works if the rabbit is trapped at the end. Say the rabbit is at 6. We check 4 and the rabbit move to 5. We check 4 again and then the rabbit moves to 4. We check 5 and the rabbit is 4th hole. The rabbit has been missed.
@@ImAfricanJesus exactly. Double checking an index is bit of a luck. But starting with an odd index when the rabbit is on odd index or even index when rabbit starts on an even number will surely catch the rabbit in a single pass (most of the time, before even completing a single sweep).
It is completely normal not to be able to solve a fairly difficult problem right away at an interview. Sometimes it takes hours to think a problem through and then code it up, let alone most of people don’t perform yo the beat of their abilities under pressure of the moment. That’s exactly why we have SE shortage. The interview process is completely broken.
I got a rejection from a big tech company once and one argument was “not implementing let and const in my code correctly”, meanwhile THE Dan Abramov: “it depends, doesn’t matter that much”… tech interviews are broken!
Absolutely. Every interview is judged subjectively, based on the peccadilloes of the interviewer(s). I'm of the mind that if there is a coding exercise, I probably won't participate. But if I do, I'd like to make sure they are setting aside time for us to review the code together, so they can ask questions, not just make snap decisions based on arbitrary standards/preferences.
With all respect, I don’t think dans approach of “not caring” is good. If you only use let when you reasign, it improves readability, you can infer things without having to read the entire code.
18:38, not correct. Recursion has to be called only if branch != null, otherwise it will throw error something like "error trying to access property left of null"
I teached programming in university for 5 years, I ended up seeing 3 basic rules for recursion to work: 1. There needs to be a recursive call. I.e. call same function inside function you are defining. 2. The call needs to be inside a conditional: if, where, ternary op, try catch, whatever 3. The recursive call needs to have different arguments than the received, and each call should make the conditional closer to branch out of the recursive call, thus ending recursion, reaching the "base case"
Hey Ben, your purely intellectual bunny problem actually got me thinking about a solution to a graph problem I've been stuck on for like 2 weeks (not joking). So, thanks I guess. Also, you might find this funny but Dan inverted the tree real quick then took longer on the bunny problem. My situation was different: it took me a while to find a way to invert the tree using another method, but I solved the bunny problem in like a minute, with O(n^2) using a different method. I guess this is a reminder that if developers stick together and apply ourselves in sync, we can solve pretty much anything, given enough time. Glad to be a sub! Keep the excellent content coming, my guy 🎊🏆☮️🙌🏽
best way to center an element "smack in the center" of the page (center both vertically and horizontally): 1. make sure the containing element has the entire width and height of the page (100vw, 100vh) 2. set the display property of the containing element to "grid" and set the place-items property to "center" i mean that's it ig hope it helps you dan :/
100vw breaks on desktop devices (sets to entire viewport width, not viewport width minus scrollbar, so you get ugly horizontal overflow), 100vh breaks on mobile devices (doesn't factor in top and bottom browser UI that hides and shows during scroll)
Ben, nice interview. Would have been also nice to hear him answer more short junior-middle questions, like "const vs let", to know what experienced people like Dan would say.
On the bunny question, couldn't you find it in one pass by ''forcing'' an initial state on the bunny? If I first check at 1 -> the bunny could be at 0 or 2+ Check at 1 again -> now the bunny could be only at 3+, if it were at 0 or 2 and it jumped to 1 then its over Now knowing that the bunny is forcibly at 3+, the odd naive approach should be enough to find it, should it not?
Wrong my man! Consider rabbit starts at position 4. Step 1, check at 1: Bunny moves to 3. Step 2, check at 1: Bunny moves to 2. Now knowing your assumption for step 3 is that rabbit is forcibly 3+. But as seen in this one, it is not. Step 3, check at 2: Bunny moves to 1. And you miss it for rest of the game. Similarly it could happen for the following steps and the concurrent positions as well. That's the flaw in your logic, respectfully. :)
watching him struggle to center the div but then solve the binary tree inversion like that was surprising. he is obviously a skilled dev, im sure he doesnt write much UI
What this tells us and should tell every interviewer is that TIs are not effective tools for finding talent. Also this was such a great kindness for Dan to allow himself the be seen as a human being. It'll have zero effect on his career but could allow much more junior developers to see themselves in a better light.
This was really amazing. The bunny question seemed really tricky. And again, it's really looking at a person's thought process that matter in those types of questions. Dan is inspiring
I always use const. If the situation arises where I need to reassign the value, I first think if I should be doing that… or if another approach is better.
29:48 I spent 20min drawing out the scenarios and with a field of size 4, the guesses you make are 1,2,2,1. With a field of size 5, the guesses are 1,2,3,3,2,1. With field of size 6, it's 1,2,3,4,4,3,2,1. While I don't understand it deeply enough to give a formal mathematical proof for why it works, I would extend this to the solution where you guess 1,2,3,4....,98 and then 98,97,96,...,1. The way it works is when you guess upwards in index, it forces the possible positions of the rabbit to be in "alternating/interleaved" positions (possible locations of a rabbit can not be next to each other). Then as you guess from 98 back to 1, it takes advantage of those alternating positions and eliminates them 1 by 1. That's terribly explained - easiest to show drawn. This whole thing is possible due to the asymmetry of the boundary condition - when you guess 1, you eliminate the possibility of the rabbit being at index 0 after it made the jump. Then when you draw out the possible positions of the rabbit as you guess 2,3,...N-2 and you see that "alternating/interleaved" pattern emerging. Edit: saw the even/odd pass solution. I think it's very similar but it resulted in a good theorem: start counting from odd/even to catch odd/even rabbit.
You can also just check twice on each hole. Then you don't skip the rabbit, if it jumps to the hole where you previously were. (just swapping the loops. Same code, slightly different idea)
Maybe explained it wrong: rabbit is on 3, u guess 1. rabbit jumps to 2. u guess 1 again (rabbit is on 2), rabbit jumps on 1 after that guess. u guess 2 now (just each hole twice), but rabbit is on 1 and u missed it
@@tobiashaefermann okay, but then when you guess 2 while it’s at 1, it can only jump to 2 right? so on the double check it should be there… unless it can hop from 1 to 4
just check second position (index 1) twice and keep going... Check index 1 two times, if you didn't find him that means the rabbit is definitely not at position 0 or 1. Then check index 2, 3, 4, n and you will squeeze the rabbit to the end or catch him early.
My approach to the bunny one (paused the video): - Say you're going up 1 -100, check the second hole twice, so if it was in the first hole, it could only have gone to the second (then you'd have found if) you didn't find it, but you eliminated the first hole, now your chances are 1/99 Keep checking the holes in order, basically cornering the bunny, but check the penultimate hole twice again.
i thought of the same thing but if bunny starts in hole 4, checking hole 1 first time, bunny could go to 3, the second time, could go to 2, then when you move on to 3, bunny could hop to 2 :(
@@mohamedchalal4518 I think you're right, there is always going to have the possibility thay the bunny can give me a slip, it just needs to be in front of me
Dan looks like a very humble man. This is how we code. In interview skills test, I still frequently see some weird JS questions that supposed to test my skills. But those are generally not real-life problems that we need to solve. Just some tricky questions to confuse people I think :)
I think the solution to find the rabbit is start at number 1 and double check. for example, if the rabbit is at 0, then I select 1, the only move it has is go to 1, and then i select again 1. If the rabbit is at 2, then I select 1, if it goes to 1 i select again 1, if it goes to 3, I select 1 and in the next move I select 2 and repeat the process.
I think it won't work Let's say you rabbit is at 3 You check 1, rabbit jumps to 2 You check 1 again, rabbit jumps to 1 but now your index is pointing to 2
I dunno what Dan works on exactly but I feel like he is no longer FE developer but a dev who works on FE technologies Also I found it a bit cute when he said "we, at Meta..."
Loved this. Now I realize I'm not so bad. I figured this would be one of those anomalous situations where the interviewee doesn't hesitate at all, like in that one video of the genius kid who only studies algorithms/DS (with Clement).
@@brianruff3066 No because I was being sarcastic. He is my father. If I was half as smart as him I'd be doing more complex things than centering divs. I struggle with medium difficulty and sometimes easy difficulty problems on leetcode. Help.
@@mrdoner3451 It's okay. It's not like those questions truly reflect real life anyway. They are still fun to solve and if you can do them they will get you into some very high paying roles. Just keep working at them, and eventually, you'll get promoted. To be fair, the other questions were probably easier than medium-level Leet Code problems, so you still have that going for your at least.
I had a different solution to the bonus. Start at 0, and hit each index twice before incrementing, this way if the bunny moves closer, you catch it, and if it moves further, you corner it at the final hole until it has no option but to move closer to you catch it.
Yes, exactly, although you don't need to start at 0, you can start at 1 because if the bunny is on 0 it can only jump to 1 and you'll get it the second time.
i was thinking this as well, but what if the rabbit is at 3 and you check 1, rabbit moves to 2, 1 again, rabbit goes to 1, and then you check 2 missing the rabbit.
Ye this won’t work, you would still need to run it twice starting at odd and even, using twice as many guesses as the videos solution. The solution in the video is the best way
I just don't get 1 point of the "invert binary tree" question: what happens when left or right are null? Iknow that the algorithm is right, but there's no base of the recursion and I believe is a must have in this type of question
I believe there is a "slightly more efficient" approach if you are allowed to make the same guess twice. Currently, you need to guess #evens + #odds (100+99) = 169. If you instead change the algorithm, you start on hole 1 (assuming there is hole 0), and guess each hole twice, and move forward, you only need to guess up until the second last hole (98), which means (100-2)*2 = 196. In other words: 1. Guess 1 -> hole 1 2. Guess 2 -> hole 1 3. Guess 3 -> hole 2 4. Guess 4 -> hole 2 ... 195. Guess 195 -> hole 98 196. Guess 196 -> hole 98 You are guaranteed to find the rabbit this way, any thoughts?
Very interesting interview! Anyway I have a question: was that div really pixel-centered (at 15:30)? The body has some default margins and it pushes the width/height in offset: in fact we can see the horizontal and vertical scrollbars. Just setting body "margin: 0" will solve it. Actually, in this way we don't even have to set body's width/height, but only put #root's width/height to "100vw/vh". Is this right? Also, about the "invertTree" function (at 20:50), don't we have to check if the current "node" is null? Since when a leaf is missing it's null, the first line would be to check this and return if it's null, e.g. "if (!node) return". Just very small doubts, let me know if this is correct or I'm going crazy.
The last node will still have a value. So it will have {value: 'something', right: null, left:null};. So if(!node) won't work. You have to check if both right and left are null.
51:51 I don't think it's the only way. Will this not work?: you start from index 1 and check each index twice ( 1,1,2,2,3,3,4,4,...)? They are very similar solutions though, except you don't need to check hole at index 0.
@@pab_loq Yeah. But you have to start from index 1. If you start from 0, you can miss the rabbit (As someone showed in another reply): (1) _ _ _ R (you pick the first) (2) _ _ R _ (you pick the first again) (3) _ _ _ R (you pick the second) (4) _ _ R _ (second again) (5) _ R _ _ (you pick the third) (6) R _ _ _ (third again… etc.
This won't work because the rabbit can still slip past you. Imagine if the rabbit starts at 3. You check 1 and the rabbit jumps to 2. You check 1 a second time and the rabbit jumps to 1, but your next check is 2.
@@johnsontinuoye8428 Even if you start at 1, you can miss the rabbit 0 1 2 3 4(R) - initial 0 1 2 3(R) 4 - you pick 1 0 1 2(R) 3 4 - you pick 1 again 0 1(R) 2 3 4 - you pick 2 and so on
I could be wrong but the proposed solution to the rabbit problem only works if there are an even number of holes or if the rabbit starts in the same whole at the beginning of each pass. Failure: With 3 holes if the rabbit starts in index 1 and you start your guess with index 0, the rabbit then moves from index 1 to 0. You guess index 1, the rabbit moves from index 0 to 1, you guess index 2, the rabbit moves from index 1 back to 0. End of iteration. Now starting next iteration with index 1, the rabbit is still on index 0 from previous iteration. You guess index 1, the rabbit moves from index 0 to index 1. You now guess index 2, Rabbit moves from index 1 to index 0 (or 2, doesn't matter) End of second iteration, rabbit not found, Game Over! Solution: Iterate the number of holes 1 time but check each hole twice, one right after another. 0,0,1,1,2,2... Because the rabbit has to move and only moves one space you will can't miss it. Rabbit starts in hole 1. Check 0 rabbit moves to either 0 or 2. Check 0 if rabbit moved to zero rabbit found if not. If rabbit had moved to two rabbit will move to 1 (if only 3 holes). You just checked 0 twice so now check index 1. Bingo! Rabbit found! Even if the rabbit moves away every time you will eventually pin the rabbit at the last or second to last hole. (Correction) This method is also prone failure. See reply's for why. The correct answer is: If there are an odd number of holes you should start your iteration on 0 both times. Even number of holes start on 0 and then 1. See Reply's for why.
It was pointed out by @Moshin Amjad that the double check solution can fail as well. I think the best solution would be to use the proposed solution in the video but if the holes are an odd number, then start on 0 in the second iteration instead of 1.
I'm curious now: "Iterate the number of holes 1 time but check each hole twice, one right after another. 0,0,1,1,2,2..." Couldn't you still miss it because it could move over 2 positions during your two checks? For instance, if you check hole 0 twice (0,0) and the rabbit is initially at hole 2, couldn't the rabbit move into position 0 after you check it the second time? (brackets are checks) Check position 0: [-] - R 0 1 2 Check position 0: [-] R - 0 1 2 Check position 1: R [-] - 0 1 2 Am I thinking about this correctly?
What I thought was, make 2 passes like they said. But in both occasions check only evens. Cause in the first pass if the rabbit is originally in an even position you'll find it. Otherwise it will jump into an even position so you check again. It's basically the same idea.
21:10 - The problem is quite simple. The rabbit knows where it is at all times. It knows this because it knows where it isn't, by subtracting where it is, from where it isn't, or where it isn't, from where it is, whichever is greater, it obtains a difference, or deviation. The guidance sub-system uses deviations to generate corrective commands to drive the rabbit from a position where it is, to a position where it isn't, and arriving at a position where it wasn't, it now is. Consequently, the position where it is, is now the position that it wasn't, and it follows that the position where it was, is now the position that it isn't. In the event of the position that it is in is not the position that it wasn't, the system has required a variation. The variation being the difference between where the rabbit is, and where it wasn't. If variation is considered to be a significant factor, it too, may be corrected by the GEA. However, the rabbit must also know where it was. The rabbit guidance computance scenario works as follows: Because a variation has modified some of the information the rabbit has obtained, it is not sure just where it is, however it is sure where it isn't, within reason, and it knows where it was. It now subracts where it should be, from where it wasn't, or vice versa. By differentiating this from the algebraic sum of where it shouldn't be, and where it was. It is able to obtain a deviation, and a variation, which is called "hole".
the creator of redux taking so long to center a div gives me so much hope in my skills
😂😂
Hahahaha lol for real 😂
Ben had a shit-eating grin on his face.
😂😂😂
@Dyanosis He's been a senior fe engineer for years, he probably has a lot of experience with css
Dear Dan,
Thank you for taking the time to meet with our team about the [role title] role at [company name]. It was a pleasure to learn more about your skills and accomplishments.
Unfortunately, our team did not select you for further consideration.
I would like to note that competition for jobs at [company name] is always strong and that we often have to make difficult choices between many high-caliber candidates.
"...not enough positive signaling"
We cannot provide further feedback due to company policy.
that *Unfortunately* it scares me everytime
Unfortunately, we need someone with 15 years of experience with React.
@@fyfoh Heard that joke before, with different language context, can't remember which one tho...
Wow, this Dan guy really has a bright future in programming if he keeps it up. Great job.
someone is goin to get r/wooosh
Loool he made future 😂
Are you serious,?? The guy co created redux
@@muhammadssempala5143 First of all you just got woooshed, second of all Dan co-created JavaScript when he was..4? I think you mean Redux 🤣
Lol, he made Angularjs
How many companies would pass on Dan Abramov - THE Dan Abramov - based on his inability to quickly track down a rabbit in a contrived puzzle? This video *perfectly* captures the problems with front-end software interviewing today.
Also, huge props to Dan for agreeing to do this. And for all he's given to the community. What a great guy.
Also thanks to Ben. This kind of content can only improve the interview process in our field.
Companies don’t want a Dan Abramov. They want the kind of person who has really basic stuff memorized.
@@fr5229 i hate that you’re right
@@fr5229 Exactly so let those companies fail, the certain companies that are smart would snatch Dan in a heart beat.
@@_nimrod92 It’s not that the world is dumb and we are smart. Companies would rather have a person who’ll execute on their roadmap than unrelated things. They’re less likely to fail that way.
People who can create, like Dan Abramov, would rather work for a company than make their own. Because they don’t have money.
The questions isn't really about finding a right or wrong answer, it's about seeing how they problem solve. Do they just completely shut down? Do they break the problem up into smaller steps which can be tackled? Can they work through with the interviewer to sense through the problem? That's really what interviewers are looking for on these type of questions. Of course, it is massively contrived and they can almost feel like the interviewer is trying to show off how smart they are. It's a hard balance.
The madman did it. He got THE Dan Abramov, defender of AngularJS, to come on the show.
Lol, it's React Js
Technically Dan himself tweeted about it. he asked random people in the world to interview him and Ben was probably one of the guys who was like yeah cool i’ll do it
@@alimaxion2005 no, hes referencing one time when Dan called out one of Ben's videos mocking Angular saying something like it wasn't funny nor good for the programming community to have that kind of videos that only cause infighting
Huge respect for this man. He just came casually and did the very honest thing, knowing that he could get possibly judged by everyone literally for the div centering thing. Imaging having Dan as your co worker, I would never leave him as a colleague.
when you are making millions of dollars, you tend to not care about how other people look at you.
I also assume Dan spends the vast majority of his time working on logic and not styling so can't judge him too much.
1:05 let & const question
3:15 when to use redux
6:40 What is dangerouslySetInnerHTML and when to use it
11:00 Center div
16:00 Binary Tree Question
21:05 Bonus Question
50:00 Bonus Question Best Solution
Thank you
👏
Thanks
47:18 Dan on Slack: "sorry guys meeting canceled I have to catch a damn rabbit"
Not only catch but also squeeze it
@@randerck2661 😭
Gotta give Dan credit for this. Takes balls for a person of his reputation to get on stream an do this! 👍
Gives me hopes that anyone can be a senior dev at a big tech company these days.
I do think his answers lacked any technical understanding of the questions though which is weird given his job background.
@@juliansoto2651 If you can deliver value for sure, Dan sure has.
You can just see how excited Ben is for being able to have an interview with someone who created some of the libraries and frameworks he has used for so many years.
Man! For 3 seconds I though you were the real Bill Gates. I was like.. OMG! kkk
Who else here read and interpret his name as Bill Gates after seeing his picture
Pretty cool 😎
Ben: There is a library called 'redux',
Dan: "Hmmmm heard about it"
Mark: "Redux Toolkit is pretty awesome"
Also Dan: Redux? I never use that stuff
This is funny haha
😂😂
One thing I learned from this video is ... well I didn't learn anything. This guy fell short of my expectations tho.
Now get one of the founding devs of Angular and make them do a React interview
Could you call out at least one of them?
they probably write better React code than you
it's a joke cause Ben jokes a lot about Angular being a shit framework
The respect I have for Dan is huge. Can you see how humble and down to earth he is
Wow, a professional mic makes so much difference.
Well done, Ben!
When Ben leans back he is a bit hard to hear, whereas Dan's volume always stays stable. Personally, I prefer the latter.
@@thesunrock only u
Sometimes I forget that not all frontend/js devs are necessarily well versed in CSS. I remember the time that this center was actually a valid challenge
thats why i ride with c/c++ for a while, before applying
learning and implement dsa with weird language like js made my head spinning
Yeah, it greatly depends on what you are working with. And how many projects you do. In big projects sooner or later you have utility classes for most important things. Even if you written them yourself you just use them and forget what exactly was needed.
It wasn't that hard even in the past. If I couldn't use flexbox then I'd do it like this in CSS:
html {
height: 100%;
}
body {
position: relative;
background: red;
height: 100%;
}
div {
width: 300px;
height: 300px;
background: white;
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}
@@brianruff3066 Yep, that was basically the solution, the only thing is that we had to use negative margin instead of translate. Also, we had to write JS to get the width/height in case it was not fixed =/
What an interesting video to watch. Really appreciative to have Dan Abramov willing to share his approach and thought process, as well as being willing to stumble with things on the fly - not easy to do at all! But seeing such an expert have some of the same stumbles as I do, as well as getting insight into a possible different approach to problem solving, is really valuable.
Thank you both!
Recruiters watching this are gonna start asking the Rabbit question because Dan and Ben did it.
I love Dan... I love this interview. This has helped me so much with my impostor syndrome. I've been coding all my life and always dreaded algorithm questions in interviews. This truly helped me. ❤❤
Thanks for both of you guys creating this unique collaboration content. I currently work as a front-end dev, and Ben's contents (React, TypeScript, libraries, and the list goes on) had helped me a lot along the way when I was studying to change my career as a developer. And Dan is my role model. I'm taking the course "Just JavaScript" that Dan recently released, and it's fantastic. I'm more than happy to see you both here in one vid and wish you all the best. Hope to meet you Dan in the near future as dev-to-dev if my dream ever comes true. I'll keep on studying and never stop learning :)
The problem with tech interviews is that recruiters find problems like these (bunny) which are designed to gauge your thought process and instead using it wrongly to reject candidates. That's when you hear news like there's not enough talented developers, that's because you're gauging them wrong. If Dan can't solve this interview question then there's a good chance that a lot of bright minds might not be able to either, but that doesn't make them bad developers.
Been an engineer for 11 years and never encountered anything like this. I had a brief idea of how it could be solved, but I would probably have rambled on about it and bombed it. It's. It's not reflective of life as a software engineer.
Agree. Software developer in multiple languages for over 15 years here. Questions like this don’t really prove much - would you ask a mechanic to work through a very abstract scenario to prove they are a good mechanic? Nope. Programming is art and science…it takes time and many iterations to get to a solution to many challenges. Very rare you just come up with an immediate answer on the fly - takes hours to fully think things through before even coding some times. All this question does is show that the interviewers are novices and are likely seeking junior people as that’s what other companies do to hire their junior staff.
100%. The fact that Dan couldn't solve this is probably reflective of most of us here. And, also, Facebook would assess you on these questions during their process yet Dan works there and can't solve them himself so that's interesting to me. You're right though; they're gauging candidates on algs and ds that you wouldn't ever use in the day to day job. I've been in software for over 10 years and have never applied any of these dumb sorts of questions. When I was good at them I was studying them in university...11 years ago 🤣
Most of bright minds can’t under pressure of the moment.
Some people who interview could be looking for things that aren't entirely related to the passing experience. If everyone interviewed were to "pass", the one who brings up something about say Coffee (when no one else did) wins, I made it up but hope you all get the picture.
omg i never thought i'd see dan abramov center a div
ben you are amazing, i love your style, and i also love dan and his great overreacted blog!
Trying to place div in the center, took almost 5min from one of the famous developer, yeah, it's better than hundreds of motivation videos ;)
Wow that's a truly special guest.
No way! Loved his Just JavaScript course!! Highly recommended!! Thank you for doing this!
Finished the 'Just JavaScript' course, made by Dan, about month ago. It helps me a lot, I was surprised, how many missconceptions there were in my understanding of JS. Thank you so much Dan, for this course and for your blog! Thank you Ben, for the great guest!)
From where can I get that course?
can I get link of that course please ?
For the bunny question, you can do *slightly* better by doing a pass from index 1 to n-1 and then a reverse pass from n-1 back to 1. That gives you a worst case of 2*((n-1) - 1) = 2n - 4 guesses. Verifying this is left as an exercise for the reader.
this isn't a valid solution
@@Daniel-rp4sx What about this: same solution as explained in the video, but instead, start at the center and make the reverse pass, then return to one hole prior to the center, and pass to the right. The idea being that you have a 50/50 shot at correctly guessing the side that the rabbit is in. I figure this provides the same benefit of the video's solution, namely, the benefit you get from passing through odds and evens, that is: having a 50/50 shot at correctly guessing the "side" (odd/even "side") the rabbit is in.
that's still O(n)
Based on my experiences with interviews:
1. Dan would have already not been considered since it took him so long to center the div.
2. That invert binary tree function would error out when reaching a leaf node, and if by some miracle you had a binary tree that didn't have any leaf nodes, it would enter an infinite loop because there is no exit clause (checking for a null node).
If that is really the case then the interview system is very broken ;-)
1. It was obvious Dan actually knew how to center a div in a "modern" way. Obviously you only do html,body style once per project.
2. The function would break, yes. On any tree. So in practice it would be super easy to notice and to fix.
BTW trees without leafs are not trees ;-) There would have to be a cycle in the graph. I'm guessing you know that, but just in case ;-)
@@eccenux i agree with this. interviewers dont tend to hyperfocus on edge cases that are common best practice unless that it the point of a trick question
@@eccenux Yes I know that trees without leafs don't exist and that's why I used the words "by some miracle". (maybe someone messed up the code and let one of the nodes point back to the root or something, but that's very silly and would never happen.... I hope).
I agree with 1. But as I said, the issue was that it took him quite long. All of my interviewers consider it as something very basic that you should be able to do in negative 10 seconds....
I live in Beijing, China by the way so maybe that gives some context as to what expectations interviewers have. It's very competitive. You need to pretty much be able to create your own operating system just to land that job where you will mostly be googling and copy pasting stuff. Also, all of my interviews are in Chinese and my Chinese is quite poor (foreigner living here).
@@Voidstroyer it's quite a bad interview question. what did you just write someone off for? for something that they most likely google in seconds and then move on to the actual work that you're paying them for? like problem solving, understanding requirements etc. remembering how all of these "basic" things work in every language, stylesheet, framework etc just isn't as relevant as being able to find their documentation, understanding it and actually producing good implementations.
In fact why even explain it that much, a guy on the react team of all things getting written off should already explain why it's a bad interview question
@@sqfzerzefsdf It's a problem with tech interviews in general. To be honest, a lot of these interviewers don't know what to ask, so they just use something as some leetcode problem because it's easy to do it that way. Of all the interviews I have done, only a handful of them actually asked me about my prior experience (I already had 3 years of experience when I did those interviews) and out of those, a few of them let me do some leetcode style questions before the actual interview.
Some of them literally ask questions such as "What is the lifecycle of vuejs", which is something that you can literally google in 3 seconds. I dislike questions that have clear googleable answers. Leetcode questions aren't bad in that they can determine how the person thinks and the process of how they solve problems. But more often than not it is the interviewer that lacks the skills to do anything with that information. I also don't like not being able to google for answers during an interview, because you use it all the time during your actual job. I think that it should be allowed. Just don't ask stupid questions to which the answer can be googled.
This is awesome. Thank you for making such an awesome interview with Dan. Love how Dan thought and solved the Rabbit problem.
In the last problem, you also need to check if the length of the array (holes) is even or odd. If the length is odd, you have to loop again with even indexes.
thank you, I know I was missing something because I started with an array of odd holes and the solution of the video doesn’t assure you the right answer.
I came to the same conclusion.
Or you can start at pos=0 and check every hole twice, pushing the bunny to the end. Same performance O(2n)
@@MrThiteixeira if the bunny is at 3, you check 1 it moves to 2, you check 1 again, the bunny moves to 1, you check 2 for the first time and you've missed it.
@@MrThiteixeira you can omit pos=0. if you check 1 and then 1, then if the bunny were originally on 0, you would always catch it the second time you check 1.
same for pos=n. once you do n-1 twice, you can stop searching.
Dan is the team leader I would love to have in my company
The rabbit problem, it can be simplified down to 3 states as indexes: h, h+1, or up to h+n where h is the first index and n is the total number of holes minus 1. We can check for the rabbit at h. If the rabbit is at h, done. If the rabbit is at h+1, it can either go to h or h+2, so we check h again. If the rabbit isn't at h we know that the rabbit must be in h+1 or h+n, so h+1 becomes our new h while h is less than n. Basically just check each hole twice from the first hole, and you find the rabbit in less than 2n tries.
EDIT: This assumes the rabbit can't jump from the first index to the last index and vise versa
EDIT 2: This solution breaks at when the rabbit starts at h+3 as there is no first index the rabbit is forced against:
| is a guess, ^ is the rabbit, & is the caught rabbit.
h+0 h+1 h+2
| ^
| ^
^ |
&
h+0 h+1 h+2 h+3
| ^
| ^
| ^
| ^
^ |
^ |
My solution just thinking would be to check even holes twice and odd holes ones.
Yes! I figured it out within a few minutes: start at pos=0 and check each hole twice. If wrong on the first try, rabbit is to the right. Check again, win or rabbit is still to the right. That way you are "pushing" the rabbit towards the end
Probably much simpler to code
I thought this at first too, but if the rabbit starts at h+2, you check h and the rabbit moves to h+1, you check h again and the rabbit moves to h, you check h+1 and you've missed it.
@@tobyealden7263 You'll miss it the first time you check h+1, yes, but the second time, the rabbit has to jump back from h to h+1, so you won't miss it. This is assuming it can't jump from the first index to the last index. Remember that h+2 is just (h+1)+1.
EDIT I've just tried it out and yes you're correct, but it's at h+3 it breaks, not h+2.
| is a guess, ^ is the rabbit, & is the caught rabbit.
h+0 h+1 h+2
| ^
| ^
^ |
&
h+0 h+1 h+2 h+3
| ^
| ^
| ^
| ^
^ |
^ |
@@jdpt- Yes, you're right in that edge case where the rabbit is at h (i.e. has nowhere else to go on the second check). So instead consider you start at h and the rabbit is at say h+4. You check h, rabbit moves to h+3, you check h again, rabbit goes back to h+4, you: h+1, rabbit: h+3, you: h+1, rabbit: h+4, you: h+2, rabbit: h+3, you: h+2, rabbit h+2 - and you've missed it. The subtly is that the rabbit can jump into the hole you just checked.
I solved the rabbit problem a little bit differently: I check the holes one by one sequentially starting from the 1st hole, but I stop before the last hole. I don't check the last hole at all, instead I check the last-1 hole again and then I start to check the holes sequentially backwards. If I reach the 2nd hole, then I'm 100% found the rabbit.
How did I come to this solution?
My idea was to take the worst case scenario: checking the 1st hole, but the rabbit is in the 2nd hole. Then I check the 2nd hole and the rabbit jumps to the 1st hole. Then I check the holes sequentially and the rabbit "follows" me until the last-1 hole. If I check the last hole then the rabbit can swap again the same way it did at the beginning. By skipping the last hole check and instead checking the last-1 hole again, I can know for sure that the rabbit is not in the last hole, otherwise with this 2nd check I would see it. If the rabbit followed me all the way, then it should be in the last-3 hole when I check the last-1 hole the 2nd time. If I start to go backwards from here and the rabbit would still follow me, then we would end up in the same hole at the next stop. But I'm thinking of the worst case here, so I assume the rabbit is running away from me at this point. If the rabbit would turn back at any point during this backwards chase, then we would end up in the same hole at one point. If I chase the rabbit all the way back to the 1st hole, then it has no place to go, but to the 2nd hole, which is my next hole that I check, therefore I don't have to check more holes.
I compared this to the solution shown on the video. I ran both solutions 100k times with a new random position on each iteration and on a set of 100 holes. Your solution found the rabbit with an average of 98.5 attempts, and the video's solution had an average of 99.6. Both solutions had a 100% success rate if anyone's wondering.
@@Italiafani can you check this solution with starting from the second index instead of first? I wonder if it's going to improve
That's exactly how I imagined and found the same solution. Glad I found you in the comments and see you already explained it better than I'd haha
Yeah this is what I was thinking!
i was thinking of just starting from zero and check each hole i step on twice until n-1 and if i didn't find it until then i will find it at n-1 since he jumps back because he's at the end.
Great interview Ben. Nice job with the rabbit question. It's cool to see an experienced js developer work through this tricky question.
One thing everyone seem to miss out, you have to have an exit condition on the recursive function call, right? Like checking on node.left exists before calling the invert function, since it would just be called infinitely often
Yes, I was wondering about that too. Eventually the node you get would be a null
came to the comments section to find this!
Since he didn't check for null/undefined, the function will be halted by an error. invertTree(node.right) will never be called because an error will be reached when invertTree(node.left) recurses to the bottom of the tree and finds that it can no longer access 'left' of undefined/null. He's very close to the solution... he would surely realize what is needed if he were to run it.
that is a huge mistake, I am impressed this guy(interviewer) did not care about it, one of the main features of recursion is the stop condition no matter the programming language..
I'm using redux for state and saga for side effects. It's pretty cool to see the people behind the tech you're using.
pretty cool to see people who thinks there is no use for this tech anymore
😀
@@filcondrat wdym?
@@quachhengtony7651 in second question, dan sounded like there are alot better options than redux right now to keep using it
wow, it was so interest, want more videos with Abramov .
ben seems more nervous interviewing dan than dan is being interviewed
Regarding the rabitt problem, you can use four pointer starting from the corners to the middle (two couple of poninters) then iterate each pair of pointer until they find each other, in that way you can find the rabbit in a O(n/2) complexity, I wonder if we can do it in log(n), not sure about that
8:50: 'At Meta ... there's a match for dangerouslySetInnerHTML someone from security will be tagged on the PR for review'
A lot of React's design decisions make more sense in the context of building facebook
This made so much sense when he explained it, I will definitely suggest tagging people in pr based on what’s in the actual pull request
Loved the rabbit question. Paused your chat and had a go myself before continuing =)
Folks, do I miss something, or the invertTree function lacks the recursion exit condition? It'll just recurse until a crash.
Maybe it depends what version you are using?
This was amazing to watch. I somehow had the impression that seniors or highly highly experienced programmers have no problem figuring out almost anything and that brought up some anxiety in me because I know I struggle with some aspects of programming.
Great interview Dan answered every question with humility.
This man is literally the god of JS and Ben is asking “let vs const” lmao 😂😂😂
And it turned out a good question to ask. He answered "I don't give a f*ck".
And he answered without a shred of arrogance.
lol a god are you kidding me. His answer to dangerouslySetInnerHtml was embarrassing.
@@LuckyTechy dude this guy is literally a god full stop, lol. people so gifted often dont even think about the easy parts to an answer, because it is to trivial to them. This guy is the head behind react, cra, redux, and hugely influencial in the entire js eco system.
@@LuckyTechy right, you probably know better. Even though you will probably never be as accomplished
This is great. Trying to figure out why watching other people interview makes me anxious...
:D same
Because we’re conditioned by our educational system to be afraid of tests? :-(
Great video, that bunny question was really something.
When I heard the hint I thought about the same idea but the implementation was a bit different. I thought to double check each even number (skipping odd ones), and if no luck then start again but double check odd numbers (skipping even ones). Not a huge difference but I feel a bit proud of myself))
my first idea was to double check every number, that should work but checking even numbers first and odds second is better, but does not reduce time complexity, because the worst case is still the same.. am i right?
@@l3o-l3o-l3o That's what I thought, just checking every value twice from 0 to 99 should get the result and has an easier implementation.
@@vitorwindberg4212 Doesn't work. The rabbit starts at 2, you double check 0, then the rabbit jumps to 0 before you check 1.
I do think there is a single pass solution but it is more complicated than this.
@@NisJrgensen you are right, only works if you guess the rabbits parity, but then we go back to the original solution and have to go back and forth
Well, with the bunny you can just keep looking in one hole (the best choice is the middle one - 49). Eventually it will get there. Yes, I know it’s O(Infinity), so what? 😜
Before starting the video I hit like. This will be a nice treat! 🔥🔥🔥
Full disclose, only started watching the rabbit question.
Initially, I thought checking the same index twice before moving to the next one would work, but the rabbit could be on the adjacent index when we check a particular index twice and jump over to the one we just checked, and we would miss the Rabbi.
Now, the terms have changed and we know the rabbit starts off on an even index. In that case, start sweeping from 0 to n, and we should catch the rabbit. If the rabbit starts on an odd index, start from 1.
This is provided the array is not looping, and once the rabbit reaches each end of the array, it has to jump back.
Yes you can solve it if you check the same index twice, but start at an edge
So check twice in 100.. if not found then the rabbit has to be at 99 or less
Check twice at 99.. has to be at 98 or less..
etc til you find it..
Probably not very efficient but it took me less than a minute of thinking to come up with this?
Am I hired? 🤩
@@RobertFranksPlus initially, I thought the same too. But it won't work. Say the rabbit is at 98 and we checked 100, no rabbit. Then the rabbit moved to 99, and we checked 100 again, no rabbit. After that, the rabbit moved to 100, and we checked 99. No rabbit.
So even if we do a sweep of the array, the rabbit can still jump through.
But since we know the rabbit starts on an even number, we can start on the first even number index of the array and do a single sweep and always find the rabbit because we are looking for where the rabbit is.
@@moxy-bison aah but the 2nd time we check 99 we would catch it!
@@RobertFranksPlus That works if the rabbit is trapped at the end. Say the rabbit is at 6. We check 4 and the rabbit move to 5. We check 4 again and then the rabbit moves to 4. We check 5 and the rabbit is 4th hole. The rabbit has been missed.
@@ImAfricanJesus exactly. Double checking an index is bit of a luck.
But starting with an odd index when the rabbit is on odd index or even index when rabbit starts on an even number will surely catch the rabbit in a single pass (most of the time, before even completing a single sweep).
It is completely normal not to be able to solve a fairly difficult problem right away at an interview. Sometimes it takes hours to think a problem through and then code it up, let alone most of people don’t perform yo the beat of their abilities under pressure of the moment. That’s exactly why we have SE shortage. The interview process is completely broken.
I got a rejection from a big tech company once and one argument was “not implementing let and const in my code correctly”, meanwhile THE Dan Abramov: “it depends, doesn’t matter that much”… tech interviews are broken!
Absolutely. Every interview is judged subjectively, based on the peccadilloes of the interviewer(s). I'm of the mind that if there is a coding exercise, I probably won't participate. But if I do, I'd like to make sure they are setting aside time for us to review the code together, so they can ask questions, not just make snap decisions based on arbitrary standards/preferences.
With all respect, I don’t think dans approach of “not caring” is good. If you only use let when you reasign, it improves readability, you can infer things without having to read the entire code.
Next time they pull some bs like that send them this video to shut them down.
Dan seems like a top-notch dude. I wish I could have someone like him as my senior.
18:38, not correct. Recursion has to be called only if branch != null, otherwise it will throw error something like "error trying to access property left of null"
Oh yea I forgot it's nullable!
I teached programming in university for 5 years, I ended up seeing 3 basic rules for recursion to work:
1. There needs to be a recursive call. I.e. call same function inside function you are defining.
2. The call needs to be inside a conditional: if, where, ternary op, try catch, whatever
3. The recursive call needs to have different arguments than the received, and each call should make the conditional closer to branch out of the recursive call, thus ending recursion, reaching the "base case"
great job guys! congrats, more content like this, do a similar coding interview on react only, hooks, context and more.
dan is such an interesting person. i love the stuff he tweets that’s not related to coding
Like maths and music
This guy is super down to earth! And Ben thank you so much for these videos, learning a lot
Hey Ben, your purely intellectual bunny problem actually got me thinking about a solution to a graph problem I've been stuck on for like 2 weeks (not joking). So, thanks I guess. Also, you might find this funny but Dan inverted the tree real quick then took longer on the bunny problem. My situation was different: it took me a while to find a way to invert the tree using another method, but I solved the bunny problem in like a minute, with O(n^2) using a different method. I guess this is a reminder that if developers stick together and apply ourselves in sync, we can solve pretty much anything, given enough time. Glad to be a sub! Keep the excellent content coming, my guy 🎊🏆☮️🙌🏽
Would love to hear your rabbit solution!
O(n^2) is worse than brute forcing. How did you manage that? Lol
@@Zeegonerif you make a 2 pass the worst case is n^2
@@funprog You could check the each hole twice. So worst case is n+n. I don't think you can get any better than that
If you've ever had "Imposter syndrome" simply return to 13:00 to watch the Dan Abramov struggle to center text on a page.
best way to center an element "smack in the center" of the page (center both vertically and horizontally):
1. make sure the containing element has the entire width and height of the page (100vw, 100vh)
2. set the display property of the containing element to "grid" and set the place-items property to "center"
i mean that's it ig hope it helps you dan :/
@Dyanosis 🤣 nice one boss
100vw breaks on desktop devices (sets to entire viewport width, not viewport width minus scrollbar, so you get ugly horizontal overflow), 100vh breaks on mobile devices (doesn't factor in top and bottom browser UI that hides and shows during scroll)
@@JonasKuske good to know :)
For the rabbit problem, we can look at two elements at a time from one side to another, so we'll find the rabbit in O(n). Loop through 1..i..n ( 1
Ben, nice interview. Would have been also nice to hear him answer more short junior-middle questions, like "const vs let", to know what experienced people like Dan would say.
What... this is literally the first thing they chat about.
wooosh!!!!??
@@ibeeliot you seem to struggle with the words "like" and "more"
On the bunny question, couldn't you find it in one pass by ''forcing'' an initial state on the bunny?
If I first check at 1 -> the bunny could be at 0 or 2+
Check at 1 again -> now the bunny could be only at 3+, if it were at 0 or 2 and it jumped to 1 then its over
Now knowing that the bunny is forcibly at 3+, the odd naive approach should be enough to find it, should it not?
Wrong my man! Consider rabbit starts at position 4.
Step 1, check at 1: Bunny moves to 3.
Step 2, check at 1: Bunny moves to 2.
Now knowing your assumption for step 3 is that rabbit is forcibly 3+. But as seen in this one, it is not.
Step 3, check at 2: Bunny moves to 1. And you miss it for rest of the game.
Similarly it could happen for the following steps and the concurrent positions as well.
That's the flaw in your logic, respectfully. :)
watching him struggle to center the div but then solve the binary tree inversion like that was surprising. he is obviously a skilled dev, im sure he doesnt write much UI
What this tells us and should tell every interviewer is that TIs are not effective tools for finding talent. Also this was such a great kindness for Dan to allow himself the be seen as a human being. It'll have zero effect on his career but could allow much more junior developers to see themselves in a better light.
This was really amazing. The bunny question seemed really tricky. And again, it's really looking at a person's thought process that matter in those types of questions.
Dan is inspiring
I always use const. If the situation arises where I need to reassign the value, I first think if I should be doing that… or if another approach is better.
Watching Dan struggle with centering a div makes me confident in my front-end skills :)
29:48 I spent 20min drawing out the scenarios and with a field of size 4, the guesses you make are 1,2,2,1. With a field of size 5, the guesses are 1,2,3,3,2,1. With field of size 6, it's 1,2,3,4,4,3,2,1. While I don't understand it deeply enough to give a formal mathematical proof for why it works, I would extend this to the solution where you guess 1,2,3,4....,98 and then 98,97,96,...,1. The way it works is when you guess upwards in index, it forces the possible positions of the rabbit to be in "alternating/interleaved" positions (possible locations of a rabbit can not be next to each other). Then as you guess from 98 back to 1, it takes advantage of those alternating positions and eliminates them 1 by 1. That's terribly explained - easiest to show drawn.
This whole thing is possible due to the asymmetry of the boundary condition - when you guess 1, you eliminate the possibility of the rabbit being at index 0 after it made the jump. Then when you draw out the possible positions of the rabbit as you guess 2,3,...N-2 and you see that "alternating/interleaved" pattern emerging.
Edit: saw the even/odd pass solution. I think it's very similar but it resulted in a good theorem: start counting from odd/even to catch odd/even rabbit.
At first I thought this was a joke sometimes Ben likes trolling😂 , nice interview
Awesome, just awesome Ben! Excellent job Dan Abramov!!
You can also just check twice on each hole. Then you don't skip the rabbit, if it jumps to the hole where you previously were. (just swapping the loops. Same code, slightly different idea)
this is not working, assume: u guess 0 0 1 1, rabbit: 3-2-3-2, then u guess 2, but it jumps from 2 to 1
@@tobiashaefermann but when you guess 2, it won't jump from 2 to 1 because you already found him
Maybe explained it wrong: rabbit is on 3, u guess 1. rabbit jumps to 2. u guess 1 again (rabbit is on 2), rabbit jumps on 1 after that guess. u guess 2 now (just each hole twice), but rabbit is on 1 and u missed it
@@tobiashaefermann okay, but then when you guess 2 while it’s at 1, it can only jump to 2 right? so on the double check it should be there… unless it can hop from 1 to 4
The two best react developer I've ever known, with both you I have to add Kent c. Doods
Find someone that looks at you the way Ben looks at Dan coding.
just check second position (index 1) twice and keep going... Check index 1 two times, if you didn't find him that means the rabbit is definitely not at position 0 or 1. Then check index 2, 3, 4, n and you will squeeze the rabbit to the end or catch him early.
My approach to the bunny one (paused the video):
- Say you're going up 1 -100, check the second hole twice,
so if it was in the first hole,
it could only have gone to the second (then you'd have found if)
you didn't find it, but you eliminated the first hole, now your chances are 1/99
Keep checking the holes in order, basically cornering the bunny, but check the penultimate hole twice again.
I came up with the same idea. Probalby not the best solution, but it works lol
@@StraightCrossing it's actually O(n) too
i thought of the same thing but if bunny starts in hole 4, checking hole 1 first time, bunny could go to 3, the second time, could go to 2, then when you move on to 3, bunny could hop to 2 :(
@@mohamedchalal4518 I think you're right, there is always going to have the possibility thay the bunny can give me a slip, it just needs to be in front of me
Dan looks like a very humble man. This is how we code. In interview skills test, I still frequently see some weird JS questions that supposed to test my skills. But those are generally not real-life problems that we need to solve. Just some tricky questions to confuse people I think :)
Dan, I completely agree with you 53:38
I think the solution to find the rabbit is start at number 1 and double check. for example, if the rabbit is at 0, then I select 1, the only move it has is go to 1, and then i select again 1.
If the rabbit is at 2, then I select 1, if it goes to 1 i select again 1, if it goes to 3, I select 1 and in the next move I select 2 and repeat the process.
Double check and move forward left to right is the one solution that came to my mind too.
If it is alowed I think is the best solution
had the exact same idea! either way the array keeps shrinking.
I think it won't work
Let's say you rabbit is at 3
You check 1, rabbit jumps to 2
You check 1 again, rabbit jumps to 1 but now your index is pointing to 2
@@mohsinamjad8947 u’re right. this solution won’t work
while inverting binary tree we should create boundary condition to return out of invertTree function, if (!node.left || !node.right) return
Good developers can code but very good developers test the code ;)
I dunno what Dan works on exactly but I feel like he is no longer FE developer but a dev who works on FE technologies
Also I found it a bit cute when he said "we, at Meta..."
Loved this. Now I realize I'm not so bad. I figured this would be one of those anomalous situations where the interviewee doesn't hesitate at all, like in that one video of the genius kid who only studies algorithms/DS (with Clement).
The invert binary tree function will go into an infinite loop because he forgot the base case
Yup. I heard that if the interviewer doesn't see the mistake it's fair game.
@@DanAbramov8 lol this
Probably it will error rather than infinite loop, but the base case is definitely missing.
@@ChaoticBestie Yeah you're right it would error (we'd read from a property of null).
@@DanAbramov8 That's probably the error I've seen more than any other writing JS. 😂
Amazing video Ben!! 🌛🔥🔥💪💪👏👏
Please more videos like that brother 🙏
By observing Dan struggle to center the div, I have promoted myself to his level in my head canon.
Yes, but could you have answered the other questions as easily as he did?
@@brianruff3066 No because I was being sarcastic. He is my father. If I was half as smart as him I'd be doing more complex things than centering divs. I struggle with medium difficulty and sometimes easy difficulty problems on leetcode. Help.
@@mrdoner3451 It's okay. It's not like those questions truly reflect real life anyway. They are still fun to solve and if you can do them they will get you into some very high paying roles. Just keep working at them, and eventually, you'll get promoted. To be fair, the other questions were probably easier than medium-level Leet Code problems, so you still have that going for your at least.
For the tree inversion, don't forget to check if node.left exists, or else you'll get cannot read left of undefined eventually. But nice solution!
+1 Handling base case is one of the fundamental part of recursive algorithm. Not sure why no one picked up on ths.
I had a different solution to the bonus.
Start at 0, and hit each index twice before incrementing, this way if the bunny moves closer, you catch it, and if it moves further, you corner it at the final hole until it has no option but to move closer to you catch it.
Yes, exactly, although you don't need to start at 0, you can start at 1 because if the bunny is on 0 it can only jump to 1 and you'll get it the second time.
i was thinking this as well, but what if the rabbit is at 3 and you check 1, rabbit moves to 2, 1 again, rabbit goes to 1, and then you check 2 missing the rabbit.
@@0Arman0 yes, it fails :( I've reproduced it now. Just shows how tricky it is to envisage all scenarios when coding in order to avoid bugs.
But you could check the second last index only twice then breaking would technically be a very small optimisation?
Ye this won’t work, you would still need to run it twice starting at odd and even, using twice as many guesses as the videos solution. The solution in the video is the best way
I just don't get 1 point of the "invert binary tree" question: what happens when left or right are null? Iknow that the algorithm is right, but there's no base of the recursion and I believe is a must have in this type of question
Imagine your interviewer is smiling like a maniac and laughing while you are trying to work your answer lmao
loved this video! more of this should come in the future with Dan! :D
If this interview tells you anything, it's that interviews are not great for finding great programmers.
I believe there is a "slightly more efficient" approach if you are allowed to make the same guess twice.
Currently, you need to guess #evens + #odds (100+99) = 169.
If you instead change the algorithm, you start on hole 1 (assuming there is hole 0), and guess each hole twice, and move forward, you only need to guess up until the second last hole (98), which means (100-2)*2 = 196.
In other words:
1. Guess 1 -> hole 1
2. Guess 2 -> hole 1
3. Guess 3 -> hole 2
4. Guess 4 -> hole 2
...
195. Guess 195 -> hole 98
196. Guess 196 -> hole 98
You are guaranteed to find the rabbit this way, any thoughts?
Dan accepted! Amazing stuff.
Very interesting interview!
Anyway I have a question: was that div really pixel-centered (at 15:30)? The body has some default margins and it pushes the width/height in offset: in fact we can see the horizontal and vertical scrollbars. Just setting body "margin: 0" will solve it.
Actually, in this way we don't even have to set body's width/height, but only put #root's width/height to "100vw/vh". Is this right?
Also, about the "invertTree" function (at 20:50), don't we have to check if the current "node" is null?
Since when a leaf is missing it's null, the first line would be to check this and return if it's null, e.g. "if (!node) return".
Just very small doubts, let me know if this is correct or I'm going crazy.
The last node will still have a value. So it will have {value: 'something', right: null, left:null};. So if(!node) won't work. You have to check if both right and left are null.
Dan: Creates Redux and works on React
Also Dan: takes 5 minutes to center a div :D
Thanks for the interview Ben and Dan. Really enjoyed it!
51:51 I don't think it's the only way. Will this not work?: you start from index 1 and check each index twice ( 1,1,2,2,3,3,4,4,...)? They are very similar solutions though, except you don't need to check hole at index 0.
that was my guess, check all indexes twice, eventually you,ll corner the rabbit at the end.
@@pab_loq Yeah. But you have to start from index 1. If you start from 0, you can miss the rabbit (As someone showed in another reply):
(1) _ _ _ R (you pick the first)
(2) _ _ R _ (you pick the first again)
(3) _ _ _ R (you pick the second)
(4) _ _ R _ (second again)
(5) _ R _ _ (you pick the third)
(6) R _ _ _ (third again… etc.
This won't work because the rabbit can still slip past you. Imagine if the rabbit starts at 3. You check 1 and the rabbit jumps to 2. You check 1 a second time and the rabbit jumps to 1, but your next check is 2.
@@johnsontinuoye8428 Even if you start at 1, you can miss the rabbit
0 1 2 3 4(R) - initial
0 1 2 3(R) 4 - you pick 1
0 1 2(R) 3 4 - you pick 1 again
0 1(R) 2 3 4 - you pick 2 and so on
@@ChaoticBestie True, I guess you have to check 0 once afterall. 0,1,1,2,2,...
I enjoyed the video very much. I really love both Dan and Ben and They are great to the community. Thanks for the collab guys.
I could be wrong but the proposed solution to the rabbit problem only works if there are an even number of holes or if the rabbit starts in the same whole at the beginning of each pass.
Failure: With 3 holes if the rabbit starts in index 1 and you start your guess with index 0, the rabbit then moves from index 1 to 0. You guess index 1, the rabbit moves from index 0 to 1, you guess index 2, the rabbit moves from index 1 back to 0. End of iteration. Now starting next iteration with index 1, the rabbit is still on index 0 from previous iteration. You guess index 1, the rabbit moves from index 0 to index 1. You now guess index 2, Rabbit moves from index 1 to index 0 (or 2, doesn't matter) End of second iteration, rabbit not found, Game Over!
Solution: Iterate the number of holes 1 time but check each hole twice, one right after another. 0,0,1,1,2,2...
Because the rabbit has to move and only moves one space you will can't miss it. Rabbit starts in hole 1. Check 0 rabbit moves to either 0 or 2. Check 0 if rabbit moved to zero rabbit found if not. If rabbit had moved to two rabbit will move to 1 (if only 3 holes). You just checked 0 twice so now check index 1. Bingo! Rabbit found! Even if the rabbit moves away every time you will eventually pin the rabbit at the last or second to last hole.
(Correction) This method is also prone failure. See reply's for why. The correct answer is: If there are an odd number of holes you should start your iteration on 0 both times. Even number of holes start on 0 and then 1. See Reply's for why.
It was pointed out by @Moshin Amjad that the double check solution can fail as well. I think the best solution would be to use the proposed solution in the video but if the holes are an odd number, then start on 0 in the second iteration instead of 1.
I'm curious now:
"Iterate the number of holes 1 time but check each hole twice, one right after another. 0,0,1,1,2,2..."
Couldn't you still miss it because it could move over 2 positions during your two checks? For instance, if you check hole 0 twice (0,0) and the rabbit is initially at hole 2, couldn't the rabbit move into position 0 after you check it the second time?
(brackets are checks)
Check position 0:
[-] - R
0 1 2
Check position 0:
[-] R -
0 1 2
Check position 1:
R [-] -
0 1 2
Am I thinking about this correctly?
@@hamm8934 Yes, you are correct. This was brought to my attention. (See my previous reply)
@@thetomking Ah yes :) didn't refresh the page to see your response
What I thought was, make 2 passes like they said. But in both occasions check only evens. Cause in the first pass if the rabbit is originally in an even position you'll find it. Otherwise it will jump into an even position so you check again.
It's basically the same idea.
21:10 - The problem is quite simple. The rabbit knows where it is at all times. It knows this because it knows where it isn't, by subtracting where it is, from where it isn't, or where it isn't, from where it is, whichever is greater, it obtains a difference, or deviation. The guidance sub-system uses deviations to generate corrective commands to drive the rabbit from a position where it is, to a position where it isn't, and arriving at a position where it wasn't, it now is. Consequently, the position where it is, is now the position that it wasn't, and it follows that the position where it was, is now the position that it isn't. In the event of the position that it is in is not the position that it wasn't, the system has required a variation. The variation being the difference between where the rabbit is, and where it wasn't. If variation is considered to be a significant factor, it too, may be corrected by the GEA. However, the rabbit must also know where it was. The rabbit guidance computance scenario works as follows: Because a variation has modified some of the information the rabbit has obtained, it is not sure just where it is, however it is sure where it isn't, within reason, and it knows where it was. It now subracts where it should be, from where it wasn't, or vice versa. By differentiating this from the algebraic sum of where it shouldn't be, and where it was. It is able to obtain a deviation, and a variation, which is called "hole".
he searched how to center div. I feel super safe ^^
Love this! :D
Feedback for Ben: your audio is much quieter in this than Dan so personally, I was doing a lot of volume adjustment up/down.