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.
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.
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 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.
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.
The breadth-first coding video (linked to the time where Gayle starts talking about it) here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Eg5-tdAwclo.html
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
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!
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.
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.
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
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 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.
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!
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.
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.
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
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.
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.
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.
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...
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
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.
these question about algoriims are more about memorisation then about actual problem solving, like how many people could actually solve a lot of these question if they never heard of the algorithm before.
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 the first step is to be aware of all data structures and their methods. Only then you will have the tools to understand a problem solution. If you haven't learned those I don't think any steps will help you.
@@sakiratkehindeusman5334 I personally used multiple resources. Leetcode ,book Grokking Algorithms, RU-vid, cracking the coding interview book and many more. P.S I am still learning although I am a senior software engineer with 6 years of experience.
