Engineering video
5:58 · 14 August 2024
Live coding interviews often trigger trauma and fear of going blank, but they offer the lowest time investment compared to take-home tasks, allowing engineers to generate multiple offers and gain market leverage.
Hear it at 0:00 →Fast touch typing frees up brain capacity during an interview, preventing the candidate from panicking over basic keyboard characters and allowing them to focus entirely on solving the problem.
Hear it at 1:05 →Candidates cannot solve in an interview what they cannot solve alone without Google or GPT, as heavy reliance on abstractions often leaves engineers unable to build simple forms or iterate independently.
Hear it at 1:41 →Mastering basic for and while loops to iterate over arrays prevents coder block, as the vast majority of problems can be solved using fundamental iteration techniques.
Hear it at 2:33 →Recursion mirrors everyday human problem-solving, and practicing how to convert standard loops into recursive code trains the brain to handle recursive problems comfortably.
Hear it at 3:26 →Big O notation relies largely on common sense and high school mathematics, requiring candidates to count operations based on input size and evaluate memory impact line by line.
Hear it at 4:07 →Proficiency in live coding unlocks access to top tech companies, remote jobs, and higher compensation, whereas fear of live coding often forces engineers to accept subpar market offers.
Hear it at 5:08 →point number one, everyone hates live coding. Can we call the example of a software engineer based in London that we're working with? And in that case, you would like literally turn down great companies as soon as they would say, hey, it's a live coding interview. Even if most of them would not be super hard. So it's just the trauma, the fear of going blank, and also the pressure of having someone looking over your shoulder.
Number two, live coding is the best kind of interview. The reason why live coding it's the best kind of interview you can make is because it's the interview with least investment of time. An average take home task will take around 15 to 30 hours total if you want to deliver something that will stand out and you have no guarantee that they will invite you to the next stage. Even if they would, you might still get rejected in the last stage.
Which means on an average week, you can only do one intake. When it comes to live coding, you can do two a day. You can do 10 interviews, you're capable to generate an interviews, you can do 10 interviews. You'll have a lot more leverage power because you can generate more offers from the market. So I want you to just imagine that tomorrow you wake up and you're really good at live coding interviews and go on LinkedIn and you see you can pretty much interview with any company.
It's some sort of an interviewing superpower. On to point number three, typing speed matters. You want to type almost as a reflex. You don't want to be looking for characters on your keyboard because it will free up your brain. And so you'll really only think about the problem. Your fingers will naturally find the the characters on the keyboard. It shows a lot of etiquette, engineering etiquette. It will free up your brain.
When you're in a live coding interview, you're already kind of operating at 50% your brain capacity. And if you need to look for characters, for like the parentheses on your keyboard, you're pretty much doomed. So the first thing you want to learn, and it's not even programming related, you want to get really good and really fast at touch typing. On to number four, you can't show what you cannot do.
You're not be able to solve in live coding interview what you cannot solve alone by yourself. And when I say by yourself means no GPT, and also no Googling. There is nothing worse than people Googling how to attach an event handler to a button. That's something you're supposed to know. A lot of people cannot build a simple form in HTML. write code for the web, it's not. And so they go into this interview, they get asked a very simple question and they blank out.
Because they've been working always in these layers of abstraction, they cannot individually by themselves build a small form. Solve a simple iterative problem. In the interview you'll maybe do 60 70% of what you normally do by yourself alone. If you are interviewing right now or if you're looking on how can I level up towards the senior level and beyond, we put together a free technical assessment to find your technical gaps.
It's going to take you around 10 minutes and you're going to get a detailed report about what are the things that you do well and what are the things you need to fix for you to get to the next level. Link it's in the comments, make sure you check it out. Point number five, iteration, it's liberation. One thing that you want to do extremely well is be able to write for and while loops, an iterator over an array.
So if I wake you up at 3:00 a.m. in the night, you can even write it to me on page. If there's something you get take away from this video is go back and open a code editor and try to go over an array with a for loop and then go over an array with a while loop. And then you want to type those things going back to typing speed, you want to type those things very fast. There are websites where you can upload a code snippet, you can upload a nested for loop and try to type it every day super fast, like 99% of the problems you will get can be solved with a for or a while loop.
And if you know this, you'll never go blank again, ever. You'll always be able to like, oh, there's an iteration. Maybe you don't solve the problem, but you passed the coder block because you know these things really well. As an engineering manager, I was interviewing people in live code and they couldn't iterate over an array without that map. They just didn't knew how. I asked them to write a for loop, I'm talking about people interviewing for a senior engineer and they couldn't write a for loop.
On to point number six, recursion, it's easier than people make you think. So recursion itself, it's something that we as humans do every day in certain problems. If I would ask you, for example, how many descendants your grand grandfather had, you would recurse from your grandfather all the way up to you and count the members. And you can do that naturally, nothing to do with computers. What happens is we don't usually write recursive code in production code bases.
Every time you have a for loop or a while loop, I want you to ask the question, how would I code this recursively? In most problems, the recursive solution won't make any sense, you'll be like, well, this is a lot harder and I get the same result. But it will train that muscle. to cancel from iteration to recursion very easily. You'll be super comfortable. The moment you see a recursive problem be like, wow, I think this can be done.
On to point number seven, big O notation, it's also a lot easier. Big O was made to look like these crazy techniques from computer majors. In reality, it's mostly common sense. It's literally, okay, how many operations I need to do depending on the size of the input? Now, people go in and and go what you things like oh, logarithmic, big O or quadratic. In reality, these things are also very easy. But they use this terminology at the end of the day, if you know high school mathematics, if you went through high school and you know logarithm and you know powers, you should be more than ready to run big O.
But the problem I see people do is they're so focused on passing the interview, they prepare for everything, and they forget about big O. And they go in, they get asked about, okay, can you tell me the time and space complexity? And they blank out. Whereas this is actually the easiest part. You made it to the interview. This is just a detail, is literally going through each line of code and counting the number of operations and how your input or your algorithm will affect memory.
Make sure you get rid of it and my advice it's always use it in your daily practice. Take a snippet of code from your react component, if you're writing a for loop or a map, throw it to GPT and ask it the big O and the territory reason again. On to point number eight, live coding is the best paid skill you can learn as a software engineer. What I've seen at least in my case, when I got good at live coding, my compensation really went through the roof.
I was able to work for the top tech companies. They all used live coding. And there's also this idea of invincibility in a way, you feel like you could go anywhere and you still can get a job. You can compete even for remote jobs that are highly competitive. The opposite is you're scared of live coding, you don't want to go to the market and you put up with things that you don't want to put up at your job.
Or it takes you forever to get an offer and the offers you're getting are even under the market or under your experience level, but because you're so terrified and frustrated with the whole process, you just accept a very bad offer. If you're interested to getting better at live coding interviews, then check out the other videos put together on this channel where we have different live coding challenges in React, JavaScript, etc.
As for us, thank you Bogdan and we will see you in the next one.
