I'm done with take-home coding tasks…

Despite looking doable and sometimes easy, take-home challenges are actually the worst kind of interview you can make as a software engineer. So, into this video, we will talk about the trap of take-home assignments, then go on to why can't developers actually opt out of doing take-home assignments if they are such a bad deal for software engineers. And, of course, what to do instead? Finally, if you're still going to do take-home assignments, we will give you some advice.

If you don't know us, my name is Garosh and together with my brother Bogdan, here in the call, we founded the Senior Dev, where we help JavaScript engineers level up to senior and get high paying roles. Well, the number one reason is that in most cases, you'll irritate to get no feedback. You'll get a generic email, maybe they tell you something like, oh, we would like you if you would use more design patterns or use this or that, or maybe you overengineered.

But literally, that's not actionable feedback that you can use to get better. The second thing is you might get rejected over some random or very vague reason. So, they'll be like, oh, we believe in this file you over engineered or they'll just, it's so easy to pick something up and reject someone. A lot of people think code, it's very objective in the sense of you can evaluate good code or bad code, but the reality is that without the context, you don't really know.

And so, people will go in, assume whatever and then reject you over the fact that you over engineered or whatever reason. They'll tell you that you didn't use enough design patterns, they'll tell you over engineered as I mentioned. And they swallow too much of your time and energy. So, you're not getting much feedback, but at the same time, you don't have a lot of time to keep up with your interviewing process, you don't have time to iterate on your resume, to apply to more companies, to have more interviews because they really swallow your time.

And it's also an energy level. A lot of people do those and they just burn themselves out and then they go to interviews and get rejected because, guess what? They look burn out and they're quite negative. It's never 2 hours, so they'll tell you, well, we don't expect you to spend more than 2 hours on this. It never takes 2 hours. It takes at the very least 6 hours to deliver something decent. If you want something that will actually get selected.

It takes around 6 to 12 to 16 hours. That's the average. And there's also just no guarantee. There's no guarantee that they will give you it. There's no guarantee they'll even look at it. I know a lot of people think that the engineering team will get around and evaluate your code. In reality, those things are done very quickly. So they'll spend 5 minutes looking at it and then move on with their day.

Because again, so busy people, they have things to do, and it's not like they will take half a day to look at every take home task. And you are getting other company Morsi, regardless of even if you pass the task, they might still reject you in the next stage. Because again, they didn't invested much, they don't really care. They don't have any stake in the game. On the other side, you committed 20 plus hours of your time and work.

So you are in a much more vulnerable position. And they don't have to reciprocate. Because again, for them it's very easy, just send a task to a bunch of people, maybe 10, 15 and whoever comes back, we look at it and see how we feel about it. And this is why take home task assignments are a red flag. Because it signals a poor engineering culture. It signals the fact that they frame software dev as a one-way street.

They come up with the requirements and you implement whatever. Not only that, but they also give you a time estimate. They said, no, this should take two hours. When in reality, every professional software engineer knows that how much time something takes depends on the scope, on the quality they want, on all the nuances that you need to figure out. That's why we have refining sessions when we do a sprint.

It also reflects top-down management. So it's kind of like, hey, you know, do this in two hours. That's the mentality. And don't think it will change. Like a lot of people think, well, this is only the interview. Most of times when the interview is like that, the company is like that. And there's also no commitment or respect for your time. So usually it's the lazy way of interviewing from the company side.

Because one of the most easy things you can do is draft a Y document with a bunch of requirements and send it over. It takes zero cost on their side, zero investment. into thinking, recruited like mid senior senior and so on. Yeah, and I think one one mistake uh software engineers make here and we all do. It's number one, we overestimate, right? And we will talk about this later. We overestimate how much and how fast we can get done actually.

Uh we look at things on the surface, but there is always things you don't know about the challenge. Uh and the other thing is uh with AI and with, you know, AI coding tools like cursor, people think, hey, you know, uh I can use AI and actually I can ship this in in 2 hours. So, if it gets me an interview, it's not such a big deal. We will see why in reality, even if you use AI, even if you if you use boiler plate, number one, so does everyone else and number two, it's still never two hours.

Now, if take home assignments are such a bad deal for software engineers, because they are the red flag, because they are usually a waste of time, because you get no commitment. Why can't software engineers just opt out and why do still, you know, why are people still doing them? Well, the number one reason is because it's the only interview they got. So, obviously people are being rational and saying, well, yes, you know, I don't want to do it, but it's the only company that actually called me back this week.

So what am I going to do? Do nothing. And we'll see in a second, this is usually a problem of not investing enough in your job applications, not having a resume that actually gets you called. But it's usually this lack of preparation in in in getting more deals. You want to focus on getting more people to call you back, because they will fix all these problems in the interview process. They are terrified by other interview formats.

Most of us had very bad experiences with live coding. It's very traumatic when I you I match up with someone that doesn't know how to interview and they can treat you very poorly. And then all that becomes kind of interview trauma and people are just paralyzed. They say, I cannot code with someone looking at my code, they feel a rejection. And above all, they feel how they will feel with themselves when they get rejected.

So they just avoid live coding. They'll be they're like, oh, I'll just do whatever it takes. not to go through that thing again. There's also the failing of productivity because you're building, you're writing code and you're starting a project from scratch. So it's usually really cool. to install all those things and you feel like you get done a lot. But again, it's a filling. It also avoids the direct employment rejection.

As I mentioned, in the other formats, you might get a rejection directly and that hurts a lot more than a silent rejection. And it's also the dynamic that we are used to as developers, right? You get some requirements, you code. So, it's literally the habit, that's how you what you've been doing at your job for the last two years. And so it feels like, oh, let me just jump on it. Like that's the first it's a reflex almost.

And there's also this illusion that you actually have a chance to pass, and here is the confusion between something that's probable and something that's possible. Because yes, it's possible that you get a job doing take homes, but the probability is very low. And nowadays, with all this Vibe coding and AI, people overestimate how fast they can get it done. So everybody thinks, well, with AI, I can probably just build up very quickly.

But the reality is every candidate has access to AI. Everybody building it will use AI, and everybody will ship a lot of code. So that's not a differentiator anymore. Again, AI and all the boiler plate they might making, you will be fast, but everybody's fast these days. And again, folks, the fact that you can make it fast and the fact that that, you know, you're comfortable, maybe you're a great coder and you're like, hey, you know actually like I can do this.

doesn't change the power dynamics respect to a company. It doesn't matter how easy it is, if you get no commitment, this is a one-sided commitment. Right, you you put the time, you put the work in, and they actually don't commit to anything. I mean, most companies don't even guarantee a review. And if they guarantee a review, we'll see that you want a live review, right? So it doesn't matter how easy it is, it doesn't matter if even if they don't have anyone doing it.

The fundamental power dynamics underlying take home task, it's still broken, which is why we recommend you and you'll see down the road to do as to do as little of them as possible. So, bug, if we cannot do take home task because they are such a bad deal for software engineers, what can we do instead? Well, we recommend that you only do one take home per week maximum from a company that they are fully committed to you and only if you're unemployed.

a commitment, it doesn't mean that they sound nice on the phone. It means you actually had a conversation of 30 to 45 minutes with someone from the company. Not an external recruiter. It either has to be an internal recruiter or a hiring manager. Why? Because these things cost them money, they they pay that person quite a lot of money. And when they pay someone to interview people, they have more skin in the game.

And they're more likely to move you forward through the process because it shows they are committed to you. And then try and get more and better interviews. Fix your LinkedIn, check if your resume has any red flags. If you want us to make a video about the best developer resumes and how to build one that actually converts, let us know in the comments. Fix your screening call performance, so make sure you don't say anything that turns people off.

And then after the screening call, they're like, well, yeah, we will uh we will call you back, but right now we found someone with more experience, that's usually a sign that something went off. And a good rule of thumb is that out of 50 job applications, you should get around 10 screening calls, that's the initial call, uh the phone interview, and from that eight technical interviews. If your numbers are lower than this, that's an opportunity for you to improve something and get good at the live coding.

So it's not easy, it's a meat to long-term bet, but trust me, it does pay off. You want to start small with easy problems, you can try lead code. Use the JavaScript once, if you're a JavaScript developer, then go into embedding binary trees. And your aim here is just to get comfortable writing code and to get faster writing code. Get super fast writing the four loops, the while loops, recursion and do as much of that as you can because then it will become kind of muscle memory.

And you'll perform a lot better. You'll never blank out anymore. And do touch type, I'm still amazed by the amount of people, amount of developers that do not touch type. You want to aim for a speed of 90 words per minute, if the vocabulary is on the English and 60 words per minute if you include punctuation and numbers, we use monkey type or typing club, but get very good. This is a career long investment.

assessment and and asks me, it's what every minute. And once you have all that, then try to negotiate a switch. So you try to push them towards a pair programming or a live coding interview, uh you just propose that. You just tell them, hey, what about uh just, you know, 30, 45 minutes with someone from an engineering team, pair programming? Do your folks offer that? You push it in a friendly way, so you see if that's a possibility.

Don't just take what you're given. One thing about negotiating it's a lot of software engineers we are, you know, non-confrontative people, you know, we are software developers, we work we work with the computer. And the good thing in actually negotiating and as you said, it can be a soft negotiation. You don't have to confront people, it that it also gives them the opportunity to show who they are, right?

If you propose a switch or an alternative and you see that the company is very rigid or they kind of shout back at you, or they kind of try to really move you to the process, then you already learn a bit about them and how they behave. And these tendencies will replicate when you get the job. Remember, when you interview for a company, no matter how, you know, desperate you are, maybe you're not getting a lot of interviews.

Uh you want this process to be a a two-way street. They are assessing you and you are assessing them. And by the way, folks, if you are interviewing right now or simply you're trying to get better, move towards a senior level, the best way for you to start, it's by knowing your angle gaps. Based on everything we've seen at the senior dev, Bug and I have created this free 10 minutes tingle assessment for JavaScript engineers.

Give it 10 minutes, it will tell you exactly what your gaps are and it will give you hints on how to fix it. Link it's in the comments. If I'm still going to do think take home challenges, then what advice would you would you give me? Well, the number one advice would be to get a detailed understanding of what you need to deliver and some commitment from their side. Try to push back on the requirements and negotiate the scope.

Remember the uh the triangle of scope, quality and time. The best way to deliver something in a short time with high quality is by teaming down the scope. So if they ask you to deliver three views and authentication for a front and up, tell them could we just focus on the core feature and we can discuss the other one once in the review. Just to keep the scope manageable. Get him to commit to a guaranteed live review where it's basically in person where you have a call with someone. So basically tell him, hey, you know, I would love to do the challenge. Would be great, you know, that you can, you know, that I could review it once I'm done over 30 minutes with someone from your team.

So you don't get just a generic email like a rejection. Aim for modularity, so keep things as simple as they have to be. Aim for code that's easy to read. Again, people the the engineers looking at this will will spend very little time looking at it. So if it's easy to read and understandable, they'll move you to the process quicker. And make sure you add test. So you definitely need unit test and at least one or two integration test. If not, they'll use that against you.

And think, think about what would you do if you had more time, write it down, but that's pretty much it. Once you're done, you can also try to make a walk to video of the application that and and you send it with the email. And the reason for that is, if you make a walk to video of the application, then the hiring manager and the recruiter both know that you completed the challenge. And those are the people that are more likely to be on your side when you decide.

Because sometimes developers and the people actually evaluating your code, they kind of compare themselves to you and they're like, oh, they're not a senior because I would have done this. And they're totally delusional, right? But because it's an ego move, they will sometimes be more likely to disqualify you even if you did a great job. But if the hiring manager and the recruiters they see that, they are the ones that have the pressure to hire someone.

They're the ones to which the management comes and says, why do we still have five openings and we are slowing engineering? So they have the pressure to hire and if they see you did a good job, they're more likely to be on your side. And once you send it over, just forget about it, focus on your applications. Okay, don't dwell on it, don't think about it too much, you're sure to forget. If they don't answer in three days of max, just follow up on them.

Send an email. Hey folks, checking in on the take home tasks. How is it going? Cheers, be friendly, but firm. One thing I would add book needs, the work to video, it's very important because as we said, when this cut most likely, if you haven't negotiated, you are not going to be in the room when this code gets reviewed. And when opening up a repo, I mean, we see what we want to see. We are all biased as software engineers, if we have more experience with with a certain feature or a certain piece of the code, we will evaluate you on that.

So the walk through video, it's your chance to show what you did, why you did it, right? And to also focus, get them focused on the pieces of the code you want them to see. And understand not everything is perfect, but of course, it's a live coding challenge, put everything in context. Okay, so it's a must, okay? You cannot skip this. The other thing is, don't hang up, you know, give them three days to come back with an answer.

If not, just drop them on email, follow up and move on with other opportunities. We see developers spending seven days on a coding challenge and then waiting for two weeks, right, being paralyzed, just you know, you go to sleep, you think about these things and this is not healthy for you. You have to follow up, you worked on this thing, you need to demand an answer and you deserve an answer because you invested your time.

And you could have been doing anything else. And it's a lack of respect for them not even to reciprocate with a bit of feedback. So is it for today, folks? We'll see you in the next one.