this is why live coding is hard for you

If you master this skill, you won't worry about AI taking your job, take layoffs or whatever will happen with the market. The skill I'm talking about, it's live coding. And despite what some people here on YouTube want you to believe, you don't need to waste months on lead code in order for you to get good at it. You only need to apply the principles that Bogdan and I are going to show you in this video.

If you look at how technical interviews are being done these days, you will see what we call a take home tasks inflation. What do we mean by that, Bogdan? So, what happened when everybody start using GPT and Cursor with all the new models is that all of the sudden, not only people can write a lot of code, but also a lot of people that were back in developers now can build a take home, a front end take home task.

Or at least can submit something that's decent. Or people at a front end, they can submit an API task. And what's been happening is that all of the sudden, when you send a take home task out as a company, instead of having three people submitting, which should be the case back in the days because most people would say, oh, I don't have time for this. Now you have 20. And so all of a sudden, there's been an inflation, as you mentioned.

Like, people can do take home task faster and better because of the AI tools, and also the competition double. Because all of a sudden, everybody, like, I know people that were Java devs that went for a senior front end engineer position because they coded the whole thing with AI. I heard of people who just get the description of the take home challenge or take home task are being sent and they feed that into cursor, for example, and kind of, you know, 80% of the job is done right.

At least that's what they they believe, right? And you have these take home task where sometimes they would not only tell you what they need, like, hey, we want a data fetching with pagination and some feature, but they'll also tell you how to do it. We want you to use Redux, and we want you to use React Query, for example. And so it's so easy, especially those ones, to feed them to GPT because you're really giving the detail extractions of what to do.

The second reason why this skill is actually the skill to learn in 2025 as a software engineer, is that take home tasks are high effort and low value. Exactly. And this is something we tell everybody that we work with. The take home task, it's literally the brute force approach to interviewing. It requires a lot of upfront work from your side. And it's usually a very poor strategy. And so what people usually do is that because they are scared of other forms of interviewing, they feel like the take home task is actually one of the safest way to get the job.

Some of them maybe got the job doing your take home task three years ago. But that's not the case anymore in 2025. If you're doing a take home task, the company has all the power, you put a lot of work, I'm talking about 20 hours plus to something decent. I know they all say it's going to take two hours. It never takes two hours. I have not seen a take home test to take two hours. Yes, maybe it takes two hours to do it.

But to do something that will actually get you the review or like the next interview, it usually takes around 20 hours. Like we're talking about deploying it, writing test, adding a read me. That's like they usually require production ready code, even when they say, oh, it doesn't have to be production ready. Yeah, and that's the funny part. You can get rejected on a wimp. You know, they'll just look at a certain line of code they don't like, they have 13 people who also did the take home task and you just get rejected after.

Maybe you put like seven days of work into that. It won't matter, right? So high effort, low value. Yeah, you would be surprised how people get rejected over the most trivial thing and how little time the company actually spends reviewing it. Like you would spend 20 hours and a lot of people think, well, I spend 20 hours you're going to look at my code and you're going to look at my components or whatever.

And the person, you know, evaluating this would maybe spend like one minute. They're going to open a bunch of files, they look at something, and if they like it, they'll find a reason to invite you to the next stage. If not, they'll find anything, things like, oh well, I feel like you're over engineered or oh, you should have done this differently. And then you're out. Yeah, because this this hiring manager or whoever it's analyzing this has a thousand things to do and then it has to review during their week, like, you know, 17 home take home task, right?

So they will spend a few seconds on it, you spend weeks on them, right? This is the the commitment it's asymmetric. So there's one part that will always end up losing in this kind of relationship. live code anyways, even if you don't like live coding, you still have to do it. Exactly. And what we've seen happening with a lot of people is they do the take home test, they use AI, the AI told this nice code, they get invited to the next stage and the senior engineer looks at the code and says, can you extend this part of the code?

And that's when they have to code live, right? And you're back to square one. And that's when also, if you used AI in your take home task and you cannot explain what, you know, chat GPT or cursor did over there, you're going to get yourself in trouble. And finally, the few developers who can actually live code will automatically stand out. Exactly. So we see a lot of people thinking, well, you know, with AI, I won't have to go through this pain, which is doing a live coding interview, I don't have to go through this um painful experience and traumatic experience and everybody's hiding behind, oh, can I just do the take home task?

Everybody applies to companies that offer a take home task. And what you see is that if you actually know how to code and you can more or less or just code your way out of of a standard live coding problem, you'll see yourself in an abundancy of companies that you apply to. AI didn't make anybody smarter, it just actually made everybody more dependent on AI. And so the scenarios where you cannot use AI, those ones are actually underinvested and there's a lot of space for for great developers to stand out there.

One thing we don't mention here is also feedback. So the big advantage of a live coding interview versus a take home task, it's the feedback loop, it's so much faster, right? You you jump on an interview, you are there with the interviewer, you try to do your best, right? And you get your feedback within maybe in the same day, maybe in the same in the interview without you having to wait, right? In exchange, when you send a take home task over, you might wait weeks.

Uh and you might not get any any feedback because companies are very afraid to give candidates feedback because, you know, some people behave badly, some people might take you to court. I've seen some very well intended engineering managers who try to give feedback to candidates and then some candidates would actually try to fight back, try to put a company in a bad spot. Which is why companies are very careful with giving feedback. They don't want one of the, you know, one of their emails to be leaked on social media, on LinkedIn.

you get the interview got couple. So if you want quick feedback on your skills, live coding is probably the way to go. The thing is, if you do live coding interviews, you can probably do 10 of them in a week. Like you can at least do two to three a day. Whereas when you do a take home, that's usually the one thing you'll do that week. Because it takes so much focused time that your main energy will go into that. So would you rather play your hand, you know, 10 times a week or one? Who who do you think will be more successful? So it's a lot easier to get lucky if the numbers are on your side. On to the next point. Now, if live coding is so amazing and it's the skill that will make you AI proof in 2025 and beyond, then why do developers struggle with live coding in the first place? Cuz half of the stuff you're going to see on YouTube, it's about how to get better at, you know, live live coding and fang interviewers and lead code and all that stuff. So why is it still that developers struggle with it if it's so over invested? Well, first of all, there is what we call the lead code disillusion. den, what is a lead code disillusion? What usually happens when we fail a live coding interview is that people get into the smart world. I'm just going to lead code for the next 6 months and I'm going to get good and I'm going to pass. And then they go in, they start lead code and six months later they eventually quit. Because, and this is from my personal experience, I tried I I did code um lead code almost full-time for three months and I got to a really decent level and I got so burned out with it that the moment I see that interface, I already get like anger attack. The way lead code is designed, it's a bit like the Squid games. I know if you remember the series, where there's like, you know, 300 people in one of them will get the million dollars and the other ones the 299 will die. And for a fun reason, if you watch the series, people actually were trying to win the squid games. So you realize, you know, the most likely outcome is that you're going to die. So the um the problems are so hard and sometimes they're so random and they're so far away from the stuff we actually face when we work, that it's almost as a as a full-time job. So thinking that you'll go in and grind lead code, yeah, I mean sure, you can get marginally better and then they go to an interview and they get a problem that they didn't touch. And that's when the story ends. So I think lead code

is one of the most inefficient ways to get good at live coding. And I know that sounds counterintuitive, but we'll see that in a second. Okay, now the second reason why developers struggle with live coding, it's overreliance and dependency on the dev tooling. What do we mean by this, Bogden? Uh this is one of the reasons why if you fail a live coding interview, don't blame yourself. Like that's the first thing is people blame themselves and they think they're not good. The reality is the way the the way the interview is set up, it's has nothing to do with your day-to-day coding. So, how are you expecting to get good at it? In most of those interviews, they will give you like code editor, sometimes the code editor doesn't even has auto complete. It doesn't have AI. And so if you're used to be able to Google, be able to check documentation, be able to have IntelliJ auto completing your code and having things like copilot, you take all that out, and all of a sudden that's a whole new world that's just coding from the top of your head. And that's a lot harder, or at least it looks a lot harder because you've never done it before like that. Because nobody really works like that, like developers use developer tooling to get faster and better. Nobody just walks away writing code in the word document. My IDE is not Microsoft Office. The next reason, it's framework abstractions. And this is a big one, especially for JavaScript devs. Exactly, so nowadays, you almost never use native APIs. Like you almost never have to write a for loop yourself, because we usually use dot map or dot reduce. And it's the same with DOM APIs and JavaScript, you almost never have to create a promise object yourself, you usually receive one from the fetch function. And I could give you thousands of examples. But we are so used to rely on the framework we are we are using, and we take those things for granted. And so when they are not there, all of a sudden, we feel like we don't know what we're doing. Because again, it's not because it's hard, it's just because that's new territory. And uh later in this video, we will show you how to deal with this dependency on on framework abstractions. Onto point number four, past trauma, and this is something bogden you can talk about a lot, I guess. Exactly, this probably should be number one, but we know that everybody talks about this. So we we

they wanted to touch it last. One of the most common thing we see is that people they you go in, you have one live coding interview and it goes so terribly wrong because of all these three reason, right? You probably practice with lead code and then you get something you didn't expected. You were over relying on the tooling and on the frameworks or on AI and all of a sudden all of that is gone. And so people get this feeling of, I know nothing.

Like they they imposter syndrome just goes through the roof. And they're like, well, okay, I'm I'm done, I'll never do this again. This is not for me. I think this is also because there's a lot of elitistic thinking in tech. And when you're I've been on the both sides, I've been as an interviewer and I've also been interviewing people. And it was so easy, especially when you work for this unicorn or tech, uh big fan companies, it's so easy to look down on the other people.

And being there, doing your best, failing and being looked down on, that's such an emotional experience and so traumatic. And it makes people feel so bad with themselves and it amplifies whatever insecurity they had. And so the number one thing we see is that people just say, well, I'm not going to do anymore life coding. They reject. Like, we had people getting message by their dream company and inviting them over.

And they would be like, no, no, no, like maybe what do I do? Are you telling me in three months or six months? The opening is not there in six months and so they get this panic attack. Because of past XP. Yeah, and talking about the the fan industry. And and taking general, I think there is this pressure to look smart. Uh and there's all this smartness and looking smart means, you know, speaking in certain way, using certain jargon, I think a lot of abstraction.

And I think a lot of people are holding back from actually asking questions and not being afraid to be curious. And this is overall um the whole biotech sector and I think it's doing more damage than than good. And the result of all this, it's that developers can code, but they cannot program. And it's time for us to really learn how to program. Which brings us to point number three, how to master life coding and not die trying.

And the first thing you have to get right if you want to master life coding, it's you need to make fundamentals your second nature. Bug them, what do we mean by that? So here it's when you want to get rid of everything. You want to get rid of the framework. You want to get rid of even your ID and I chat. all you to do this exercise just after this video. We're going to pause the video, open a block note and try to write a program that just iterates over an array with a for loop and creates the sum.

And do it in your notepad, and you'll see how different that is. Now, I'm not saying you're going to make, you know, the note block or uh Microsoft document your programming tool. But I want you to go to that extreme because that's when you get rid of everything and you realize code is just text, right? It will get interpreted by a compiler and then execute it. And you'll start, you know, everything, all of a sudden, the web now looks so hard.

You'll be like, well, wait a second, if we start see at zero, how do I get back to React, JSX, the editor, AI, TypeScript, and all that. And so you really want to know how to move across a whole spectrum and understand that most of the times you operate here with abstractions, tooling. And so it will be hard to operate on the other extreme, just because you're not used to it. And that's why you got to get rid of everything.

And by the way, I will add on this, because in this AI age, where everybody is AI, AI, we forget one simple thing, code was invented by humans. And it's built in such a way, right? It's built it's kind of the the compromise, the bridge between machines, the way machines think and they can only think in zeros and ones. Uh you know, they have transistors, they don't have neurons and humans, right? And I remember uh Paul Allen, was it Paul Paul Allen, the co-founder of Microsoft, when um you know, Bill Gates tell the story about uh Paul Allen, they they had a big demo the next day and he wrote the compiler by by hand on a piece of paper uh in the airplane and it all compiled perfectly, right?

Now, of course, you don't have to be, you know, you don't have to reach that level, but that's what we're talking about. I mean, programming was built by humans, right? And you can, you can use your brain actually, and you can learn these things and you can use your brain first. You're thinking first before before, you know, defaulting on uh premade things. Now, to make fundamentals second nature, you need to start thinking in first principles over abstractions.

So for example, every time you're iterating in your code, you're writing a map or reduce. Always ask yourself as a small mental ex How would I write this with a for loop? Or how would I write this with a while loop? Or can I make this requests? These three questions will tell you almost 99% of the things you need to know about that piece of code. If you can answer those three, I promise you, you can walk away alive with your dignity intact from any code interview, regardless of if you solve the specific problem they throw at you. The second thing, it's understanding that complexity, it's only an aggregate of simplicity. Exactly. And this is what we call that by a thousand cuts. So, a lot of people sometimes say, well, I'm slower or I couldn't figure this out and they think it's something about them. But in reality is the fact that there's many small things that they they know that then they sum up into, okay, I cannot get this done. And so, usually you'll understand that everything in computer science, everything in programming is extremely simple. Every problem in isolation is simple. The reason why programming is hard is because you got to tackle all those things at once. They come at you all together. And so, the best exercise is again to go to the atomic version of whatever you're doing. Break every function you're doing in a in a line of code. Break everything you're doing down to the while and for loop. And then you'll understand that all of these operations are extremely small and then you can conquer them independently, and then you can go and operate faster at a higher level because you know how all those species work independent. And the third point, it's master the basics. Right? And what do we mean by the basics? We mean the four and the while loops. You know, the boring stuff, the simple stuff that maybe a react developer or someone that works within you those abstractions in our daily job doesn't get a chance to to touch. I remember years ago when I went to my first live coding interview. I was back in the days I was working with react and they told me to write a while loop. And I I think I never I didn't knew the signature of the while loop. Like I didn't knew how to write it. And the reason is simple, you don't write while loops in react. They're a disaster, they will destroy your app, they go out of control. In the same way, we never use recursion. And most of the times it doesn't make sense unless it's a very controlling environment, like, you know, the browser recurses the dome, but

for the most part even NASA said, it's forbidden to write recursion in any of the NASA code because it can go out of control. And so, you go to that live coding interview, they ask you to write recursion, and they make you feel bad because you don't know it. And you interview is that, but in reality is like, how are you supposed to know? It's not a good practice in the first. The thing is, you want to get really good at the basic and this is sounds very simple, right?

Oh, get get out of the basics. Everybody says that. But we live we are in an industry where every day I go on YouTube, I see a new library, I see a new shiny object. And so it's so easy to get into the complex. It's like, oh, you need to keep talk about complex things. Oh, you need to know system design very well. But in reality, you'll get so much more, just like Jordan was saying, right? You get much more from the fundamentals.

You get much more for knowing, again, go back to that exercise I mentioned, writing the for loop out of your top of your head, right? A while loop. And then switch those to recursive. If you know how to do that, you're way ahead most people. So once you master your fundamentals, we get to the second stage, which is pick your battles, because even if you master the fundamentals, but then you try to, you know, pick the wrong problems to solve, you're going to get in trouble.

And basically, picking your battles mean don't go for a dynamic programming if you are not going to interview at Google. And by the way, only about 3% of Google interviews contain dynamic programming problems. Exactly. And we mentioned in the beginning that lead code, it's a bit of a disillusion and goes in line with this. A lot of people going and they try to solve graph problems or greedy algorithms or building a secret breaker or dynamic programming.

And that's cool if you're really pre-efficient at everything else. And you got to remind yourself that 99% of companies will not interview like Google. And 99% of the companies will never ask you about dynamic programming. And that it's exponentially harder and it takes exponentially more time to get good at dynamic programming than to learn the fundamentals. And so pick the easy battle and get really good there and then go out and interview.

And then come back and say, well, I'm going to ramp it up next level. I'm going to dominate the recursion and then you're going in and you're like, oh, let me get deeper into iteration and learn two pointers or sliding window. And only once you're fully confident of that. And full confidence means in a word document. That's that's when I tell you, like what does it mean I'm fully confident about this? I can write it in a word document?

Then you move on to graphs, you know, greedy algorithms, dynamic programming and the like. And the final point is of course, focus on patterns, not problems. Exactly. So there's this huge biased towards specific problems. Everybody it's running after the problems that meta asks in their interviews or stripe asks in their interviews. And people forgot that it doesn't matter how you solve a specific problem.

There's this whole saying that if you learn how to fi if you give someone a fish, they eat for a day, if they learn how to fish, they will uh won't they will never be hungry. And that's what you want to apply in your learning in general and specifically in life coding. So if I go in and I solve the problem, that has literally no value for me. I would always ask myself, hey, what was the pattern I use?

How did I broke this down? Or what is the pattern they use? And then I'll try to apply that to two, three, five problems until that's part of my mental tool set. And until that's like an engineering techniques I can use, find again solution to problems that match the same pattern. And finally, this is just a bonus hint from Bug and Knight, but do get to know your keyboard. Uh if you're a programmer, the best is if you can touch type.

And I think the hours right now you are at around 100 VPNs. Uh and I remember when when you start getting good at this is that your uh your girlfriend was getting jealous because you would spend more time with the keyboard than you would with her. And so that's the level of of commitment you need, folks. You need to make uh make at home your keyboard. Your keyboard you should be more familiar with your keyboard and you are with uh the palm of your hand.

Okay, you got to love it, you got to love being here. You got to think magic things happen when I touch the keyboard and you're going to make that your favorite place to be. Yeah, if you're a musician or if you're good with your fingers, you probably have a head start. But in my case, I learned how to touch type pretty late um in in life, I wasn't, you know, young anymore. Your your brain is not so plastic.

Meaning, you know, I had to wake up, you know, Saturdays and and Sundays and I would practice every day. one of those, you know, websites type every day, type every day, write in my journal, write as much code as I can, right? Now, you have to understand in those live coding interviews, there is so much pressure, you know, you're in the red zone and in the red zone you want, you know, you don't have time for mistakes, because every mistake will compound up to a point where you're paralyzed.

Which is why having this uh, you know, making fundamentals your second nature, knowing how to touch type, right? having practice the simple problems and knowing how to abstract outside of of all the abstractions, all these things are going to add add up to a spectacular performance. I mean you will impress yourself, you will stand out and you will get a job if you do all these things. Keep up the good work. Bogdan, thank you so much. Uh if you are looking to interview and if you're looking to understand what your technical gaps are and how to fix them, check out the free 10 color assessment that we have in the comments. And if you'd like Bogdan and I to personally mentor you and you'd like to join a community of developers who are looking to level up,

then also check out the software mas program that we are offer. We have some spots left. Make sure you fill out your application and if there's a fit, you can get in touch with me directly. With that being said, thank you so much and we will see you in the next one.