.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
#261 - I Used to Suck at Coding Interviews. Then I Started Doing These 4 Things
Five years ago, during an interview for a senior dev role, I had a panic attack. It was one of my worst interview experiences. It also taught me a lot about what I was doing wrong.
In this episode, I'll break down the process that took me from under-paid developer to passing interviews and 4x'ing my salary.
Here's your worksheet to help you create a solid story for an interview: worksheet
If you know you suck at interviews - I'll be working with a few people to help them crush their next interview and increase their salaries.
Apply here: Fill out application 👈
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. So five years ago, during an interview for a senior level developer role, I had a literal panic attack. I mean, straight up, my heart was like pounding. I thought I was gonna have a heart attack. I do actually have a existing heart condition, so this made me freak out even more. I'm like am I really gonna pass out? During the phone call, I couldn't get my words out. I actually had to ask the interviewer if we could restart the call and I'm thinking at this point okay, I'm toast.
Speaker 1:By the way, I'm a senior software developer with around 12 years of experience. I've worked at half a dozen companies over the last few years, including some startups, but now I own a program called Parsity where I mentor other developers. So this was even more embarrassing in that I've taught people how to get interviews, how to pass interviews. I've helped people double their salaries. I've helped people get to their first interview and crush it. And here I am completely bombing and failing the easiest part of the interview, the softball call with the CEO. I had a little too much coffee, I was embarrassed, shaky and I'm like I blew it. Plot twist I actually got the job, but this was one of many interview disasters that I've had over the years and it showed me just how broken my approach was. Now here's the thing I was already pretty decent at writing code. At this point I wasn't struggling to actually do the job, I was struggling to get the job, and I feel like that's the problem that a lot of software developers encounter, and I know it's not fair and you think the interviews are biased and you have to study LeetCode and all this junk. I wanna walk you through a process that I use personally. That's helped me to stay employable over the years, to land job offers and to really just have a lot more confidence as a software developer.
Speaker 1:If you're expecting some leet code style advice or how to get into really big tech companies, this is not. It Newsflash is that most of us will not be working for these massive companies. We'll be working for companies that no one's really ever heard of, or ones that at least don't use whiteboard interviews or these leet code style interviews where you're judged on your knowledge of algorithms and data structures, although I do think that's important. I also know that interviewing is a game, and to be prepared for this game I do think that's important. I also know that interviewing is a game. And to be prepared for this game you can't just study that kind of stuff and expect to be handed a massive salary.
Speaker 1:Right, but knowing how to code and being good at your job but not being able to pass interviews is a really frustrating place to be. In one interview at the beginning of my career, a guy actually asked me about JavaScript object referential equality and I fumbled so hard because I honestly just didn't know anything about this. You can say, oh, you're a terrible developer. And yes, I wasn't the best, right, I was mostly self-taught. I went to a coding boot camp that was specifically for front end. I ended up doing full stack in my first job, not learning a lot beyond how to just make things work. I didn't really go any deeper, so I didn't really have a lot of knowledge that people would expect me to have at this point. So, during this call, as I'm fumbling and trying to explain why an object might actually equal an object in JavaScript and if you think that's the case, just go look up object referential equality. And then this interviewer, nice person, that he was ended up explaining to me over the call, like I was a student, why this was not a thing, and he was kind and patient but basically taught me. And at this point I'm like okay, the interview's over.
Speaker 1:Another time I was doing the initial phone screen for Facebook and the person asked me a question that involved recursion. And there's no way, right, I was bumbling and fumbling so badly. I just said just cut the interview short. I said you know what, respectfully, I'm going to ask that we end this interview because I'm wasting your time and my time and I apologize for not being more prepared. And the guy was nice, he's like are you sure? Like we could try to work through it together, and I'm like, nah, man, I think I'm just going to bail out of here, right.
Speaker 1:And so I left these interviews thinking I'm not cut out for this, maybe I'm just not supposed to be in this profession. But here's the thing about me I'm a stubborn SOB and I'm obsessed a little bit. I have a history of addiction that I've talked about on other shows that I won't get into right now, but I have a little bit of a history with addiction and I'm obsessed with patterns. So I started breaking down the process and rebuilding it from the ground up, and here's what changed everything for me. Number one I built a library of personal stories. I'm not going to start off with the tech stuff. That's actually fairly obvious. There's a million sites you can go onto nowadays and learn how to traverse a tree or do binary search. That's not that hard, honestly.
Speaker 1:What's harder is during these interviews after the hundred I've done over the last 11 years or so as an engineering manager and as a software engineer, I've noticed that most interviews tend to have the same four to five or whatever behavioral questions, just reworded in some way. Tell me about a time you solved a technical problem that was difficult? Tell me about a time you had a conflict. What's a project you're proud of? When did you fail? There's some variation of these questions in almost every interview and the problem is I was freestyling these ones and I wasn't putting together stories which gave me a lot of credibility or made me seem like a really good fit.
Speaker 1:So I started looking at all the stories throughout my experience and cataloging them, and then I would map those stories to the questions that I thought I'd receive. I also did a lot of research on the companies beforehand. I realized it's a high stakes game when you're going into an interview, so you might as well be as prepared as possible. So I put these stories into a Google doc, I grouped them by theme and then I knew the stories down so when I got to the interview I could look at my stories. If it was a virtual interview, if it was in person at least I'd written them down and now I have like some muscle memory and I can kind of pull these stories out of my hat. They talked about what I did, what I learned and what they revealed about me.
Speaker 1:The stories had a purpose. When I talked about me scaffolding the front-end system design for a large company, this is a story that would speak to my leadership. When I spoke about the time that I got a project back on track that was going to be three months over the delivery date, that's a story about leadership and how I manage teams and not really a technical story. When I talked about me bringing down the latency on an API by like 75% by optimizing a certain query, that speaks to some of my backend skills and my investigation and debugging skills. So I had these stories that were very, very particular to the types of interviews that I knew I was gonna get and the types of personalities. If I'm speaking to a hiring manager or somebody that's not super technical, maybe I wanna go with more of a leadership management story. If I'm speaking to somebody that's highly technical, maybe I wanna go with the story of decreasing the latency on that API and how it saved a lot of money and our customers were happier afterwards, and how I debugged it and investigated it. So knowing my audience was really crucial too. So I had this little grab bag of stories like right there, I could tell you them and then I could use these in the interview to make myself seem more impressive.
Speaker 1:Then at one point I became an engineering manager, really kind of by mistake. I got kind of forced into being an engineering manager and here I was conducting interviews now and as I'm doing the interviews, I'm realizing I'm asking these same questions. But what am I really asking here? What am I trying to get at? Basically it's, can I imagine this person working here? Do I feel comfortable putting my stamp of approval on this person? Because they're going to be a reflection of me.
Speaker 1:Once I understood this, I thought how many other managers are essentially doing the same thing? It's not purely objective. It's like thinking how much can I see this person fitting on the team? How much can I see them contributing technically? Do I see them having a long period here where they can actually contribute and do well on the team? Or does this feel like a risk? And then I thought, okay, cool. Well, if I'm basically trying to mitigate risk and see if I can envision this person working here, I need to have stories that really sell myself. So what good is passing the coding round of an interview if you bomb the behavioral sections?
Speaker 1:I don't know why more interview prep doesn't speak about this. It's like if we just wanted people that could traverse binary trees or think of the most optimized route for finding a node in a graph or something like that, then we would just hire competitive programmers. But we don't right. So why don't more people talk about this aspect of the interview? I think it's because it's a lot messier. I also honestly think that a lot of the interview advice comes from people that don't really have long work histories, so they don't really understand what it's like to interview a lot. I've actually interviewed a ton and I've practiced a ton and I realized that these questions actually make up the majority of your interviews, maybe not at Facebook or Google or Netflix, but at other companies. They're going to want to know a lot more than whether you can just code, because, honestly, that's kind of a given, and I also have an exercise document that's in the show notes here that's going to help you organize your technical story for the next time you get an interview and get inevitably asked that question what's the most technically complex project you've worked on and what was your role? You need to have a good answer for that and the document I have is going to help you craft an answer around that Next step.
Speaker 1:Step number two is I got clear on my technical gaps. I didn't try to become a master of everything. I focused on the concepts that were always tripping me up, especially with JavaScript. It was closures, prototypal inheritance, recursion, coding, challenges, like you know, finding the min and max in an array or something like that Really silly, trivial stuff. That honestly seems pretty simple now because I have years of practice doing it, but at the time it was really really difficult. So the way I did this is I built small projects using vanilla JavaScript.
Speaker 1:Why vanilla JavaScript over React? Because if you're hiring a software developer, especially at larger companies or really any company, it was more common, I think, especially back in the past, to judge somebody or interview them based on their command of a certain programming language rather than a framework. Now that's kind of flipped. Honestly, I rarely see interviews that are about JavaScript, but you really wanna be good at the programming language that you write on a daily basis. So I did a bunch of exercises using vanilla JavaScript and then I made videos where I'd explain these concepts out loud. I wrote code until I didn't need to look things up anymore.
Speaker 1:Eventually, I put all of this into this GitHub repo that I've shared with other developers that I mentor and it really kind of beats them right. Some of my mentees have seen this and like whoa, this is actually really difficult. I'm a senior developer, I'm a mid-level developer. I went to a bootcamp and this is going over what I assume was basic JavaScript and I can't really figure this out right. And that's exactly the kind of epiphany that I wanna have, because those are the things that I learned when I was doing this. Like hey, let's build a snake game using vanilla, javascript and HTML and CSS. How do you think through that? How do you do that? And how do you do that when somebody's watching you? Putting yourself on video putting myself on video was actually one of the best tricks, the best hacks that I found to mimic the pressure that I'd feel in an interview. Then I could go back and watch it and I'd cringe a little bit and be like jeez, I'm an idiot. Over time it got a lot better, which leads me to step number three.
Speaker 1:I had to train myself to be calm. This was really really difficult for me. I have a history of having panic attacks. I'm a bit high energy, pretty nervous person. I have an actual heart problem, so it's not all in my head. I know that I have to be able to be calm in order to do a good job, but I also know that that's just not naturally who I am. I get freaked out really easily.
Speaker 1:So I thought about this. I'm like huh, what's the most scary thing I could imagine? Skydiving and I thought there's some people that jump out of a plane every single day. They do skydiving every single day. Then I thought back to my past life, where I did a lot of illegal stuff in the streets and I thought the first time that I made a large sale on the streets or something like that, it was scary. I thought, oh my God, am I gonna get caught? The police gonna be right behind me. You do that a hundred times. You stop tripping on that one bit, just like a skydiving instructor might jump out of a plane a hundred times At some point. It's just a boring day to them, like, oh great, another day at the office I got to go jump out of a plane for the thousandth time with some dude or some woman that wants to celebrate their anniversary, whatever. What a day, right. So you have to make what is unique become really mundane.
Speaker 1:And I took the same approach to interviews. I used a service called Pramp. I am not sponsored by them in any way, even though I really think I should be honestly at this point. Pramp, if you're listening, reach out. Pramp is an interview site where you can interview with strangers and basically mimic the process of being judged by a stranger while doing a coding question. I bombed the interviews there. I embarrassed myself, but I got used to it. I did a lot of interviews on Pramp. I did one per week. After a while they just kind of felt like routine right. Per week After a while they just kind of felt like routine right. I'm like, okay, now it's just kind of boring and that's exactly what I wanted it to be. So what were the results of doing all this stuff Speaking into a camera, getting a list of stories compiled, practicing interviews, reading books like System Design 1 and 2, just going through the rigor of actually learning the stuff, applying it and mimicking how it would feel to do an interview I went from a salary of 60k when I first started writing code to around 300k most recently.
Speaker 1:I've gone down since then again, but I've dramatically increased my salary over the years. Obviously, the salary bumps were great for my financial life but, more importantly than that, I'm a lot less worried about if I can find another role. Learning to interview, whether you like it or not, is the single highest leverage skill you can have as a software developer. I don't think this is fair. I do think it's reality. I'm not here to debate, you know, whether that's fair or whether you're a better developer than me or anything like that. Maybe you are, maybe you're not. That's really none of my concern at all. My concern is knowing how to interview well, and I think it's a skill that I'd like to see more people get, because I see how dramatically it changed my life. And when I say my life, I don't mean like, oh, now I grew hair and my kids are happier. It just means I have one less thing to worry about. Honestly, and if it takes you a couple hours a week over the span of two months to do that, why not invest in that kind of skill?
Speaker 1:I invested tens of thousands of dollars doing this through other programs like Interview, kickstart, through buying things like Algo, expert System, design 1 and 2. I went to another coding bootcamp like seven years ago where I learned also how to interview. I've spent a lot of money over the years learning this stuff, but, honestly, and when I put all those hard skills that I learned into this process that I just shared with you, that's when I saw the most dramatic increases and actually saw this come to life right. So that's when I saw okay, it's not just about the technical piece, it's about having all these other stories ready and really selling myself in an interview, and there's all sorts of other stuff that I won't get into today about like negotiation or doing research on the company beforehand or things you can do to really just improve your chances, or places where you can look for interview questions that have already been asked, like going on Glassdoor or Team Blind or just asking. There's a lot of things you can do to just increase your chances of getting a yes in an interview. You don't need to be the best candidate, you just need to be the best person that shows up on that particular day. You need to be the best locally available option.
Speaker 1:And, lastly, I haven't done this program for a long time because I'm really busy running Parsity, which is a program for career changes, and obviously we have a interview aspect to that program, which is really important. Like, we've had people come in that have never gotten an interview. They went to a bootcamp. Now they're finally getting interviews, which is really cool to see. I've always been a bit obsessed with the interviews and right now I'm going to open up like five spots max. I have a few people already that have reached out to do this.
Speaker 1:I haven't done this for a few years now, but I see that this is actually a really great program and if you want to work with me over eight sessions where we're going to get you in the best interview shape you could possibly be into. Whether you're doing a take-home exam, in-person coding rounds, behavioral interview, we're going to make sure that you are going to have the best possible chance. This is for people that are already, you know, got a little bit of experience. Maybe you already graduated a coding boot camp at the very minimum. But if you're learning to code, this is absolutely not for you, so don't do that. And if you want something that involves fang prep, like prepping for Netflix or Google or Meta, just go to NeatCode or interviewio, algoexpert, interview, kickstart. Those are great programs. This is not what I offer at all.
Speaker 1:I've been working with developers for years doing this. I stopped doing it to run Parsity, but I've helped a ton of developers increase their salaries by like 10 to like 30K just by learning some fairly simple techniques and just up leveling on some skills that they had been neglecting. So if you're in the us and you would like to take me up on that, you can fill out a short form. I'll give you a call, see if we're a good fit. We'll go from there. I'm only going to do this with like five people at a time max, and I might not do it for a long time again.
Speaker 1:I do this when I feel like doing it. I actually really enjoy this kind of stuff. I think it's fun. I also see how big of a huge unlock it could be. Maybe I'll make it into a whole thing at Parsity, I don't know, but I think it's a really great skill to learn. I see how much it can change your life. Anyway, let's make interviews boring for you again, and whether or not you decide to take me up on that offer because most Check out the thing in the show notes that's going to help you craft a good story and just take some of what I've said. Go on Pramp, start practicing, learn the things that you know you should be learning and you're going to get better guaranteed. Anyway, I always hope that's helpful. 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.
