How to Get Hired as a JavaScript Developer in 2025

Hi folks, Dari from DeF N today, together with Bogdan, we're going to go to the whole process from getting technical interviews, passing tech interviews and getting a new position. These are usually the six steps that um pretty much most companies have in their process. So, it will typically start with you applying, where you send your CV. Then you're probably going to have a screening call with someone from HR. Then possibly you might have a hiring manager interview with an engineering manager or the person that's actually hiring for that position, usually an engineering manager. And then a round of technical interviews, there might be one, two, three, depending on the company, we will get here and talk about this in depth. Um, then you will have a culture fit with a VP, like a vice president or um or a head of uh department or with product. And finally, if you pass all those, you might get an offer. So this is the top view of the process. Mhm. Thank you, Bogdan. So, uh folks, for the ones watching us. Ideally, you get more than an offer. And I want to say this before we start. We are in a market where it doesn't matter if you pass all the interviews and the company says they will extend an offer, they might still not do it. So, we're going to start with the application phase, because if you are not able to get interviews in the first place, it doesn't matter how good you are at lead coding or system design or doing technical interviews, you won't even get a chance to show it. So, until you get to a point where you are able to send, I know, 50 applications or 40 applications and get calls back and pass those calls and get technical interviews, your main focus and you should be obsessed about this and most evil is. Don't put nearly enough time because, you know, writing CVs is boring and we all like to build apps and to write code and, and, you know, just looking at the CV and trying to make it better can be pretty exhausting. But you need to obsess about this because this is the foundation, if we don't get calls, nothing happens. Now, in the application phase, keep in mind, the market, it's very competitive, right? We've got people writing resumes with AI. And we have people from all over the world applying to jobs. So, you really need to stand.

out. Now, how do you stand out? And what do you need to stand out? Well, you only need two things. And I'm telling you this from the perspective of someone who helped 300 people, actually land 300 engineers land positions in this market. The only thing we use are the senior devs with all of our students, it's a very well optimized resume, first of all, and then a very well optimized LinkedIn, which basically, if you've done your job with the resume, it's basically a copy paste.

Okay? LinkedIn should be ideally a copy paste. Now, what do I mean by a well optimized CV resume? Number one, most developer CVs that I get, they have big red flags if you have gaps between jobs. If you have um jobs where you you weren't doing too many things technically in between, so for example, you have developers who get a very technical position, then they maybe they they take a break or they they have a um they get a certain kind of job where they weren't doing much.

Another red flag would be if the CV it's entirely written by GPT. And make no mistake, we you can use GPT if you have writers block, you can use GPT to to help you, right? Have a socratic dialogue, ask GPT questions, what should I put here, but you cannot just copy paste from GPT and send it. And I tell you something else, as a business owner, if you do this to me as a software engineer, I will assume that you are lazy, that you are going to, um, you know, I'm going to hire you.

You've done your CV with GPT, I'm going to hire you and you're going to, you know, write your code with GPT and I want to pay someone that actually does the thinking, right? That's and, you know, I could use GPT myself, right? Another red flag, it's always poor poor structure and no solid story. What do I mean? If you go from, you know, front end engineering to full stack, then to back end, then back to full stack, right, you need a CV that tells a story, basically a CV that tells a story of progression.

So every job should build upon each other and there should be no gaps. Again, it's about uniformity and it's about showing a story of progression, okay? The most important position will always be the last one. I advise you to use the commonly used bullet for bullet points format and have at least five to seven technical bullet points, right, if you are looking to stand out in the current market. And Travis, if if I'm my bootcamp graduate and all other people are.

Is there anything more specific that I should take into account should I put the boot camp in the in the resume? This is a bit tricky, right? So there's mainly two cases, right? One, you have experience and even let's say you have five, six, six experience, that makes things a lot easier, right? Uh but I see a lot of experience developers who don't take advantage of that and don't go in depth into their experience.

So if you have experience, make sure you talk about it a lot. Make sure you expand on it. Now, if you don't have experience, you're a boot camp graduate or a self-taught dev or a just a graduate, right, you will need to kind of fabricate experience out of nothing, right? So, basically, what can you do in that case? Well, any boot camp project that you had, I would advise you to deploy that to production.

I would advise you to try to to treat it as it would be a commercial SAS application and then to talk about it in your CV, right, talking about the things that you achieved just like it would be treated as professional experience. Okay, any piece of experience you've got. That can be building your own side project somehow and try to try to make it production ready, or it can be going to to a co-working and asking any startup founder, AI startup founders these days, if they need any help, helping them for free, just for you to get experience.

Just a few weeks, it doesn't have to be months, I'm not saying work for free, but you need to get some kind of experience. It doesn't have production to be like production ready enterprise experience, but we need something because we cannot get nothing out of nothing. Okay, and if if I have a good resume, let's say, so I did all the work and I have a good LinkedIn profile. In terms of how many job applications should I do and what is the typical conversion ratio to get to the next step, which is a screening call and get a position in less than three months.

So, basically, a good CV from the numbers we've seen in the current market should convert, let's use conversion rate at about 20 to 25%, okay? Everything on top of 25% means the CV is doing very fine and it's enough, okay? So that should be around, yeah, 20 to 25%. What does that mean? You send 50 applications, you get at least, out of every list, 10 people. calling you back. And this is when you apply actively.

Again, if you have a very good CV and if you your LinkedIn is very it's well optimized, even in this market, you would still should get around, I'll say two to three people at least every week talking to you on LinkedIn. Okay? So you're going to have inbound applications as well, and you're going to have outbound applications. You should have about 20 to 25% conversion rate. Although I know that the CV is bad, what would be like a very pretty conversion ratio.

So let's say I apply to 100 applications, when do I know the CV I I need to work on the CV? Uh This is very common, a lot of developers I talked to they get about three calls in three months, you know, I talked to people who's have been applying for three months. And they got like five five calls from recruiters. Like that's a disaster. How do you know if your LinkedIn is better? Well, you keep track of things.

This is a one of the big mistakes, it's, you know, you get an excel, right, we we we provide our students with with all these tools and templates at the CNDF. But if you if you don't have something like that, you just get a open a Google sheets or an Excel and you keep track of the positions you apply. You apply to a job, you write down, you write down the name of the company, you write down the position and you write down the application status.

So after you've done, you don't go around and you apply to, you know, 100 jobs. And this is a big a big thing, a lot of developers are lying themselves, you know, they go out, they get some dopamine shots because they apply to like 100 jobs, they don't keep track of anything. They get some calls, then they get some some technical interviews, they get rejected, and then they are back to zero. But they don't know their numbers.

And people say, no, I know my numbers, they don't know their numbers because it's, you know, it's you know with yourself, pardon them back when you're applying to jobs, you know, just going and applying to this job. It's pretty boring, right? And it doesn't pay off in the moment. But you need to keep track of everything without numbers, you won't even know what happens. And do not lie to yourself, do not think it can happen that you apply to 50 jobs, you get some interviews, you pass them, but this is not the case in the current market.

We suggest about 200 applications for you to to get the position. So let's say we're going to start with 200 applications. To get two to three offers. And this is if you've been, you know, this is if your technical interviewing skills are not very rusty. It depends how rusty you are. As I mentioned, consistency is key. They apply to maybe 20 jobs today and then they think they did it and they leave that for the week. So that's why you want to track everything as Drago said. Um, okay. Now let's move on to the next step, which is the screening calls. We apply to 200 applications, we get 40 screening calls, right? Um, let's move on to that step. So, this is our screening call, right? So, what's um can you tell us a bit about, you know, how does this looks like? What should I have ready for this? And how do I make sure I pass them? And also what's a what's a typical conversion rate? Film screening call to technical interviews. Yes, so before we end up the the the application phase, you mentioned something that people apply to some 20 jobs, then they drop it. Okay, um they get some calls. This is what happens. They get to the screening calls, they get some screening calls and then they stop applying. And the one thing they have to keep in mind, it's until you get a sign offer, until you get a contact and you sign it, you keep applying to jobs every single day. The game is not over until it's over. So you don't just get a bunch of technical interviews and now you have no time, then you wake up and you apply to five jobs or 10 jobs every single day Monday to Friday until you get a job. This is the kind of consistency you need to stand out in this market. And that's how you will get first and if you do this for six, eight, 12 weeks, depending on how good your interviewing performance and your CVs, but I can guarantee you, you will get a job. But most most people don't do this. And very important, an offer it's a signed contract. It's not a promise, not an email. They call you back, it's a signed, it's in home paper as the Yes. Not an email, not a verbal agreement, not hey, we love to hire you. No, a signature on paper. Okay. And even if you get the paper, you still do all the interviews you have left. We're going to talk about that. Now, moving on to the screening call. Uh this is very important because because of the state of the market, it's not that, you know, you you can't afford to to screw it up in screening calls. And it would be a pity if they selected your CV for you to mess it up in the screening call. Ideally, just for people to know, the conversion rate should be about 50%, okay? That's when you uh you know, after you practice a few screening calls, uh you should from all the recruiters that are calling you about 50% now, a few things can happen here and you have to be very careful when you analyze this. Basically, you do 10 calls, five of them should proceed to a technical interview. If you feel like you're getting calls,

from people that are offering jobs that are not, you know, they don't align with your tech stack for example. You have JavaScript developers getting PHP calls, right? This is because they there are some mistakes in your CV. You haven't made it clear, is not specific enough, right? So, whenever you see problems in the screening call, they come from the CV, because ideally, right, if your CV it's well optimized and it's aligned with the job position, that recruiter is going to call you up, they're going to go through it, they're going to ask you a bunch of standard questions, you're going to give a bunch of standard answers and they're going to move you forward because there is nothing to there are no red flags. There's nothing to everything looks fine, okay? That's the ideal case, right? But the ideal case doesn't happen because people have um the most common the most common question here is, why have you what happened in your last position? Why are you why are you on the job market? What happened? Right? And we see a lot of people that have been unemployed for a while. They've been unemployed for three months, six months, and they don't have an explanation. It's like, yeah, I got laid off and, you know, I've been job hunting for six months. Even if that's the truth, you know, that's not convenient for a company, you know, companies need to feel like they're hiring people that are in demand. And people that developers that are in demand, they don't spend six months on the bench. Is there any other question that um that you think they should get we should be prepared? That's like why are you on the market? It's one of them. Any other tricky question that they should be prepared for? The other one would be, um, you know, tell me more about your last project or your last position. And um here, you know, you got to keep it relevant. It's not about you, it's about them. So I I I hope you read the job description and I hope you're going to tailor whatever you're going to say related to what they are asking for, okay? And this is a very important change of in mindset, it's not about you, it's about them. You got to tell them something that's relevant for them, okay? The other thing would be, what are your salary expectations? And a lot of people, a lot of developers lose confidence here. You know, they the their voice starts shaking and I think what I would do, if I would be someone that doesn't have this practice, is just to practice, you know, take all these questions, write them down and practice them in front of the mirror and see how they sound. Do you sound maybe do it with your partner, do it with a friend. Yeah. Uh tell me more about your last position. What are your salary expectations? Okay? What should they say when when they get asked about salary expectations? Should I just tell them or?

You know, it's a bit of a tricky question because I'm asking you what are you selling expectations? Like you you're some kind of greedy and you have some expectations. And you should definitely move the focus to the market. It's it's a very straightforward questions if you understand it, right? So basically, what what are you selling expectations? Well, for someone with my level of skills of experience, what I'm seeing right now in the market, it's anything between, you know, 120k and 250k, right?

So, always give a range and do your research and don't obsess over it. People think, no, because you know, I I told them around 150k the US market, or I told them 180 or 250, and actually, I think I could have gotten 260. Don't worry. After the interview is done and they decide to hire you, you can always renegotiate and don't listen to the people of, you know, don't give a number. Because in this market, if you don't give me a number, if you tell me, ah, you know, I you know, let's talk about salaries after I pass the interview.

Then I'll tell you, hey, you know what, just it's been nice to meet you and uh you know, because I cannot proceed with people. I have a budget and I need to know that if I'm going to extend you an offer, it's going to be within my budget. So do not listen to the people of don't give a number, do give a number, do your research, you are a professional, you know your rate, okay? Just go to upsscale, search for senior or mid-level JavaScript engineer and adjust and just give a range within that.

So we don't want to negotiate in the screening. We don't want to get too crazy about negotiation and if that's paid in range, we want to get to the technical interview. to prove our value and then we will have more leverage for us to negotiate. They might ask you, what was your salary in the last position? How much were you earning? And here is very tricky because people are like, you know, maybe you are making 50k and you are in the market for 60,000 or 70,000, or maybe you're making 120 and you want to get 160, right? You should not answer that question, right?

Not at the beginning. So the the way to answer that is, in my last position, I was making about 120k. But for me to accept an offer, it would have to be at least 160k. How much you were making in your last position, it's not relevant. They might use it to low ball you. Don't blame them. Don't don't don't get pissed with them. They're going to do that. It's how the market works. Just sell them, you know?

Like for me to, you know, switch jobs. Okay, this is the minimum that I would go for. And my first answer would be, look, look, I don't think it's relevant what I was making in my last position. But for because for me to accept an offer for. This is how the minimum that it should be. And if they ask again, just tell them, but tell them, for me to accept an offer, this is what. Again, if you look good, if your CV looks solid, and if they feel like they are getting a good candidate, they want, you know, they they will give you what you want, okay? Like, you got to try that companies want to hire you,

okay? Even if it looks like they don't. Really important here, even if it's a tense situation, be laid back. So, like, yeah, um, so this is what I'm looking at in the market. This is what, you know, this is the range I'm looking at, then uh Hm. And not justify your your you don't have to justify your salary expectation. It's just my market rate, you know, it's like, don't fall into I need to justify myself, I need to prove my value. You don't.

So basically, we applied to different applications, we got 40 screening calls, and we perform well in those screening calls. That's assuming we have all these ready, we do not make any of the pitfalls. We end up with let me write it down here. Uh, so from 40 screening calls, we end up with around 20 hiring interview, or sometimes they'll pass you straight to the technical interview. Well, let's assume we get 20 hiring manager.

Okay, so let's move on to our hiring manager interview. Okay, this is about this one. This interview, it's optional. It doesn't always happen, sometimes they they pass you straight to a take home challenge or a live coding assignment direct. Uh, so maybe, you can tell me more, you've done a bunch of those. So how would you how would you go about the hiring manager interview? So here the the attitude and the knowledge, it's mostly what you've been doing in a screening call, but this is a bit more technical.

What do I mean? They won't usually ask you about data structure algorithm, so go in depth. But they will ask you, um, what was the setup, for example, in your last job? Um, what was your role, what was your role? What do I mean by this? Uh, they will ask you like, are you more of a backend person, or are you more of a front end person? And they will want to know a bit about the technical environment, like what was the architecture of your team?

Were you doing agile? Were you doing Scrum? Were you doing two weeks sprints? Were you doing retrospectives? So, this person is more technical. It is they are usually an engineering manager. team and uh it's like an extension of the screening call, but with a more technical flavor. If you do this well, I would expect around an 80 to almost 100% conversion rate. Like, um the only reason you would get rejected here is because you're not really well prepared or the way you're presenting your position, it's not professional enough, you do not mention enough best practices, or you don't ask too many questions and you look like you're not interested. But usually, if you do it well, I would expect around 80 to even 100% conversion. And um here is very important that you, for example, right, some developers, I know some developers in their companies, they don't test their code or they don't have a proper CI CD in place. Or they have no idea about performance, right? And even if your company, like you cannot say, you know, how about testing? You know, I'm asking you, what about testing? And then you you jump and you're like, no, my company doesn't test. You know, you you just failed, okay? So, if you lack some of the best practices, or if you don't have experience with certain best practices, because this is what they are looking for. They are looking for someone that worked in a team, that knows all the agile process, that has an idea about the proper CI CD. So, make sure you understand what happens when you push that feature and be able to explain all the different steps. In your current set of company. And if your company doesn't have that, because some companies, they don't use TypeScript, which is crazy in 2024, but they don't, right? So, if that's the case, then do it yourself and have an idea and talk about the best practices and just show that you know them. Even if your company is not doing it. Yes. So, as I mentioned, you want to know, for example, what was your code coverage in your last job, um all the best practices, but also what we do advice people and what works really well is that they will ask you, and this is 90% of those interviews, they always ask you about, um tell me a situation or a project and what was your impact. And this is where you want to use, I think I got ahead of myself here. You want to use this star model, so situation, test, um action and result and draft out a situation from your last job, it's usually the best if it's your last job where, um you had some sort of technical impact. So you don't want to be generic here. We really want to say things like

Well, in my last job, you know, we wanted for example to improve the web performance of of a specific application. We were at 60%, whatever, lighthouse score, this is a very common one, and I did ABC, and we got it to nine. And here, um, you want to be able to uh to show that ABC and all the technical decision making you did in the process. So take out, you know, take out that your war document, write this down, and be ready to tell it to someone that's not super technical, like a product manager, but then also to say the same story with a lot more technical depth to an engineering manager or to a software architect or principal. Yes, so have some stories prepared. And I would say the the favorite ones I bought, and you mentioned one story about impact, short story. I mean, you don't have to obsess over this, but you need to have at least one anecdote, one story where it's clear, you know, what was the the star, right? The situation task, um, I think it's action and result. Something like that. But, you know, have one about impact and have one about conflict. Companies can't afford to hire people that don't deal well with conflict, because conflict is going to happen. So they might, they want to know that, you know, that number one, you're there to make impact via your coding skills, and number two, um, you know, how do you deal with conflicts? And this can be pull request denied, or it can be a disagreement in a technical discussion, anything that involves conflict. The typical question, um, you would get a lot if the if the hiring manager is really prepared is, okay, you you pushed your code, you open a pull request, um, you got requested some changes, you do not agree with them. What do you do? Say, what do you do? Do you go and comment in range on the on the pull request? Do you jump on a call? Uh, what what best practices do you use to make sure the team reaches an agreement? Um, so solid principles, we talked about code coverage, and here you want to be able to have one story, one story prepared as they were said, one about action and result and one about conflict should be more than enough to stand out. Um, we could talk hours about this, but let's move on to step number four, which is the technical. I think, this is a very big one, we're gonna try to to keep it short, there's different kinds of interviews, maybe we can go to each one of them. And I definitely think that all most of the content here on YouTube, it's very much biased towards

coding and otherwise the fangs. So we're going to try to give you a more realistic overview of the market. Most software companies are not fang companies. So let's we're going to give you an overview of the market. If you are not going specifically for the fang, this is what you should expect if you're interviewing right now. One of the easiest time one to interview would be the question bank. We have a couple of them in a channel where basically the algo is just asking me questions and he they will start with, okay, can you tell us about code splitting or web performance. So sometimes they are super ended, open-ended, like um how were you doing state management and explain me this? Or sometimes they are really concrete like, do you know what area role labels are or do you know what a blue green deployment? Or can you tell me the disadvantage of a microservices or microfrontance architecture? Um but this is one of the easiest, I would say. When they tell you there's two engineers, you join and they'll just ask you exploratory questions. And by the way, if you're preparing for that kind of interview, make sure you take the technical assessment. We actually built it with questions from that kind of technical interview and I can promise you if you take this one, you will find them in technical interviews. We're going to drop the link in the comments. Or the question question bank do the technical assessment like mentioned. And um also you don't have to what do we do if, you know, I've done the assessment, I you know, I check my JavaScript fundamentals, I check my react fundamentals, I check my AWS fundamentals, right? So I I reviewed all that knowledge, but um you know I'm going to face let's say there's like, I know, they ask me 10 interview 10 questions and I fail about, you know, I have no idea. I never work with that stuff. How should I go about? I mean, the easiest thing is if you if you see the same question and that's the one you blank out, like let's say I'm a front end interview and front end developer and uh I get questions about AWS and every time I go to interviews, that's the one where I blank out, that's we definitely need to do something there. We definitely need to get into deployment. So you want to you want to close that gap. Um if it's something you never heard about, just as the interview, be super chill and be like, well, um to be honest, um I I wasn't, you know, in my last position, I didn't have the chance to touch upon that um and let them give you the insight or or at least the

what they were looking for. So be okay with not knowing everything. I mean, if you if they ask you 10 questions and you don't know any of them, well, you know, that's a pity you probably they probably are going to move forward. But if you, you know, nail about 70 to 80%, they're still going to pass you forward. The other thing is you want to make this a conversation, so then get into the mode of they asking question, you answer and and that that's a very hard position. It's kind of you against the wall. Um, so try to maybe be very chill and just be laid back and be like, oh cool, so the way I would go about this or um what we used to do um or you know, what I've seen in my past position. This is what we're going to do and inject a lot of best practices in your answer. So you want to be casual, but still add a lot of expertise to your answer. I'm going to go on with number two, which should be again, the take home task. And we see people getting a lot of those lately. And the problem with the take home task is it's something that they will send you over, you need to build and send back a lot of people prefer this because they say, well, you know, I I'm afraid of live coding interviews. We will talk about those, but the problem with the take home task is that they are very intense. It takes a lot of time to build one of those and really get past. So, usually a company would say, you can build this in two hours. That's usually never almost never the case, it's usually takes around at least eight to 10 hours to deliver something good. Uh we've seen developers spending 16 to 20 hours on something and then getting back like a generic rejection email. So, um what we would advise here it's because we have three months, right, to find that next position. I wouldn't take more than one a week and I would be strategic. And pick take home tasks that would allow me to develop some skills that I can use in my next interview. So, if I have a take home task and I know I need to learn AWS, I'll probably try to deploy the project I'm building. Again, the biggest mistake with a take home task, it's spending seven days on on something to make it perfect and then uh getting a generic rejection email. Which happens every day. Right, you cannot put all your eggs in one basket. So you have to cherry pick. And what happens, well, you know, some companies, you're going to say no, they're going to send you a take home task. They will tell you it's about, it should take you around four hours. Um, it's going to take you at least than hours.

something um that's worried that that that's acceptable. So, number one, avoid take home task. And you're going to, how can I avoid them? Well, get good at live coding interviews. I know it's hard, but it's going to pay off, you're going to find out why. And and secondly, cherry pick, so you cannot afford to spend seven days. If you're spending if you're investing seven days on something, um then you're going to you're going to be disappointed, you will burn out.

And this is one of the main reasons why why I see developers failing, you know. They tell me, hey, you know, I've done this take home task, I I put I put the whole weekend into it and I got a generic rejection email. Well, you shouldn't have done this in the first place, you're going to burn out and you're going to drop the drop the race before you get to the finish line. Yes, that's a lot of what a lot of people do and they kind of kill their process because while you're doing the take home task, you're not doing, you know, hiring manager interviews.

You're not doing screening calls, you're not applying to more jobs, you're just exhausted because you spent 20 hours on something that maybe they don't even look. So, again, uh pick your battles, be very strategic. Make sure it's a company that you kind of see that committed to you um and don't do more than one a week. Um, so moving on to the live coding interview. Uh this is one of the toughest. I we could spend hours talking about this one so be very honest.

We do have in the on the channel a lot of examples of what you can expect. Um, a lot of people would go on lead code for months before they interview. That's not a good advice. There are good problems on lead code you can prepare. But you need to be very strategic and just to make it really quickly, to give you two advices would be number one, get really good at touch typing. And be able to write things like four loops and iteration very fast.

And number two, get good at recursion, be able to go from a for loop or a while loop to recursive functions. And back to um from a recursive function to a for loop. And number three, get very good at big O notation, which is not that complex, so you can do like time complexity and space complexity analysis in the interview. I would aim for a 50% conversion ratio in live coding. So, if you get rejected, just be chill about it and every interview you do and you're showing up, it's a win.

So, that's how you handle um rejection. Check out our videos on live coding. There's a lot to talk about here. A few a few more words on the live coding interview, most developers avoid them because they go blank. blank because as Bogdan said, most people, they work with React, they work inside of all these abstractions of the framework, they they they always work with React. Some of them don't know how to write a simple for loop.

You know, when you have to do this thing live, you know, you won't, you don't have time to think. To succeed in the tinkle interview today, you need to do the things that you did not want you to do as a software engineer, right? You need to obsess about the details. You need to write for loops and you need to write while loops on top of your head. And maybe this sounds stupid and it sounds boring, and why are they interviewing me on this? Well, it's because they can, okay?

So don't think about it, just do it and do the basics. Okay? Obsess over the basics. There is no way for you to get it right. You need practice. The other thing, talking about lead code, I'm talking to a lot of developers and they they go online, they search tinkle interview preparation and they get a lead code some lead code and they are like they spend three months on lead code. They don't stick to it because lead code is hard, they don't check if they problems and then they quit all together.

This is too hard. I'm not going to do it. Yeah, you do not need to become a master on these things. You just need to be able to know enough about to know enough to handle around 70% of the problem. Don't get into dynamic programming if you're not going to interview for Google, right? Avoid lead code hell, just get good at the basics. So, no dynamic programming unless you go for Google and no greedy algorithms and no graph problems if you go for Google.

They won't ask you those. And a linked list, you know, if you go for the Fang maybe, but if you go for your typical company, recursion and integration should get you out. So last but not least, there's system design. If you are in the US market, you will for sure do system design. In the European market, it's a bit less common, but it's starting to get more and more common these days. Um, but it's a core type of interviews.

Um, we have a couple of them again on the channel and here it's very important that you're able to um, kind of go from some fizzy functional requirements to non-functional requirements and then to a system that satisfies those requirements. It can be front-end focus, it can be back-end focus, and then you are able to talk about scalability, availability, deployment and architecture. Again, there's a lot of resources out there, we we post some of them on our um, on our channel.

It's really important here that you are able to talk how somehow lead the interview to things you know. So if you have front end oppression, you definitely want to spend a lot of time or lead the interview to the front end. If you are back end, always always play at home, always play on your stuff. But again, in terms of difficulty, if we were to rank those, probably the easiest interview it's the questions bank. Then uh it would be live coding. Then there's take home, which is not hard per se, but it's very unlikely that you get it's a lot of tough control. And system design will be somewhere in the middle. It's definitely easier than live coding, but it's a bit harder than the question bank. Okay, now let's let's rewind a bit. So we got um we got 30, whatever you said, we got around 20 hiring managers interview, and out of that, um we converted, let's say 16, right? to 16 technical interviews rounds. Um, what would be our like a good conversion rate? I mean, this is tough to assess um because again, it's a process, right? You start you start wiping up, but I would say at least you should pass. about 50% of the think interviews go and make. Anything below that means you have some some big gap in your think skill. Yeah, I agree. Or it means you're doing the wrong type of interviews. Yeah, so 50, even 40 would be okay if you if you have very bad luck. Um, but ideally, because this is a round, so there might be two or three interviews. And so it kind of compounds, right? Um, so basically, we would be able to go to eight culture fit interviews. Um, maybe only six, let's say, you know. I mean, ideally, most most developers they get stuck here, they get a bunch of rejections, they waste their time doing way too many take home challenges. They don't improve their live coding skills. They never get to the system design. Now, in the live coding interviews, we we don't have to go time we don't have time to go that deep, but there are again four types of so interviews right then you can get. Vanilla JavaScript like coding, you can get react like coding, so it takes time. This is why said that this is an aggregate, okay? Now, my advice here, it's, you know, if you are able, if you've done everything correctly and you are able to get tank interviews and just do tank interviews until you get the new job. like do not quit, right? Um, try to get there's so many variations as you can see.

going to get these right the first, you know, at the first on the first right. So what we see people doing here is that they get maybe too optimistic or they just hope that the next interview will be um the one that they will close and they never have to do it again, but the good attitude would be, I'm going to keep doing this until I get good. Yeah, this lot getting thinking that we see um all time like this next interview, maybe I get this one and I don't have to I don't have to get good, you know, maybe this one goes well.

That's that that mindset is going is going to screw you because you don't know, okay? And the other thing is falling in love with companies. This is generic overall, but you know, people get to a technical interview and then they stop applying to new companies and they just, wow, this company it's amazing. I passed the first technical interview, I passed the take home task. Now they invited me to a live coding. If this goes well, um, you know, they maybe they make me an offer and maybe this whole nightmare, it's over.

And this is the bad thinking. You have to really have no feelings, uh just go to the steps, very consistent and keep applying to other companies and keep again, play the table, not the hand. You don't know. The interview can go great, you the even if the interview goes goes great, you might not get an offer. And that's why you got to take care of yourself. You always got to have been interviewing with other companies.

Exactly. Now, let's really quickly move on to the culture fit. What what can you tell us about this one? Uh, I mean, this is I mean if you get here, this is, you know, here it's starting to get easier. Um, you've done a bunch of them. Basically it's about doing a bit of research and honestly, I mean if you get up until here, this should this culture fit should ideally go smoothly um you can mess it up by not being prepared, by not, you know, checking the company's values, seeing how you can fit, being open-minded, being interested in their in their mission and vision and showing and and showing that you want to understand how can I be a fit, right? How can I help you realize this mission and vision that you have?

Most tech companies exist for a reason, right? They want to change something and they have certain values. You've done a bunch of them, maybe you can add a bit on that. Yes, as you mentioned, know the company, know the team, know what they're trying to achieve. Why are they hiring you? Get them to talk a lot about that. Refer to information you got through the interview process and um make sure that you look like someone that it's kind of pective. So they will ask you things like like one of the most common question here because again this person is not super technical, they might be a VP, they might be like more for manager.

They'll ask you, what do you do to improve your skills? And then you don't want if you're going for a senior position then say online courses, like Udemy courses and mention that, that will make you look a junior. Um, but again, you want to ask a lot of questions about, okay, what would be the uh what are you looking in a next person joining the team or what do you think about the team? What are the challenges they're facing?

What is your plan for the next one to two years or what would I need to be successful in this goal? These are the typical questions and this is usually an easy one. If you have the right mindset, you should get 100% conversation. Like you should never get rejected at this point. Again, the rule here is get them to talk, be interested. Yeah, get them the opportunity to tell you how you could fit in the company.

It's not about you. The whole interview process, it's about them making a hiring decision. So, make it about them. The more you can show you are interested, the more interesting you will be as a candidate. Perfect. So, let's assume from the six cultural fit we got, uh maybe we can move four of them to offer. Let's just say I would say at least five, you know? Ideally at 100% because this is not a tough interview.

five offers, which is better than pretty much anyone in the market, right? Perfect. So, what about the offer stage, George? In terms of negotiation, is there anything you want to um you want to tell us here, especially in this market? I feel like companies are trying to lowball candidates all the time. Um, so is there anything you want to uh to share with us here? Yeah, number one, get rid of FOMO, you know?

We live in this um social media age and we compare ourselves and we compare salaries and maybe maybe some of your friends are, you know, earning 5,000 more than you are. Uh, really be realistic about, you know, I see a lot of developers going to this um offer interview thinking, oh, you know, I'm sure I'm sure I'm living some money on the table. And I think this is the way uh sure way to be unhappy.

Even if you even if you uh live about, I don't know, 5k on the table, you know, you you got like, I don't know, you get 140k and you could have gotten 145. After tax, it's not a lot of money and trust me, once they see your value, you can you can renegotiate down the road. Now, you do want to to try to negotiate your offer. Yeah, if if you feel like, hey, I can get me a signing up, I can get a signing bonus, I can get more vacation days, like pay time off, right?

So, um number one, get rid of FOMO. Number two, do not have any emotions in the uh in the process, right? And you want to make a counter offer. For example, you know, let's let's simulate this, right? Hey, we would love to hire you. I would find love rates 150k if you're in the US. or let's say 180 to 250, I don't really care. And then you can say, hey, you know, I love your offer, uh I believe, you know, it's definitely a great offer.

And then state your number and ask them, is there anything you can do to close the gap? And this is the mindset you want to have. You are just asking them, you're appreciating the time, you're appreciating the offer, and you're asking them, hey, you know, are you open to something more? Just to see what's on the table. Make sure I hear that you come from a perspective of, um, can I know your Batna, which is your um the if we can handle here this was your best alternative.

If not to negotiate like, you know, what would be the lowest you want to go to, you know, would you accept the offer that they made you if they give you nothing, if there is zero, you know, if you get zero out of the negotiation, would you still accept it? Right? Have have an idea of these things, but don't don't obsess over them again. Yes, and try to do it over email, okay? Then in in you just asked me that on video and it's kind of it's very intimidating.

Unless you're very experienced, um if you're an engineer, if you're coding, most of your time you're not negotiating every day. Um, so do try to move things over email. The other thing is, I remember being an engineering manager and was making this kind of offers to people and um some candidates would be very aggressive. Like they they would go in and ask things that maybe no one had in the team like, oh, but what about um remote and what about hybrid?

And at that point, we were in the office, right? Remote was not something we were offering. Um, and it was kind of you would already know they are a Taker and sometimes we would did withdraw offers because of how they behaved um because I would tell them, hey, look, uh they would go in and be like, oh, but there's this other company that offer me this and try to uh pressure us. And um the only thing that achieved is that we moved like we have people in thing interviews that maybe didn't do that well, but we would push them to offer just to to make sure that we don't bring someone in that it's a taker. That's just looking for like, oh, what about this, what about that? Because if they do that in the offer stage, that's already a very bad vibe to bring into it. So don't be don't be a taker, always look for a win-win. And I think people they they some made mistakes, you know, number one people are like, no, I don't want to be an asshole, I don't want to be a taker, I don't want to come across as a taker, so I'm not going to negotiate at all. And this is a very big mistake because you have to understand uh you're not going to get a lot of chances. to negotiate a pay raise, you get an initial salary, you're going to stay quite uh you know, you're going to stick to that salary for a long time and if you never negotiate, you never get the practice. Now, I understand why people because they don't know how to do it properly, most developers, so they're like, I better not negotiate at all, just get the offer the market is bad. I was underpaid for years because of that mindset. And the second part is people going and reading these articles and try treating companies like, you know, like you know, like they're trying to to take advantage of you. And my rule here it's, you know, treat people like you want to be treated and do not come across as a taker, but do have a strong boundary. This means we can talk about numbers, we can talk about salaries in a chill way, out of emotions, just looking at the facts. And always be grateful for the opportunity you've been given. Don't forget. Okay? They are extending an offer, you know, they might want to work with you. Would you like to work with someone that's like, hey, you know, but you know, these other company, like work together with them. You know, you're not they want to hire you, you want to work together, you just want an agreement that it's beneficial for both for both parties. And forget the internet, forget what your friends are making, you'll never be happy. Analyze the whole package, look at the remote, look at the paid time off, look at 401K, um the whole contribution package comes into place. And then compare yourself with Silicon Valley numbers, they usually include a lot of equity. That's not cash compensation. You can you can be making six figures, if you're always thinking about your friend that makes 120, you will never be happy. There's always someone that got it a bit lazier than you in life, okay? Perfect. So, there I'm just going to review this really quickly. So we said, hey, we need a job in 3 months, right? And we're doing this full-time. So we mentioned we need a very good CV, a resume and LinkedIn profile.

and we will apply for around 200 jobs. Um I think you can usually apply for 10 jobs an hour if you are well organized. So this should take you around 3 hours over 2 weeks. Um you should out of that get around we mentioned here uh 40 screening calls and with a 50% conversion rate go to 20 hiring manager interviews. And out of those uh will out around 16 technical interview rounds. And then from that at the 50 or 40% uh conversion ratio go into around six culture fit interviews and out of that get five.

Oh, which is pretty solid in three months in the kind market and that would be kind of the overview of the whole process. Anything uh to wrap this up, George? Any. Now, we try to give you absolute numbers, uh there's a lot of complexity, each of those interviews has its own level of difficulty, its own nuances from the, you know, the CV part to the live coding interview, to the take home challenge.

So if you want Bugden and I to make a video specifically about each one of those, uh stages that just let us know in the comments. If I were to abstract this in two things, it's number one, getting interviews and number two, doing interviews. Anything that you're doing that is not these two things, if you're looking at AI, if you're looking at blockchain, if you're looking at VR, there's some other developer out there that's getting interviews and doing interviews and they will get the job.

Okay, anything that you're doing that's not this, you're failing. You have three months, three months is not a lot of time, if you're employed, if you have a family, you have a few hours every week, a bunch of hours of time and it's not even the time, it's the energy. So you got to be strategic, you got to be smart, you got to follow the advice that Bugden and I give you, and if you're interviewing right now, no matter how well you do it, it's going to be hard.

We wish you the best of success, okay? It's not easy, but you can make it. With that being said, check out the free Thinkle assessment, if you want to find out where you're at in terms of Thinkle gaps. Check out the channel because Bug and I are putting a lot of videos out, specifically focus on the technical gaps because that's the gap we see right now in most developers, thank you, thank you so much, Bugden and we will see you folks in the next one.