#253 - The Real-World Step-by-Step Guide to Tech Interviews (Not for Google or Meta)

Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network, and more. I'm Brian, your host. You've probably heard me talk a lot about tech interviews on this show, and that's because I know how important they are. I went from being really, really terrible at tech interviews and basically avoiding them at all costs to kind of becoming obsessed with them over the years. And there's a good reason why there's so many industries and courses on interviewing, because if you think about it, whether you're going to a college, a bootcamp, some sort of mentorship program like Parsity, or learning on your own, your ultimate goal is to get to an interview and then pass that technical interview. The problem is, most people go about interviews in the absolute wrong way, and I know because I was one of these people, and now at Parsity, I get the pleasure of helping people out to pass the technical interview based on my years of experience, bumbling around, being terrible at them, paying $10,000 to learn data structures and algorithms, then finally going to places like Google and Facebook and all the fancy companies in Silicon Valley, failing a lot of those problems and a lot of those technical challenges, and also acing a lot of them and having a world of opportunity open up for me. It's one of the reasons why I feel a lot more confident now and I know what it can mean for your salary as well as for your confidence as a software developer. But the problem is, the problem that I'm very painfully aware of, because I see this at Parsity. In fact, we had a few people at Parsity come to Zubin and I and say, hey, I had an interview, and they kind of told us some of the things they did that we look at and we think, oh man, that wasn't a good move, right? The stakes are high when it comes to technical interviews. They're hard to get, especially if you're at the beginning of your career, or maybe even if you're not at the beginning of your career, they can be really difficult to get. And when you get them, you don't wanna just let them slip away like sand out of your hand, right? You wanna try to nail them as best as you can. So I'm gonna go through some very practical strategies that you should be doing at every stage of the interview, going through negotiation to help you increase your salary. And this show, as a matter of fact, if you get nothing else from this show, I can basically guarantee you that if you follow these steps, especially the negotiation stuff, you're probably gonna get an extra 10, $20,000 in your salary just from doing that. So yeah, go ahead and listen to this show. I swear to God, if you get nothing out of Parsity and you went there and you got strictly only interview help, in my opinion, you've already paid for the price of the program. And if you go get another job after that, then you've basically doubled your investment in the program. That's how confident I am in this stuff because I used to do a program where I only taught people how to pass the technical interview. And I saw how life-changing it was for many people that went from 60, 80,000 to 100,000, or go from like 50,000 to 120,000. It's pretty wild, the stakes that are in interviews. And if you do them well and you can get them and then succeed at them, you can make a lot of money, like it or not. I know it's kind of a lame thing to have to, I know it's probably not what a lot of people wanna hear because they're like, well, that's so biased and unfair. It's not like what I'll be doing in real life, right? But it's a game. It's like a carnival game. It's like a corporate carnival game where the stakes are high. And if you spin the wheel and win, you could get a six-figure salary. So anyway, without further ado. And I wanna give a short disclaimer. This interview advice I'm giving is for people that are not going for big tech companies, which should be the overwhelming majority of you. Now, I do understand that there's a lot of desire and there's a lot of major, massive benefits to going into big tech. I'm not gonna pretend that there's not. I'm not against big tech at all. In fact, Zubin, my partner, went to Google and I see how powerful that is for his own brand. And I see how beneficial that is, not only for him, but for anybody that's gone to big tech. That little badge on your LinkedIn or resume can basically carry you for years. It immediately gives you credibility, immediately gives you validation, immediately makes people think, damn, you must be pretty good. And they're probably right. But this show is not for them. So if you're only interested in going to Google or some sort of big company, OpenAI, Fang, whatever, then go check out Zubin's article on how to beat those interviews, because he is an expert at that kind of thing. I am not. I am talking to the 99% of developers who will never get into big tech, but are studying as if they are going into big tech, which is the biggest mistake I see people make. They go and try to learn 500 lead code problems, or they buy something like Algo Expert, which by the way, I think is a great program, or they just kind of wing it, right? They go on like Code Wars or do these random coding exercises and challenges that don't really have anything to do with the types of interviews they get. And what's worse is, many people are doing all this studying and don't even have an interview coming up. So here's how your interview is most likely going to go. There are a few stages of the interview. Now, the first step in your interview process is gonna be something completely non-technical. It's gonna be you talking to a recruiter. This is the filtration process, where they're gonna basically do a vibe check, basically a sanity check to make sure you're not crazy or just really, really weird, and then probably gauge your technical ability and see if you're like a decent match based on some basic technical requirements of the job. A lot of people mess up at this stage and they don't even get to the technical part. I've done this as well, because you're probably not understanding who's your audience when you're talking to the recruiter. Most recruiters, by and large, are not technical. So they're trying to assess you based on a list of keywords and like a technical wishlist that somebody gave them. I was in this position. I was a hiring manager at one point. I was an engineering manager, rather, and I would give somebody in this HR division a list of technical skills I wanted the person to have. And somehow they took that with a list of the old skills we have, they mashed them together, and I saw the LinkedIn post, and I was like, that's not really what I said, but I'm like, whatever, I'm really busy. I gotta get back to what I'm doing. This person would somehow vet these people. They'd look at their resumes and then pass on the ones that they thought were good to me. So think about who your audience is when you're on the phone with this person. Again, this person's probably not super technical. So when they ask you questions that are really loaded, like on a scale of one to 10, rate your proficiency with JavaScript or Angular or React or whatever, and you say something like seven or six or five, they're immediately thinking, no way. They don't know what that means, and so they're like, I don't wanna take a risk and have me look dumb by putting you forward as a candidate to the engineering manager or to the team to waste their time on you. So I'm just gonna filter you out immediately. They're asking questions to basically filter you out. How many years do you have with this technology? How comfortably do you feel with this kind of interview? Are you able to work X days in an office? Are you okay with this type of salary? They're asking all these questions to essentially make sure they don't push you through to the interview if you're already not gonna be a good candidate. So a lot of this is really subjective, and my basic rule of thumb is tell them as much as they need to know and nothing more. Give them the minimum effective dose. Tell them what you think they need to hear in order for you to get to a person that can assess you technically. Maybe I said that in a weird way. I wanna make it very clear. Do not lie, right? Lying by omission is still lying, but what I'm saying is don't offer more information than they need to make a decision. For example, if they say, hey, what's your proficiency with JavaScript? Be like, I'm really proficient and strong in JavaScript. I'm confident in my JavaScript skills. And they say, hey, on a scale of one to 10, how would you rate yourself? Say, well, what do you consider a 10 and what would you consider a one? Because I know that's fairly subjective, and I think that I wanna make sure we're using the same scale. You can kinda turn it on them and make it a bit of a joke. Now, they might be a little uncomfortable too, because in reality, they don't know probably anything about coding. So as long as you make them feel comfortable, ask yourself this question when you're talking to them or really at any stage of the interview. If I was talking to me, would I hire me? Remember, if they're an external recruiter especially, they really gotta be careful because if they send junk candidates to the client, to the company to go interview, and the company's like, who the hell are these weirdos you keep sending down here? They barely know how to do a for loop or whatever, right? And that person's gonna get fired. So they wanna make sure that they look good by presenting really good candidates. So make sure you don't give them reasons during this initial interview to filter you out. For bonus points, do a little bit of research about the company. I'd look up the about section, some of the values that they have, and try to just incorporate those into your answer. And I think you're gonna get a lot of bang for your buck in this case. And if they really nail you about salary, first of all, you don't need to tell them what your salary is or how much you want to make. In the USA, that is in many cases illegal, and it's just not a necessary thing. You don't have to tell them what your salary is or your salary requirements. You can just say, I'm open, and I'm just looking for basic market range for my area. And then you should turn it back on them and say, what can you tell me about the salary range? Because oftentimes what they're trying to do is honestly just lowball you. They're trying to say like, oh, will you take 80,000? Oh, well, damn, great, because we were gonna pay 120,000, and now we know we don't have to go that high up. Don't worry, by the way, if you mess this up. I've totally messed this up before, and then I've negotiated at the end for much higher salary. So just because you say you're okay with something doesn't mean you have to stick to that number. But if you can, please don't give them a number. Do everything you can to not give them a number. And ideally, they should give you a number. And if they really won't, go on Glassdoor, see what you can find about the company, and say, well, I see from some research that your range is around here, and I'm hoping to come in around that range as well. And if they ask for a hard number, just say, well, it depends on a lot of factors about other offers I may have at the time, but I'm totally reasonable, and I'm willing to work with you should we get to that stage in the interview. Very diplomatic and presidential response, right? So the next step after this is almost certainly gonna be the technical interview where they're gonna invite you onsite or online or somewhere to do some sort of coding challenge. It may be with another software engineer. It may be one of those take-home stupid exams, which I hate. Or it may be something like an automated test, which I hate even more. Now, for the dreaded take-home exam that's supposed to take like two hours, but really takes a whole weekend, you really need to decide if this is your best use of time. If it's a company you really wanna go for, then absolutely, by all means, do the coding challenge. I really, really don't like these types of challenges because they take up a lot of time. It's completely unclear what they're usually grading you on. And sometimes it just feels like it's a waste of your time. And they always take longer than they should. So here's a few ways that I've told people over the years how to have the best opportunity to actually pass these. And it's pretty simple. One is to write some tests. If you don't know how to write tests, sue your bootcamp. You should have gone to Parsity. And also just pick up my testing kit, which is in the show notes, which I'm just gonna give you for free. It shows you some basic front-end testing stuff that's gonna help you out tremendously. Hey, I hope you're enjoying this episode. Now, you know that I own an anti-bootcamp with my buddy Zubin, an ex-Google software engineer. If you're interested in not just learning how to code, and you know it's gonna take more than three months, and you're serious about making a transition into a career in software, and you wanna work with people that have done it before and are currently working in senior-plus levels, join me and Zubin at parsity.io slash inner-circle. You can learn all about our philosophy, how we approach learning how to code and switching careers in a much different way, and how we have so much gosh-dang success. If you're interested in being one of the few people that works with us this year, go and apply at parsity.io slash inner-circle. And now, back to the episode. So yes, write a test or two, not like a really lame test where it just checks like, did this thing appear in the screen? Test some actual functionality. If you have a back-end component, test part of that back-end component to make sure that the API response returns what you think it's going to. This is gonna help you out tremendously. In fact, I remember years ago helping out a mentee with this and telling him, hey man, you better put some tests in here. And when he got invited to the onsite, they say, hey, you're one of the few candidates that added a test in this challenge, and that's the reason why we invited you onsite. So yeah, write some tests, make sure they don't suck, and don't, for the love of God, just use chat GPT or cursor. I actually saw a ton of this in a recent interview challenge that I was doing, and I was like, wow, how many people just put together this AI-generated slop? And it's very, very clear, honestly, because the way I can tell at least is that it's over-engineered, like way over-engineered. I'm talking about they had like a rate limiter. They had some sort of like super complex front-end or whatever for something really simple. I'm like, why? Why did you do this? And why would you think that people couldn't tell that this was completely AI-generated? It was like obvious the person hadn't really written like any of the code, and it didn't even work. I was like, what is this? I guess when you're doing a bunch of take-homes like that, maybe it's a way to just do a bunch of them at scale, I guess, but yeah, it's not gonna get you anywhere. But having a really good unit test, having a readme where you explain the code, maybe even having a really small video using Loom where you walk through some of the gotchas and say, here's some of the trade-offs I made, and explain why you did what you did within the time you had, and then you can even use that video to see how many people watched the video, how long they got through it. You can look at the analytics of a video using Loom at least that I'm familiar with, and you can see like, oh, did people actually watch the video? Where did they drop off? Did they leave any comments, or what was something that may give me some indication of whether I did a good job or not? Either way, it gives you some extra bonus points. It lets them see you as a human rather than just another number in a system, and the test will show that you're an actual software engineer rather than somebody that didn't even think to do tests. They didn't even think, oh, why would I have a test? Like, yeah, you should have tests because software teams write tests. That's what we do day to day, and most people will not do this, so you don't wanna be like most people. If you're trying to stand out, it's really difficult to stand out on code alone, so having a readme, having it easy for the person to set up, having a unit test or two and explaining how to run those unit tests shows some thinking and shows some software engineering skill past just the trivial. Now, for the other types of coding challenges that involve like some automated test whatever, these honestly are really hard to quote-unquote beat, and a lot of people just cheat on them. Honestly, these are basically luck of the draw. You could get something as bad as like trivia, like coding language trivia, like explain this weird concept in JavaScript. If I have a for loop with an asynchronous request in it and then I console log I in the for loop, what am I gonna get? And it's these weird, tricky, parlor trick JavaScript questions that don't really tell you anything, and it's multiple choice. These are evil, and these are usually given by companies that have no clue what they're doing in the first place. They're just like, I don't know, let's use the old exam we had from 1995 to see if people know some JavaScript trivia because that's what we do on this job. We do JavaScript trivia in our code base. We have to support Windows 95 and IE 11 still, so we need you to know this stuff. So you're screwed if you get these ones. Now, here's the most likely scenario. You're gonna get some sort of challenge where you're gonna be on site or online with somebody, and they're gonna test you on something like React or build a component in front of me. I've actually gone over this in depth. I even have a video on this that I'll share in the show notes as well, and this is the most common exam by far. This is the most common technical challenge you're gonna come across. It's gonna be some version of, build me something with React. Here is an API. I want you to call that API. I want you to fetch some data. I want you to display that data on the screen, and people fall apart because they're not used to doing this with a person watching. So their nerves are on 10, right? And they're barely able to type what they could normally type out. They might already have a problem doing this without anybody watching. So now that somebody's watching, they're really messing up, and they're trying to get through it, and maybe they even do, and they still don't get an offer. The reason why is because what's behind doing this kind of technical challenge is not just saying, hey, do you know some basic React? It's like, hey, how's it like working with you? If I throw in something that maybe doesn't work or we add a bug or something that we need to debug together, how do you think through it? And so that's really important to talk through the problem. Think of it like this. Here's the framework I use. I always think of I'm the teacher, and I'm teaching the class these concepts as I'm typing code. Now, I have a lot of practice doing this. The reason I have a lot of practice doing this is not because I own Parsity or literally do this in front of people. It's because I spend a lot of time getting prepared for interviews using a camera and my keyboard. I would put myself on video, very uncomfortable at the time, and I would talk through doing problems that I knew I'd probably get in an interview. At the time when I was doing this, which was like five years ago, it was things like closure, asynchronous requests, also building React components, but a lot of vanilla JavaScript concepts that I knew would come up in an interview, so I practiced talking through these on camera, and it really showed me some serious gaps in my knowledge. And I was not like a junior developer at this time. I was well into being a senior developer, and it still exposed some gaps in my knowledge. Things that I thought I understood, I realized I couldn't articulate. So getting on camera, as awful and awkward as it is, is literally the best way for you to practice doing this stuff. Why wait till the interview to do that when you could do that on a camera in your own home, and you could destroy the video once you're done? Who cares? You don't need to actually watch the video. You just need to be able to be on video, and then explain a concept as if you were in the interview. Now, I would also use a tool like Pramp.com. Pramp.com is a free site for the most part. You get like five free interviews a month or something like that, which is more than you'll need, because most people are not gonna do this either. I do this. I recommend all Parsity students do this. In fact, this is part of the Parsity curriculum, to do interviews through Pramp, or to do mock interviews with me or Zubin. So yes, that is what we do in our program as well. You're on camera quite a lot, because we know that that is the most effective way for you to learn, and it will prepare you for your interviews more than anything else. So take on the teacher-student mindset, where despite this person probably being a senior, or a CTO, or whatever, you are talking as if you're teaching them, because that is how you're gonna display your knowledge. It's how you're gonna become more calm during the interview, I think, as well, because now it's not about, hey, can I get this question right? It's about me going through a problem, explaining it to you, going through the trade-offs, explaining why I'm making the decisions I'm making, because now you can see how I articulate and speak technically, which is super important. If people only cared about writing code or getting the right code, they would just hire competitive programmers, or probably just replace us all with AI, the second AI could just generate the kind of code that most senior engineers could. By the way, we're not at that point at all yet, despite what the social media world is telling you. But we hire humans still, right? Companies are still hiring humans. In fact, they're hiring more people this year than they have in the last two years, by a significant amount. So what does that tell you? Hiring is actually trending up, despite what social media says, or the news of your mom or your dad. All you gotta do is look at the numbers. They're hiring a lot more people now than they were two years ago. So why is it so difficult to get a job still? The hard, cold truth is most people aren't that good. Here's the other kind of not so fun thing to tell people. You can't suck at programming and just expect to do these things and get hired, right? If you put yourself on camera, and you can't call an API, use use effect, use use state, and write out a basic React component, then you're not gonna get the job anyway. So you have to have a technical foundation, which is kind of implied at this point, because if you don't, you're just gonna set yourself up for failure. I have seen a lot of people, in fact, more people than not, that will get to an interview, do pretty well in the behavioral rounds, and then completely fail the technical portion of the interview. I've seen this happen way more times than you'd ever believe. And there's this myth out there that all these super senior developers and people that went to Apple or Meta or whatever are on the market, and now they're coming for your job at the local startup that no one's heard of in your hometown. That is completely false. That is not true. Who you're competing with, honestly, is people that are somewhere near mediocre or average, or maybe a little north or a little south of average. So you don't need to be some sort of genius to beat them in the interview. You just have to be the best person that showed up that day, and you just cannot suck at programming. And that's a much larger topic for another episode. You should probably go to Parsity if you're worried about your technical foundation. That's not something you can solve in a week or two before an interview. So now that we've covered some really typical styles of interviews that you're likely to encounter, the most important thing you should do when they invite you to the interview is just ask. Say, hey, what's this interview gonna be about? That is the most important thing you can do. So you can study for all these things, but it's of no difference if you go to the interview and it's something like, hey, by the way, now we're gonna actually do something in vanilla JavaScript, or actually, now we're gonna do something in a programming language you've never used before, because we wanna see how you use a programming language that you've never seen. Gotcha, right? So what you wanna do is just ask. It's amazing how many people don't just do this simple thing. They just say, oh, thanks for the interview, and they go in, and then they just get completely blindsided, or they just study LeetCode and assume it's gonna be whiteboard LeetCode stuff. No, you must ask. Ask really simply. Just say, I'm really excited to interview. Can I ask you what type of interview will this involve? Is this gonna be technical? If so, what should I be studying? That is not a weird question at all. It just helps you prepare. If you can, take time to prepare. You shouldn't need a long time, because if you're having to learn a bunch of material before you go into the interview, it's likely not a good sign. The interview should mostly be a brush-up on topics you're already familiar with. Unless you're going to somewhere like Google or one of the really big tech companies, then you should honestly take months to study, which they'll often give you. They will give you up to 90 days to get ready for an interview. That was my experience at least a few years ago. I don't know how that's changed, but you definitely need to give that full attention if you're going for the big tech companies. If you're going for the smaller companies, you really shouldn't need to. This should be mostly a refresher of skills you should already have, like JavaScript, React, Node Express, Next, TypeScript. Whatever your core set of skills are that they are interviewing for should likely be a reflection of those things. Now, behavioral interviews are their own beast, and I could have a whole show on that. In fact, we spend a lot of time with Parsity students getting ready for the behavioral interview. Behavioral interviews are a really big bucket, right? They can entail all sorts of things, like tell me about yourself. Tell me about a time you had a conflict with a coworker. What I would be doing, by the way, is going on Glassdoor or TeamBlind. These are two sites where you can find a lot of information about your interviews if you're lucky. Now, sometimes you can't find anything at all, but you know some questions are gonna come up. You know they are, like tell me about yourself. Please don't go off and tell them about the time when you were five and you wanted to learn how to program or how your life story led you here. They really just wanna know kinda hey, what led you here today? Why should I be hiring you? Why should I take you seriously? Here are some red flags for you to avoid. Don't call yourself junior. Avoid talking about any bootcamp stuff. These are things that people automatically will distrust, right? You wanna give them less reason to distrust you. You wanna give less surface area for bias. So maybe don't start off with, well, you know, last year I hate my job and I wanted to learn to code, so I did, I went to a coding bootcamp for a few months. I built some crud apps and now here I am trying to get my first job. That raises a lot of red flags and also makes you look like an outsider. You don't wanna be an outsider, right? You just wanna give them the minimum effective dose of information. You wanna tell them, yeah, the reason I'm here is because I love the company values and the vision. I know that my skills as a full-stack software developer could make me a real asset here. And not only that, but I have a background in whatever from my previous life or career or whatever I was doing that I think is gonna make me particularly skilled here in this role. I know this is a small company where you're looking for someone that can probably wear multiple hats and I believe I could be that person because not only do I have the technical skill, but I have the grit, I have the communication skills, and I have some leadership experience from previous roles that were outside of tech. That comes on very, very strong. That's a nice, strong way to come on. So write these things out. Don't leave it till you get there to freestyle it. You know they're gonna ask you why you're here. You know they're gonna ask you that time you had a conflict with a coworker. You know they're gonna ask you about the hardest technical problem you had or some technical challenge you had. Again, when these questions, try to come up with something interesting that's gonna make them see you in the light that you'd like them to. Talk about a technical problem that you've solved. You don't need to tell them it was a side project. You don't need to tell them it was a coursework or anything like that or some sort of material that you were using for your bootcamp or college, whatever. Just tell them the thing you did, right? If they ask more information, feel free to give it to them, but you don't need to tell them every single thing that will not help them make a decision. You're trying to help them make a decision about you. If you're there, it's because they want to hire you, so don't give them reasons not to hire you. That's my main takeaway for you because I see this happen way too often. People will get there, they'll diminish their skills, they'll say, I'm just really junior, but I'm really hungry for the first job, and what they're basically asking is, hey, take a chance on me. Nobody wants to take a chance on you, especially not in today's market. Interest rates are high, trust is low, managers are being asked to do more with less. They want to be pretty confident in who they hire. That doesn't mean the expectations are wildly different, by the way. No one's gonna have you come into a job and see that you're basically junior and expect you to be a senior. They should be interviewing you in a way where they know what your skills are and they understand how to level you. The word junior and the word senior at many places can mean a lot of the same things. Titles are fairly meaningless, so don't put a lot of stock into them. So now, you've made it past the recruiter, you've made it past the technical portion, you've made it past the behavioral exam, now finally you're into the offer stage. This is the most fun part, and also where people just quit. They get the offer, they say, we're really happy to give you an offer. They want to give you the offer. They give you the magical number, and you see it and you say, yes, I'll take it. Wrong answer, I did this for years without actually knowing there's a game being played. I had no clue that you're not supposed to just take the first number they give you. Some companies are very explicit and say, that's literally all we're gonna give you and there's no wiggle room at all. And then some companies will say, here's our offer. I'm really happy for you to join. Welcome to the team. Now it's up to you to do some small pushback. Say, I'm really excited and thank you so much for the offer. Do you mind if I have a few days to think this over? They're gonna say, of course. Take some time, talk to your family, think it over. Now you need to come back, do a little bit of research. If they're offering you at the very highest range and you're thinking, this is more money than I've ever seen in my entire life, which it likely is, you still need to ask for a little bit more. Here's why. No matter how much money you make, when you get into that role, almost certainly in a year or two, I guarantee you, if you're like most people, you're gonna be thinking, you know what would be cool? If I made a little bit more. If you're used to making 60,000 or 70,000 and a company offers you 90,000, but you know that software engineers in your area are making around 100 and 120K, like in the Bay Area, for example. That 90K may be more than you've ever made, but it's still not the market rate. If they're offering anything below market rate, it's in your best interest and their best interest to meet you at that market rate. The reason is, if you come in happy, you're not gonna be looking around envious of your peers in a year or two when you get those skills under your belt and you're thinking, damn, I'm getting paid less than the junior guys coming in. What the hell's that about? That happened to me and that was ultimately why I left the first company I was at. And that was actually a silver lining because then I doubled my salary at the next place. But if I had come in at a really high salary, one, I probably would have been freaking out and been stressed out. I also would have stayed at the company a lot longer because why would I have jumped ship if I was already getting a really high salary? That's just not how things work though. So what often happens is they have a range and I can tell you this from experience. You have a range that you can offer people. They say, here's the most you could offer this person. Here's like the minimum and here's what we recommend you offer them. And so you'll get on the phone with that person and you'll give them the recommended offer that somebody in HR told you to tell them. And they'll say, cool. And sometimes people say, I'll take it. And then me, would be like, damn, I wish they hadn't done that, right? I wish they had negotiated a little bit. The negotiation didn't need to be super duper well thought out or like some sort of fancy presentation or require a lot of research. All they literally needed to say would be, hey, I'm really happy with this offer, but I'd like to come in more around this range. Now, if they said, hey, I wanna come in 50% higher than what we were offering, well, that's not gonna work, right? If we're offering 100K and they're like, I want 200K, you're like, well, maybe the offer is taken back now because that shows like a serious lack of credibility on your part. It's like, wait, did you know the salary before you came? Are you just like messing with us? Then it's like, eh, maybe we made a mistake. The offer is taken back. Now, I have heard of horror stories of people making reasonable requests and then getting the offer taken back. This is super rare, by the way, in my experience. Also, it's a very, very bad sign for that company. If you simply ask and they say, no, you shouldn't even open your mouth, offer gone. Terrible, terrible, terrible sign. Big red flag and probably a really good thing that you avoided this company. Majority of companies, the other 99% are gonna say, hey, you know what? We can't actually give you that. Or they're gonna say, you know what? We're unable to, and that's okay because the negotiation is not over. You don't need to just negotiate your salary. I've negotiated things like the amount of days that I would come into the office. I said, hey, I have young kids. I have a really long commute. Is there any way that I could come into the office three days a week instead of five? This was back pre-pandemic when in San Francisco, it was still the norm to work five days in an office in many places. And I successfully negotiated coming in three days of the week and also having my core hours go from 10 to four rather than like nine to five. I said, I'll still continue doing my work. I'll just do some of it on the train and some of it at home, but I can't get to the office before 10 on certain days and I need to leave right at four on certain days because I have young children. I was able to successfully negotiate that without getting all the money that I originally wanted or see if they have something called a sign-on bonus. This is very common as well. Sign-on bonuses can be between 10 and 20K. They're a one-time payout. You get taxed about 50% on these, so you're not really gonna take all that amount home, but it's just a good practice for you to show you that yes, there's more money on the table than you thought there was. If you don't do this, you're shooting yourself in the foot and you're giving away money. Please don't make this mistake that I did. You really need to do that. And I have tons of stories of people I've done this with. Most of them were successful. In fact, one guy a few years ago, he went from like 80K to I think almost like 113K, which was shocking. I'll be honest. I was like, damn, that's a lot of extra money. That's $43,000 more. One time I negotiated my salary from 120 to 150, a 30K jump just by asking at the next company. I successfully negotiated a 10K increase with a 10K sign-on bonus, and at the last company, I also negotiated to the very top of the range simply by asking. Now, is it always that easy? Of course not. I've had companies say, no, that's actually the highest that we can go, and you say, okay, then it's up to you to make a decision. But if you don't ask, you shall not receive, right? So please do it. Anyway, I hope this was super helpful for you, and if you took nothing away from this whole thing, write tests for your stupid take-home exams and negotiate, negotiate, negotiate. Hope that's helpful. Hope you have a wonderful July 4th, and I'll see you around. By the way, if you have questions you'd like me to answer on the show, please use the link in the show notes, and I'll shout you out on the show if I pick one of your questions. Thanks a lot. See you around. That'll do it for today's episode of the Develop Yourself Podcast. If you're serious about switching careers and becoming a software developer and building complex software and wanna work directly with me and my team, go to parsity.io. And if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.