.png)
Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#253 - The Real-World Step-by-Step Guide to Tech Interviews (Not for Google or Meta)
Interviewing is arguably the highest paying skill you can have as a developer.
I don't think this is fair but it is reality.
I've taken part in well over 100 interviews both as an interviewee and interviewer. I've worked with dozens of developers to ace their interviews and increase their salaries by tens of thousands of dollars.
This is not for developers looking to get into Big Tech. This episode is for the 99%.
We're going to cover the 4 most common stages of the tech interview from recruiter filtering to technical interview to "tell me about yourself" and finally the offer stage.
Here's the unit testing course I mentioned in the episode that you seriously need to check out if you don't know how to write a test: https://github.com/CodeCoachJS/js_pro_unit_testing
Shameless Plugs
🧑💻 Join Parsity - For career changers who want to pivot into software.
✉️ Got a question you want answered on the pod? Drop it here
Zubin's LinkedIn (ex-lawyer, former Googler, Brian-look-a-like)
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 boot camp, 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. 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.
Speaker 1: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 want to just let them slip away like sand out of your hand, right? You want to try to nail them as best as you can. So I'm going to 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 going to get an extra $10,000, $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, like you know, 60, 80,000, like 100,000, or go from like 50,000 to 120,000.
Speaker 1: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 want to 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 you could get a six-figure salary. So anyway, without further ado, I wanna make it and I wanna give a short disclaimer.
Speaker 1: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.
Speaker 1: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.
Speaker 1:There are a few stages of the interview. Now. The first step in your interview process is going to be something completely non-technical. It's going to be you talking to a recruiter. This is the filtration process, where they're going to 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.
Speaker 1: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.
Speaker 1: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, you know they're immediately thinking no way. They don't know what that means and so they're like I don't want to 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. All right, 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 going to 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.
Speaker 1:Technically. Maybe I said that in a weird way. I want to make it very clear Do not lie right technically. Maybe I said that in a weird way. I want to 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? 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 ten, 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 want to make sure we're using the same scale. You can kind of turn it on them and make it a bit of a joke.
Speaker 1: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.
Speaker 1: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. You know basic market range for my area and you know 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 well, you take 80,000. Oh well, damn great Cause 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, 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.
Speaker 1:So the next step after this is almost certainly gonna be the technical interview where they're going to invite you on site 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 want to 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.
Speaker 1: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 going to give you for free. It shows you some basic front-end testing stuff that's going to 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 going to take more than three months and you're serious about making a transition into a career in software and you want to work with people that have done it before and are currently working in senior plus levels, join me and Zubin at parsityio slash inner dash 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 parsityio slash inner dash circle.
Speaker 1: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 backend component, test part of that backend 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 on site. So, yeah, write some tests, make sure they don't suck and don't, for the love of God, just use ChatGPT or Cursor.
Speaker 1: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?
Speaker 1:I guess when you're doing a bunch of take-homes like that, you know, maybe it's a way to just do a bunch of them at scale, I guess but yeah, it's not going to get you anywhere, but having a really good unit test, having a read me 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 you know 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 want to 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.
Speaker 1: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 going to 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.
Speaker 1: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 going to come across. It's going to be some version of build me something with React.
Speaker 1: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.
Speaker 1:The reason why is because what's behind doing this kind of technical challenge is not just seeing 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, the problem. Think of it like this here's the framework I use.
Speaker 1: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.
Speaker 1: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 Prampcom. Prampcom 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 going to do this either.
Speaker 1: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.
Speaker 1:If people only cared about, like, 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, 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.
Speaker 1: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 going to 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 going to 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. 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.
Speaker 1: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 going to actually do something in vanilla, javascript or actually, now we're going to do something in a programming language you've never used before, because we want to see how you use a programming language that you've never seen Gotcha, right. So what you want to do is just ask.
Speaker 1: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 going to 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 going to 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.
Speaker 1: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.
Speaker 1: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 right? They can entail all sorts of things like tell me about yourself, tell me about a time you had a conflict with a co worker. What I would be doing, by the way, is going on Glassdoor or team blind. 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 going to come up.
Speaker 1: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 you know how your life story led you here. They really just want to know, kind of hey, what led you here today? Why should I be hiring you? Why should I take you seriously?
Speaker 1: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. You wanna give them less reason to distrust you. You wanna give less surface area for bias.
Speaker 1: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 want to be an outsider, right? You just want to give them the minimum effective dose of information you want to 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 going to 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.
Speaker 1:So write these things out. Don't leave it till you get there to freestyle it. You know they're going to ask you why you're here. You know they're going to ask you that time you had a conflict with a coworker. You know they're going to 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 going to 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 boot camp or college or 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.
Speaker 1: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 you know, 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 going to 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.
Speaker 1: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 going to 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.
Speaker 1: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.
Speaker 1:Here's why, no matter how much money you make when, 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 going to 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,000, $120,000, 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 going to 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 is that about? That happened to me and that was ultimately why I left the first company I was at. Now 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.
Speaker 1: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 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, I would like 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.
Speaker 1: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 in? 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 companies, the other 99% are going to say, hey, you know what we can't actually give you that. Or they're going to 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.
Speaker 1: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, 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.
Speaker 1: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 going to 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.
Speaker 1: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?
Speaker 1: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 want to work directly with me and my team, go to parsityio, and if you want more information, feel free to schedule a chat by just clicking the link in the.
