I had an interview today and it was my FIRST TIME whiteboarding! I was so nervous and had no clue what to expect so I just wanted to say thank you for making this video because it really helped me get through the interview and I was lucky enough to get an email back to move on to the next stages.
hello, I hope you got the job and was it for an entry level web developer job.I have one soon and i dont have an idea what the question is going to look like
1. Repeat: make sure you do understand the problem. 2. Example: get insights by doing examples 3. Approach: come up with your approach(es) to the problem (brute force first) 4. Code: write the code for your chosen approach 5. Testing: pass the testcases 6. Optimize: optimize the complexities (time and space) of your algorithm
One of the things that I found helpful that you missed here is breaking down the problem into multiple parts (possibly smaller functions). This helps to avoid being stuck in trivial implementation details just because your code feels super complex and also helps focusing on one small problem at a time.
You really don't have time to brute force and optimize in 20min. Many FAANG companies will tell you to explain your most efficient approach, why, then do it.
it's a test to see if you're just like them--a test to see if you know the same things they do (and therefore are on their level). Personally, I think that's not always the best way to full a team. It may be good to have people that know different things so your team can do more together.
I have an interview today. Out of everything I've watched to prepare in the last 2 days, this has been the best help yet. I came from computer programming college courses and not computer science and have 4 years of web dev under my belt. I've never done a coding interview as I've worked for a large corp since I left school. I've needed this example.
@@chilly2171 Useless for you* Also, I have never been asked these questions in tech interview. The last tech interview I did for web dev I had to create a game. It was way easier than memorizing these useless algorithms that you never actually use after graduating. A lot of the education in US seem to be memory based. You know the questions they are going to ask and can therefore be ridiculously well prepared.
I really appreciate this video! Thank you for taking your time to explain this. I've been in this field for over a decade, and I realize now that when I was an entry level developer I naturally performed at interviews using similar set of steps. Now as I am at a senior level, I am more nervous about white boarding than ever before. I realize that it is because I adopted the classic thought -- "As a senior I need to be able to solve all of these problems easily." I appreciate this video so much as it reminded me that "No I don't have to know all of it. The goal is to show how I think." Thanks!
Fantastic talk. Great points created around a memorable acronym. Especially great points were: 1. Talk your approach out, talk about what your thinking 2. Decompose your solution into high-level functions (don’t start writing imperative code) 3. Break down your approach into high level ideas -- you can often become caught-up on trivial details but this helps you think of the over all solution. Thanks for the great advice.
This deserves more views. I have been working as a manager for some time and was feeling very nervous for a technical interview since it's been a while since I've had to do coding. This gave me very practical advice that I will certainly be using and will take with me forward to any future technical interviews.
I have to say this has been the most helpful video I have watched to prepare myself, and it helped me way more than I thought it would through my past interview. Background: I am a very pathologically anxious person. Trick interview questions with stangers looking over my shoulder and judging me is definitely one of the most terrific situation possible for me to be in. I was still very unbearably freaked out with the interview, almost brain-frozen by anxiety and dark thoughts. But this video really gave me those few steps I could hold to, and it was comforting. I was able to get started, clear-up my thoughts, and tackle the problem with a clear methodology, in a constructed way. I was still very anxious, and it felt like I solved their problem in a "secondary thread", while my main thread was focused on being anxious and frozen. But that secondary thread was definitely following the framework, and I think it was key. Apprently, my secondary thread solved their problem successfully. I'm still a bit bitter that they ask this kind of trick questions during interviews. It's only good at evaluating the level of stress of the interviewee, and how much they have prepared for this very specific kind of interview question, which is pointless and unrelated to the actual job. But regardless, thank you so much, this video was of great help.
I think their should be ONE more little step in here. That being simplify and break down the problem into smaller parts, then once you have your bearings on that small control size, scale it up to the whole problem at hand. It's not always gonna work, but it's helped me notice patterns I was missing when trying to tackle the problem as a whole.
Great video, these are some of the ideas I had when prepping for interviews. It would be nice if Fullstack Academy would post a mock interview that follows these steps.
I've heard that "breadth-first coding" idea described before as "top-down" rather than bottom-up, but breadth-first describes it better. There's an old diagram format from the 1980s called Warnier diagrams which is basically all about this. The conventions of the diagram aren't very important, other than that it makes you describe what happens at the top level in one or two words per action, before moving down to the second level and so on.
totally faild my interview with Amazon. My codes didn't pass all the tests, felt horrible at the time. Then realized it is a huge company and many people told me it is very hard to pass!
@@sneezygibz6403 don't worry, I managed to pass in November in the same company. Be calm, practice today so you will be more confident tomorrow. If it is your first time, they usuarlly use sites like testdome.com or hackerank.com; Review search, sort and optimization algorithms. Matrix are common as well. Good luck!
That is such a good point, help the interviewer to be comfortable in the interview. That probably helps them to remember you better after the interview. 13:12
Thanks man, you're making me feel way more comfortable for my interview today! In the interview is it ok to tell them/ask them about thinking out loud? Or should I just start doing it without telling them. Obviously won't say I'm using reacto method but asking to just verbalize my thoughts.
this vídeo made me MUCH calmer about my upcoming interview at Amazon. I have some live coding experience that I hope will help me to not freeze and stay a little bit more chill
Breadth-first coding worked like a charm! I had a coding problem on paper, and the interviewer got the idea of my code very quickly. Got the job in the end.
I personally want to use a marker in the Repeat step. I would jot down some keywords and requirements that I notice in the process. Just so that I have a constant reference to those stuff that I can go back to.
Recently I've been doing for the first time a Whiteboard interview. They warned me about it, but I didn't think they ware serious, so I didn't did my research and failed obviously. Honestly, it's bit frustrating, when a person who's haven't looked for a new job for a while has to learn why such interviews exists, how they should behave. Even I consider myself a good programmer/coder, I felt like I was standing naked thinking how bullshit coding is this: I have to waste time writing by hand, I can't edit, I can't move, I can't look up, I can't test... next thing they gonna ask me to build a computer out of rocks like xkcd comics... I had the idea in my head, but I couldn't write in in code just straight off directly, so the most part I was repeating, trying approaches realizing, that this won't work, and start over, more stress... Total nonsense if you don't know to do this interviews....
Same here, totally bombed it lol HackerRank or LeetCode questions suck the joy out of programming for me. I've solved a few of them since i bombed that interview, and I come to liking them less each time. Completely irrelevant problems, out of touch with reality, playing on an abstract field of BS. This gamification of Software Development makes me sick.
This is super helpful - thank you for sharing! One thought: I wonder if it could be helpful for others to remember the acronym as “React To”. How one should react to the interview question.
In the C Step, I learned to do CT - Test as you Code. You can do a little sanity checks after every few lines. For example, after writing out a loop, or helper function, any conditional statement, math, look for syntax errors, logic errors. It helps a lot instead of doing it in the end in one fell swoop.
I had many interviewers that sit there completely silent, even though I was trying to talk to them they barely talked and they expected 100% working code without any hints or anything. Obviously these places had bad reviews on glassdoor and those managers or interviewers are most likely incompetent.
How could we solve ANY problem. Some problem even if we sit there trying to solve it, it could take 2 hours. And some problems, to reach the optimal solution, it took people a few months or even years. So how is it solvable in 20 or 30 minutes if we didn't see it before?
@@nikhilchauhan7511 in a way, it might be similar to the Tang Dynasty or any dynasties. They want people to recite and memorize 50 pounds of books and then be able to write it back in "National Exams". Those who obey and go to the exam become the Number 1 and can be the official to oversee 70,000 or 100,000 people. Those who don't obey will go to the farm and grow some rice or vegetable. So they want to test whether you "obey", even when it is not reasonable. It is a bit like George in Seinfeld. In order to be The Van Buren Boys, you have to rob or steal or do something bad, to show that you are part of them and you follow their rules, before they consider you part of them
good example.. everyone should learn and practice foe algorithms to improve your approach and yes alwayz be confidient and dont ahow your interview er you are stuck
While this is good high-level advice, my problem is not that I don't go through these steps. Rather, it's the "Describe your approaches" step, which is easier said than done for some problems.
I have a similar view on this. Been developing for a while now, with many languages, over various size projects, and more than a few frameworks... I always find it hard to articulate how I would unravel a problem with all the various solutions I might initially touch upon... some are even intuition or foresight from past lessons learned.... but you don't have time in an interview to even begin to touch upon ... and still they want to see your best within 30 mins... I do better with 4 engineers grilling me for 4 hours in a free for all session... Talking shop really tells you how someone is to work with... not these 45 minute interviews, where you memorize every algorithm under the sun and hope they ask you the easy ones and fake it until you make it... such a forced and fake process, I am getting tired of these interview games...
Precisely. The EEOC UGESP laws/regs cover these whiteboard interview Selection Procedures. The Programmer Whiteboard Test Discriminations lawsuits are coming because the contingent lawyers sense money.
i think it means that even if you performed well, there will always room for improvement! and that is a trait that tells a lot about a person being interviwed. :D
It's last because a working brute force solution is better than a non-working optimized solution. Also many times, the brute force solution can be built on top of to get the optimized solution. Of course sometimes you have to totally rethink the solution to get the optimized solution, but it is more risky to immediately go for optimized solution unless you are very confident in it.
I had an interview today and it was my FIRST TIME whiteboarding! I was so nervous and had no clue what to expect so I just wanted to say thank you for making this video because it really helped me get through the interview and I was lucky enough to get an email back to move on to the next stages.
Hi, what was your whiteboard question?
hello, I hope you got the job and was it for an entry level web developer job.I have one soon and i dont have an idea what the question is going to look like
1. Repeat: make sure you do understand the problem.
2. Example: get insights by doing examples
3. Approach: come up with your approach(es) to the problem (brute force first)
4. Code: write the code for your chosen approach
5. Testing: pass the testcases
6. Optimize: optimize the complexities (time and space) of your algorithm
Nice one! You can make it better by adding timestamps to each step.
Thank you, saved me a lot of time!
One of the things that I found helpful that you missed here is breaking down the problem into multiple parts (possibly smaller functions). This helps to avoid being stuck in trivial implementation details just because your code feels super complex and also helps focusing on one small problem at a time.
You really don't have time to brute force and optimize in 20min. Many FAANG companies will tell you to explain your most efficient approach, why, then do it.
This is exactly what he said in the video.
What’s your point?
This is probably the best valued programming content I've seen on youtube.
R -> also stands for RELAX
it's a test to see if you're just like them--a test to see if you know the same things they do (and therefore are on their level).
Personally, I think that's not always the best way to full a team. It may be good to have people that know different things so your team can do more together.
I have an interview today. Out of everything I've watched to prepare in the last 2 days, this has been the best help yet. I came from computer programming college courses and not computer science and have 4 years of web dev under my belt. I've never done a coding interview as I've worked for a large corp since I left school. I've needed this example.
how was it?
well, bro?
@@davidleal714 i really hate when they don´t respond, what is the problem?
@@vcalesco Those that aced coding interviews like myself (Google intern) knows that this video is useless.
@@chilly2171 Useless for you*
Also, I have never been asked these questions in tech interview. The last tech interview I did for web dev I had to create a game. It was way easier than memorizing these useless algorithms that you never actually use after graduating.
A lot of the education in US seem to be memory based. You know the questions they are going to ask and can therefore be ridiculously well prepared.
I really appreciate this video! Thank you for taking your time to explain this. I've been in this field for over a decade, and I realize now that when I was an entry level developer I naturally performed at interviews using similar set of steps. Now as I am at a senior level, I am more nervous about white boarding than ever before. I realize that it is because I adopted the classic thought -- "As a senior I need to be able to solve all of these problems easily." I appreciate this video so much as it reminded me that "No I don't have to know all of it. The goal is to show how I think." Thanks!
Thanks, you saved me from directly rushing towards the keyboard and start typing code as soon as problem is displayed.
Fantastic talk. Great points created around a memorable acronym. Especially great points were:
1. Talk your approach out, talk about what your thinking 2. Decompose your solution into high-level functions (don’t start writing imperative code) 3. Break down your approach into high level ideas -- you can often become caught-up on trivial details but this helps you think of the over all solution. Thanks for the great advice.
This deserves more views. I have been working as a manager for some time and was feeling very nervous for a technical interview since it's been a while since I've had to do coding. This gave me very practical advice that I will certainly be using and will take with me forward to any future technical interviews.
I have to say this has been the most helpful video I have watched to prepare myself, and it helped me way more than I thought it would through my past interview. Background: I am a very pathologically anxious person. Trick interview questions with stangers looking over my shoulder and judging me is definitely one of the most terrific situation possible for me to be in.
I was still very unbearably freaked out with the interview, almost brain-frozen by anxiety and dark thoughts. But this video really gave me those few steps I could hold to, and it was comforting. I was able to get started, clear-up my thoughts, and tackle the problem with a clear methodology, in a constructed way.
I was still very anxious, and it felt like I solved their problem in a "secondary thread", while my main thread was focused on being anxious and frozen. But that secondary thread was definitely following the framework, and I think it was key. Apprently, my secondary thread solved their problem successfully.
I'm still a bit bitter that they ask this kind of trick questions during interviews. It's only good at evaluating the level of stress of the interviewee, and how much they have prepared for this very specific kind of interview question, which is pointless and unrelated to the actual job. But regardless, thank you so much, this video was of great help.
This is the best video I have watched on this subject. Thank you.
impressive. Can we have a demo where u pretend to solve a real coding question with implementation of these steps. Thanks in advance
Agreed!
The breadth-first coding video (linked to the time where Gayle starts talking about it) here: ua-cam.com/video/Eg5-tdAwclo/v-deo.html
After watching a thousand videos about this topic. This is the best of them all. No disrespect to other creators.
Very insightful. I can apply this not only to my future interviews, but also to my future coding problems. Thanks man!
This helped me calm down a lot, thanks!
I think their should be ONE more little step in here. That being simplify and break down the problem into smaller parts, then once you have your bearings on that small control size, scale it up to the whole problem at hand. It's not always gonna work, but it's helped me notice patterns I was missing when trying to tackle the problem as a whole.
I feel like this helped me reduce my technical interview anxiety a bit. Thank you so much! 🙏
WoW! THIS. I needed exactly, If and when I pass a whiteboard interview someday , I will come back here and thank you!
Thank you sooooo so much. Made a huge difference in my prep and approach to the interview
This is a great video! Picks up in very simple concepts overlooked often like understanding the questions right and writing down the input/outputs!
Best code interview tips ever!!
Great video, these are some of the ideas I had when prepping for interviews. It would be nice if Fullstack Academy would post a mock interview that follows these steps.
Very helpful. Please make a sample video with the whiteboard.
I've heard that "breadth-first coding" idea described before as "top-down" rather than bottom-up, but breadth-first describes it better. There's an old diagram format from the 1980s called Warnier diagrams which is basically all about this. The conventions of the diagram aren't very important, other than that it makes you describe what happens at the top level in one or two words per action, before moving down to the second level and so on.
Great video! Thank you this is incredibly helpful!
totally faild my interview with Amazon. My codes didn't pass all the tests, felt horrible at the time. Then realized it is a huge company and many people told me it is very hard to pass!
I'm nervous for my interview tomorrow. Hopefully it goes well
@@sneezygibz6403 don't worry, I managed to pass in November in the same company. Be calm, practice today so you will be more confident tomorrow. If it is your first time, they usuarlly use sites like testdome.com or hackerank.com; Review search, sort and optimization algorithms. Matrix are common as well. Good luck!
They can’t know how you now with a technical interview, the companies are very wrong, the experience is enough
nice, this video values more more than "I'm former FAANG Google Uber super coder .and now " .. Good job, man
Fantastic! I love that REACTO structure!
Very helpful advice! Thanks! :)
This is fantastic advice, thanks for making this!
this made me feel a LOT better thank you!
Are you better at solving coding problems or did it just make you feel better?
Great video, I could relate to a lot of situations mentioned in the talk , I guess I picked up some pointers , Thanks .
Wow. Very helpful guide. Thank you very much. It is so hard to find a high quality info in the internet now.
I am applying for job recently. Thanks for this video. It will be helpful for me!
This is awesome insight! Thank you so much!
Good content, I really wish there was another way. I usually have no confidence and the "hazing" analogy is real
Great tips. Thank you
That so easy yet useful! thank you :)
That is such a good point, help the interviewer to be comfortable in the interview. That probably helps them to remember you better after the interview. 13:12
Beautiful video very helpful advice!
Super helpful! Thank you!
Great explanation. Thank you a lot!
Very helpful video, thanks
Thanks a lot..i feel more comfortable going in now
Great idea to start by writing pseudocode. To expand on that, you can start breaking down the problem by writing out comments for the code sections.
Thanks man, you're making me feel way more comfortable for my interview today! In the interview is it ok to tell them/ask them about thinking out loud? Or should I just start doing it without telling them. Obviously won't say I'm using reacto method but asking to just verbalize my thoughts.
Great valuable tips, thank you very much.
This was incredibly useful thanks homie
Such a good video! Thanks
This is very calming. I have a job interview in 2 days I worry that I may completely butcher the coding assessment.
absolutely great stuff!!
Alternative title: Framework for Getting a Job at Which You'll Be Miserable
thanks so much, great insight!
Whiteboards are so different. I wrote "// Example of a hashmap" on the board and stood there in silence for 30mins waiting for Copilot.
This is great, thanks!
this vídeo made me MUCH calmer about my upcoming interview at Amazon. I have some live coding experience that I hope will help me to not freeze and stay a little bit more chill
good luck with your interview! :)
How did it go?
@@tnikoli40 didn't even get to the one with actual people hahaha. But I'm cool, I have much to learn
@@NomadCodemist so only over the phone type interview?
@@tnikoli40 not even that hahaha. I was too slow on the online assessment
Thank you for this great video
add "review" to the end and call it reactor
Breadth-first coding worked like a charm! I had a coding problem on paper, and the interviewer got the idea of my code very quickly. Got the job in the end.
Do you have resource breadth first coding i can learn?
Awesome.Thank you.
Nice....I really appreciate this video!!!!!!!!
I personally want to use a marker in the Repeat step. I would jot down some keywords and requirements that I notice in the process. Just so that I have a constant reference to those stuff that I can go back to.
Nice video mate - thanks for this and very useful. :)
Great content!
Very nice explanation
Recently I've been doing for the first time a Whiteboard interview. They warned me about it, but I didn't think they ware serious, so I didn't did my research and failed obviously.
Honestly, it's bit frustrating, when a person who's haven't looked for a new job for a while has to learn why such interviews exists, how they should behave. Even I consider myself a good programmer/coder, I felt like I was standing naked thinking how bullshit coding is this: I have to waste time writing by hand, I can't edit, I can't move, I can't look up, I can't test... next thing they gonna ask me to build a computer out of rocks like xkcd comics...
I had the idea in my head, but I couldn't write in in code just straight off directly, so the most part I was repeating, trying approaches realizing, that this won't work, and start over, more stress...
Total nonsense if you don't know to do this interviews....
Same here, totally bombed it lol
HackerRank or LeetCode questions suck the joy out of programming for me. I've solved a few of them since i bombed that interview, and I come to liking them less each time.
Completely irrelevant problems, out of touch with reality, playing on an abstract field of BS. This gamification of Software Development makes me sick.
This is super helpful - thank you for sharing!
One thought: I wonder if it could be helpful for others to remember the acronym as “React To”. How one should react to the interview question.
Nice explanation 👍
Thank you for it is very useful for me. ❤️❤️❤️❤️
Great advice
4:58 if anyone else is confused, it's "breadth-first" coding, not "breath-first". Breadth meaning the full width of the problem
Very helpfull. Thank you!
great advice.
This is great I love the content
damn this is some good advice, thank you dude. appreciate it!
Thanks so much!
Great video.
Thanks a lot bro
thank you very much
Thank you
In the C Step, I learned to do CT - Test as you Code.
You can do a little sanity checks after every few lines. For example, after writing out a loop, or helper function, any conditional statement, math, look for syntax errors, logic errors.
It helps a lot instead of doing it in the end in one fell swoop.
Very helpful
Excellent
I had many interviewers that sit there completely silent, even though I was trying to talk to them they barely talked and they expected 100% working code without any hints or anything. Obviously these places had bad reviews on glassdoor and those managers or interviewers are most likely incompetent.
This is literally the design recipe from my favourite book "how to design programs".
Thanks
very useful tips
Very interesting
George Polya sends hugs, bruh.
How could we solve ANY problem. Some problem even if we sit there trying to solve it, it could take 2 hours. And some problems, to reach the optimal solution, it took people a few months or even years. So how is it solvable in 20 or 30 minutes if we didn't see it before?
Same problem
Luck
lmaoo that's the thing. these companies want you to rot learn every problem and spew everything out on the day of interview.
i really dont get it.
@@nikhilchauhan7511 in a way, it might be similar to the Tang Dynasty or any dynasties. They want people to recite and memorize 50 pounds of books and then be able to write it back in "National Exams". Those who obey and go to the exam become the Number 1 and can be the official to oversee 70,000 or 100,000 people. Those who don't obey will go to the farm and grow some rice or vegetable. So they want to test whether you "obey", even when it is not reasonable. It is a bit like George in Seinfeld. In order to be The Van Buren Boys, you have to rob or steal or do something bad, to show that you are part of them and you follow their rules, before they consider you part of them
I have an interview tomorrow and part of it is peer coding of JavaScript. I’m so nervous but this was helpful!
how did it go?
any update???
Here's the update: She butchered it and is homeless now. Hope she gets back on the right path.
@@31redorange08 I got the job and make 6 figures now 😏
@@mollydeangelis-jimenez3220 Not sure if sarcasm. 🤔
good example.. everyone should learn and practice foe algorithms to improve your approach and yes alwayz be confidient and dont ahow your interview er you are stuck
Wow! You have the book
While this is good high-level advice, my problem is not that I don't go through these steps. Rather, it's the "Describe your approaches" step, which is easier said than done for some problems.
I have a similar view on this. Been developing for a while now, with many languages, over various size projects, and more than a few frameworks... I always find it hard to articulate how I would unravel a problem with all the various solutions I might initially touch upon... some are even intuition or foresight from past lessons learned.... but you don't have time in an interview to even begin to touch upon ... and still they want to see your best within 30 mins... I do better with 4 engineers grilling me for 4 hours in a free for all session... Talking shop really tells you how someone is to work with... not these 45 minute interviews, where you memorize every algorithm under the sun and hope they ask you the easy ones and fake it until you make it... such a forced and fake process, I am getting tired of these interview games...
The most accurate word in this video is "hazing"
Precisely. The EEOC UGESP laws/regs cover these whiteboard interview Selection Procedures. The Programmer Whiteboard Test Discriminations lawsuits are coming because the contingent lawyers sense money.
Hazing is a great word
Why is Optimization last -- does that mean we are supposed to always code out the brute force solution..
i think it means that even if you performed well, there will always room for improvement! and that is a trait that tells a lot about a person being interviwed. :D
It's last because a working brute force solution is better than a non-working optimized solution. Also many times, the brute force solution can be built on top of to get the optimized solution. Of course sometimes you have to totally rethink the solution to get the optimized solution, but it is more risky to immediately go for optimized solution unless you are very confident in it.
What’s the Christopher Approach?