Develop Yourself

#284 - The Junior Developer Interview Guide (From Recruiter Screen to React)

• Brian Jenney

Share episode

Let's be honest - interviews suck.

But you can't suck at them.

In this episode I break down what your next interview as a junior developer will LIKELY include.

Your mileage will vary.

Grab the interview guide below which includes a playback of a live event that Parsity recently hosted and a ton of resources: 

https://brianjenney.substack.com/p/the-junior-dev-interview-guide

Send us a text

Shameless Plugs

👉 Build Your First Website in 30 minutes 👈

✉️ Got a question you want answered on the pod? Drop it here

🧑‍💻 Apply for 1 of 12 spots at Parsity - Become a full stack AI developer in 6-9 months.

SPEAKER_01:

Welcome to the Develop Yourself Podcast featuring my dad, the best coder ever. The problem with 99% of the advice you read about interviews online and especially on LinkedIn is that they only apply to the top 1% of all companies out there. So when you read about how to pass an interview, it almost always includes whiteboard data structures and algorithms and how to get into Google or Netflix or some massive company, which 99.9% of developers do not work for. So what I want to go over today with you, because I like you so much, is your junior developer interview guide. You could easily also call this the mid-level developer interview guide or potentially even the senior developer interview guide. You can really maybe call this the interview guide for the 99%. And I want to go over some things with you, just hard-hitting practical stuff you can do based on my experience doing tons of interviews, both as an engineering manager, as a software engineer, and working with hundreds of people over the last 11 years to land roles in tech. So, what are we going to learn? The screening call, the behavioral interview, the react question you're going to get, how to prepare for JavaScript trivia, take-home exam tips and tricks, how to manage your anxiety if you're a neurotic AF like me, what you should absolutely not do. And yeah, we are going to go over a little bit of DSA basics and just some resources that you can use. But first, why even trust me? Who am I to tell you anything about how to pass interviews? What do I know? Here's the thing my experience is by nature limited. I am one human being. But over the years, I've talked with around 800 developers through 15-minute phone calls. Don't ask me why I did this or how I found the time, but I did, and I can prove it to you if you really want to see. You can also schedule a call with me in the show notes because I'm crazy like that. That I like to talk to people and genuinely hear what they're going through. These are 15-minute calls. 99.9% of them have been pretty cool, to be honest with you. I haven't met too many weirdos out there. But that being said, I've learned a lot about what people are going through when it comes to tech interviews and a lot of the nonsense that you hear online. A lot of people do get whiteboard stuff, depending on your part of the world. I've talked to people all the way from Nigeria to Italy, mostly in the US, and I've heard all the stories you can imagine. In addition, I've sucked at interviews. I sucked at them so badly. And then I finally spent a lot of money and time getting better at them. I got to the on-sites at Google, at Meta, Amazon. I landed plenty of roles, got a lot of offers over the years. I've had around seven positions. I've had around a hundred interviews. I've also helped shape the interview process at two of the companies where I've worked, one very recently, and I've helped over a hundred developers to land their next role and pass their interviews and get more money. So I think I have a pretty decent idea. And I'm not saying this to brag because honestly, my experience, even with this many people, is very, very limited. But I feel like I have a pretty good idea and I want to share this stuff with you because I want to see you pass your interview. I just want to see you get out there and stop leaving all this nonsense you hear online and maybe get some more money in your pocket. And at the very least, feel a lot more confident when you finally do get an interview. So, first off, before you even get to the part where you mess up their whiteboard or you're writing some code on a piece of paper for some weirdo to see in an interview, you're gonna have to go through a screening call. That screening call is usually a call with somebody who's a recruiter who's not very technical at all. And it'll start off with something like, So, you know, what led you here today? And the worst thing you can say is, uh, remind me what this role is for. If you're a senior, you can kind of get away with this. If you're a junior or on your first job, trying to get your first job, you got to do some homework on this company. Quite simply, go to the landing page, go to their LinkedIn page, go to their about section and look up their company values and try to just parrot back some of these company values as you're talking. Don't be super obvious about it, obviously, but you know, just do some due diligence and make sure you understand what the role is and who you're talking to. Now, inevitably, they're gonna ask you this question when you're on the call. They're gonna ask you, so what's your salary range? And you are gonna wanna say a number that's not too big and you're gonna want to say a number that's not too small. What you should do though is not say any number at all. And here's the thing: if you say a number, you've kind of locked yourself in to a range and you don't know their range. What you should do is turn the question back on them and say, Oh, well, what's your range? And they say something. And you say, Okay, well, that's well within the range that I'm looking for. So once we get to the stage of offers, I'm happy to speak about that more. No, no, we really, really need you to give us a number. Give them a number. I'm one of those people, I don't think about it so much. I've given people a number and then I've gotten an offer and I've come back and said, you know what, that number I said, it was too low. I've messed up. And now I'm gonna tell you a higher number. This is not gonna X you out of the role or disqualify you if the number's not too high or too insane, but don't overthink this. Do your best not to give a number. Here's one of the most difficult pieces of advice I've had to give to people don't be weird, right? The way you can avoid being quote unquote weird, which I know a lot of us are as software developers, and perhaps I am myself, I don't know. But I like to do this. I like to give less information than needed. I like to give just enough information for the person to make a decision and move on to the next stage or round of what we're going to do. The worst thing I think people do during a call or during an on-site or during that part where they're actually in the real interview is just ramble on for too long. This can either expose too much information about you that you didn't want to expose, also, it can eat into valuable time that you should be using to crack hard problems, and it can expose your weirdness a little bit. If you are weird and you don't know, well then hey, you don't know. And to be completely honest, some people are gonna like you and some people aren't. Now, here's one of the questions I hate the most in these screening calls, and I see junior developers especially get this question, Ron, they'll say, Hey, rate yourself on a scale of one to 10 in JavaScript. And you, knowing that you're not a 10, also knowing that five would be too low, say something like seven. The recruiter, who may not be technical at all, hears this number and says, What the hell? Seven? That's like a C, right? That's like a C minus. I was hoping you'd say eight or nine, maybe even ten. What the hell? You tell me you don't know how to write the one language we want you to be able to write? Well, get the hell out of here, Bucko. And so you're saying something that makes it sound safe. I like to turn this back around on them if possible. It can also be kind of funny and break the ice a little bit and say, Well, what would you consider a 10? And they might say, Well, I'm not actually that familiar with JavaScript. So this is just a question I have to ask for this kind of role, and say, okay, well, that's fair. Well, listen, I'm very confident in my JavaScript skills, but if I think of 10 as being like Shakespeare and one as being a newborn baby, I probably put myself somewhere in the you know eight range or so like that. But I'm very proficient. So however your scale needs to reflect my belief in that, let's just say that number. And they'll maybe chuckle or something like that. Or if they don't, then you know, screw them, you should probably look somewhere else because they have no sense of humor and don't understand comedic gold when it's being delivered over the phone. So now you've got past the screening call. And I should mention that they're likely going to ask you your tech stack on the screening call. Sometimes they haven't done their homework and you will just be disqualified based on your tech stack alone. They might hear it and say, oh, actually, that's not what we're looking for. So sad, too bad. Don't extrapolate too much from any of these stages that we're going to go over. That is one of the worst mistakes I see people do, including myself. We extrapolate, we take one experience and we make up stories around this one experience, and that's why we didn't get hired. This is just one experience of many that you will have. So, next up, the behavioral interview. This is typically going to happen before your technical interview. A lot of people will get a technical interview before the behavioral interview, but very commonly you'll get some sort of behavioral interview. And what they're really trying to do in here is one, see how well you would quote unquote be a culture fit, like how well will you fit in? Are you basically kind of weird? Tell me about something technical you've accomplished. They're trying to understand like what level are you, and how well can you communicate and speak to us about something technical? So, because most of your interviews are going to be on screen, right? You're going to be using Zoom or Google Meet or whatever like that. So use this to your advantage. You need to have a catalog of stories ready. I literally have a Google Doc full of stories ready, and I'll have all the resources in the show notes for you to just grab. It's all yours. It's in an article I wrote full of links, nothing to sell you. Just use the links and hopefully you'll get better and have good luck on your interviews. That's it. That's the whole deal. I'm not selling you nothing at all at this time. Anyway, have a catalog of stories ready. The more senior you are, the more stories you're going to want to have involving leadership. But if you're listening to this, I'm making an assumption that you're probably a little earlier in your career. So this catalog of stories can simply be things like times you had a conflict with somebody, something technically challenging that you did. This technically challenging thing can be a thing you did at a boot camp. It can be a thing you did in college, it can be a project you did on your own. And you just need to frame it in the right way. I might not just offer too much information like, oh, well, at this boot camp I took that nobody's ever heard of, I built a movie finder. That's not an interesting story. What is an interesting story is anything where you can use this framework, PAS, problem, agitate, solve. I'm sure you've heard of the star framework. And if you haven't, that's well documented and you can find all sorts of information on how to craft a star story. I think this actually is easier to remember. There's less letters, it's three letters instead of five, right? So problem, agitate, solve. This is often used in sales calls. So the problem was that I was at a company or I was working on this project and we had a bunch of different components using different libraries, and we couldn't figure out how to make them all be aligned and use the style we really wanted. What was even more difficult was the more we added on and the more pages, the more work we had to do as software engineers to make sure that all these different components, like the button on this page, exactly matched the button on this page, and somebody used a different style and somebody used this, so it didn't look like it was really aligned and didn't give us a very polished feel. So now I've laid out a problem, I've agitated the problem saying it only got worse, things are getting really bad, these buttons out of control. And finally, I'm going to solve it. And when I frame the solution, I want to frame it in a way that shows my contribution, not necessarily the whole team's contribution because they're hiring you and not the team. So the solution was I had to make a component library and then I had to publish it to NPM so we could distribute it across the team members and then also share it via open source. And this way we were able to solve the problem and it actually cut down our development time by around 10 to 20% based on the number of commits that we were tracking through GitHub at the time. So you may need to do some homework on this, or you need to chase the kind of experiences that lend themselves to stories. This is the cool thing about software. You don't need to wait for somebody to give your permission to do something. You don't need to wait till you're on a team. You can build out solutions to problems that you want to encounter. If you want to see how to scale a microservice, or you want to see how to use a message queue in AWS, or you want to see what it's like to transfer an app from Next.js on for sale to AWS or GCP, just do that. And if all those acronyms I just said make no sense to you, then check out Parsity.io because you really need to learn this stuff. Anyway, the next really loaded question they're going to ask you is going to be tell me about yourself. And you're going to want to think, oh, well, as a little boy in Oakland, California, my father left me and my mother was hungry. And then I knew one day I'd be a software developer making the next microchip that would power cars and make me a multi-billionaire so I could spit on the masses of people. And that's what led me here today. Now, that's a cool story and all, right? But what they're really asking you about is why are you here today in this room or on this Zoom call and why this company? This is another time for you to talk about the company values and say, well, you know, I've always valued X, Y, and Z about this company. If you really have a genuine interest in the company, even better. If you don't, find a reason why you're there that day. Not just I need a job or oh, the text act looked interesting, whatever. Find something a little deeper and then give them some like validation or some qualifying experiences, like, well, I'm a software developer with this many years of experience, or I recently graduated from this program and I've built a few pieces of software. And then I learned about your company, which does X, Y, and Z, which led me here today. And I'm really excited to learn more about this role and opportunity and interview with you. And I like to keep this fairly short because the problem with this question, and I've seen this happen in interviews that I've conducted, is that somebody literally will tell you from their childhood up through like right now, today. And here's the thing in most interviews, especially outside of big tech, it's not like there's some super standardized format or anything. It's just some dude or some woman who just decided what they were going to ask you today. They may not interrupt you. They know they have to get through the interview, but they're also nervous and don't want to interrupt you either. So if you take up all that time, they may not have time to get to the actual meat of the questions they want to ask you. And then at that point, they may just score you lower and there's no way you could pass, even if you are otherwise a really good candidate. Is this fair? Absolutely not. This leads me to another really interesting point that I think a lot of people just don't think about. There's no formal training at most companies, especially not large ones, for doing tech interviews. I've seen people ask questions that they themselves couldn't answer. I've unfortunately asked questions that I had no business asking in the past, and I'm a little embarrassed to say that. And I've certainly been nervous when interviewing people and forgotten to ask certain things or let them ramble on too long rather than trying to keep them on track to finish. So let's get to the technical portion of your interview, which I know everybody is the most interested in, even though honestly it can be less important than you really think. But there's one question or one type of question or format that I've seen over and over and over. And even a person at Parsity got this recently. She was asked this question or given this challenge. Given a React component, I'm going to give you an API. That API is going to be some third-party API, maybe at a Pokemon or a to-do list or a shopping cart or something like that. What you're going to do is fetch the data from that API. You're going to display that data on the screen and you're going to manipulate that data in some way. I have a project, a small challenge you can check out in the show notes that is going to walk you through that challenge and offer you a solution that I would use. But here's the thing: you're not going to be able to always prepare for every single question out there. So the thing you really should be doing, besides studying for this question, because it is the most likely one you're going to get, is to go on Glassdoor and team blind and figure out what kind of questions this company has asked in the past. And before you even do that, you should just be asking the recruiter, hey, what is the nature of this interview? What kind of questions should I be prepared to answer? And doing a little bit of research ahead of time can really narrow down all the things that you should be studying or that you could be studying. Now, recently I've done some interviews and I've both given them and taken part in some interviews that included AI, meaning they allowed you to use AI during the interview. This was very, very interesting and different. Now, using AI in interviews is much more likely to happen in smaller tech or companies that are on the coast, startups, fast-paced types of places that really value speed, maybe over anything else. But this is going to become a lot more common going forward. And I believe even Meta is now allowing these in interviews. So if you're using AI tools, use them the same way you normally would. But the most important thing is to talk through your thought process here. No one really cares that you just got the answer. That in fact, sometimes it doesn't matter if you got to the right answer. I've often not finished a solution, but was still invited to the next round or even offered a position without completing a solution. Now, I have had places where I was penalized for this and was X'd out and said, nope, too bad you didn't finish it on time. That's it. You're out of here. You toast see you, hit the road, Jack, don't come back. But when you are doing these kind of interviews and they allow you to keep the AI tools on, you need to explain what you're doing, not just blindly take everything they give to you and use that output from Claude or Cursor or whatever you're using and then massage that into an answer that fits something that you feel comfortable with, not just blindly taking the solutions, because that's basically as bad as this copying and pasting from Stack Overflow and thinking that that's gonna get you the job. That's why it blows my mind that people are using these cheating tools and not realizing that, yeah, that might help you pass the literal question. But when you have to explain the code, which you will at any decent interview, even at a really bad interview, they're gonna ask you, well, what does this code do? Why did you choose this over this? Have you considered this edge case? Have you considered this case? If you have to take these questions and put them back in your code editor or your AI tool, you've kind of just failed the interview. And I know there are some people that are gonna hear this React question and think, oh man, my interviews are never that easy. That's the point. Every interview is gonna be a little bit different. You really have to do a little bit of research, but based on the hundreds of conversations I've had and the many interviews I've taken myself, that React problem is the one you're likely going to get. So if you don't know, probably just study for that. Now, big tech versus little tech is so much different when it comes to technical interviews and React questions and things like that. Often in little tech, you'll get a person you're going to speak to, you'll have some sort of back and forth. It may not matter if you get to the solution. Now, in big tech, you're much more likely to have to study data structures and algorithms, which I'll get to in just a minute. Before we get to data structures and algorithms, though, one of my least favorite types of interviews you can get, which is the JavaScript trivia interview. Now, this is honestly not that hard to study for, but it's one of those things you just have to remember to study for. You can have questions on closure, promises, async away, let versus const, explain promises to me like I'm five. These are honestly the easiest to study for. These are testing just trivia, and they're a really, really terrible metric, in my opinion, to test somebody on. But I have a cheat sheet in the show notes which should at least help you out on some of the most common questions, especially about browser APIs and things like set timeout and the event loop and just certain questions that seem to come up all the time that really are kind of old school. But if you're outside the coast, if you live like in Alabama or something like that, or somewhere down in the Midwest and you're going for one of those office jobs where you got to wear slacks, I bet you you're gonna get some JavaScript trivia questions or some C sharp trivia questions, and you should be prepared to answer those. These are the easiest in the world to study nowadays because all you got to do is go on Chat GPT and then ask, hey, give me some JavaScript trivia questions or some insert language here, trivia questions, and that should get you pretty good to go for the interview. Did I say JavaScript trivia was my least favorite type of interview? This is my least favorite type of interview, the take home interview, my least favorite type. Why do I hate these so much? Because they're time consuming, right? It's supposed to take you two hours. They never take two hours, they take like four, five, six, eight hours. So you just blew through your weekend, right? You didn't get to hang out with your kids or eat pancakes. Instead, you're building some godforsaken app and you're trying to use AI to do the whole thing. Don't do that. If you're going to participate in these types of exams, do one thing. And I've done this with many of the people I've mentored, write a test. Now with AI, this has become even more simple to do, but you'd be shocked at how many people will just essentially AI generate the whole thing. It is very obvious when this is done. The tests will be very, very terrible, and you won't have any reason or explanation for why they're there. They're just there because AI put it there, Claude or Curse or whatever, just inserted some useless test in there. So if you're going to write tests, make sure they're good. This can often be the thing that makes you stand out. In fact, one of the mentees that I worked with, he ended up going to the on-site for a pretty large company because he was one of the only people to add a test to the take-home assignment. Think about that for a minute. Most boot camps don't teach how to write tests, and most colleges also don't teach this. This is one of those few skills that people tend to only learn on the job. So adding them in can set you apart from a lot of other juniors who just may not be doing that. Also add documentation. Be really simple. Don't add a bunch of emojis. It's very obvious to tell when AI just wrote the whole documentation for you. Have it be in your words. Follow the who, what, why. What is this thing? Who created it? Why is it here? Are there any strange edge cases? How do I run this thing? Super simple. Doesn't need to be a large book or novel or novella, right? And lastly, consider this record a one-minute video walkthrough explaining your solution. Just one minute. I like to use loom.com. I've been using this tool for years. And one of the main reasons I like to use it is because it shows analytics. So you can see if somebody actually viewed the video, which can give you some insight. If you see that somebody viewed it, you say, okay, cool, they viewed it, and you know, maybe, okay, maybe my solution wasn't up to par. If you see that nobody viewed it and you were auto-rejected, that also might tell you something too. It might give you some clue or insight as to how much you should really weigh the opinion of this particular company. Now you can learn all the data structures and algorithms in React and JavaScript trivia in the world. It doesn't matter if you get bitten by the bug of anxiety. I literally had a panic attack during an interview. I'm not being hyperbolic. I literally had a panic attack. My heart felt like it was jumping out of my chest. I've honestly suffered from panic attacks for many years. It's an unfortunate side effect of my previous life, you could say. Anyway, I had a panic attack and I felt like I was maybe about to have a heart issue at that point. I had to ask the person at the time to restart the interview. Very embarrassing. I still got the job, but it was not an experience I will ever forget. So the problem with tests and interviews in general is not that you don't necessarily know the answer. That certainly could be part of it. It's weird, right? This is an unfamiliar situation. The only way to fix this is through repetition. Think about this. When a skydiver for the first time goes out, they're probably freaking out. If you or I went skydiving, then we'd freak out. We'd be jumping out the plane and be like, oh my God, I'm gonna die. Now, if it was your job to do skydiving and you did four dives a day and you did this 300 days a year and you did this for 10 years, it would be boring, right? You'd go to work and be like, oh, I can't wait to get off work and not skydive, right? It would just be boring. So interviews can be taken the same way. And that's how I thought about them. I said, Why do I have a panic attack when I'm doing these interviews? Why am I freaking out so much doing these interviews? It's not normal. How do I make it normal? Do them all the time. And so this worked for me. I do interviews at least twice a year. And I mean like the real deal interviews where we're actually interviewing for a job, and I do mock interviews at least a few times throughout the year as well. I use Pramp.com. I've heard really good things about interviewing.io. You practice with strangers. The goal is to make the weirdness of the interview just feel normal. So that way you're in the interview and you're not freaking out. Your nerves aren't just going haywire because you're at least used to either failing in front of somebody you don't know and realizing it's not the end of the world, or maybe you've passed in front of somebody that you don't really know and you feel a lot more confident now. But you must, you must do mock interviews. And if you're a little bit too nervous to do that, then do that React challenge by using this link in the show notes that I have here and record a video of yourself just going through the problem. You don't have to show it to anybody, but if you can't explain it, this should give you some insight into some gaps in your knowledge that you can just go in and fill. So, what do you absolutely not do in an interview? A lot of junior developers do this, right? They just play up, I'm a junior, so you know I'm really ambitious and I want you to take a chance on me and all this kind of stuff. The problem with that is no one wants to take a chance on you, right? Don't play up the fact that you're a junior or an outsider. This can often hurt you more than it can help you. I'm not telling you what I think is right. I'm just telling you what I think is reality. And I can tell you, if you're in an interview and you're essentially asking the person to take a chance on you, you're hurting your own chances of being hired. Also, the junior title is basically beginning to disappear a little bit. And this isn't because people don't need juniors, it's because people know that when you put the word junior in front of a job, you're gonna get twice the amount of applicants. I literally saw this at one of the companies where I worked in the past, where we put up an ad for a junior developer. We got a thousand-something applicants. I asked the HR person to just take the word junior out of there. She did, and we got a few hundred people the next time around. Now, the job was no different, just the wording. What does this tell you? People are filtering themselves out of jobs before they even get there. They are seeing a role that they should be qualified for, looking for the word junior and not finding it, and then bouncing. Don't do that. The worst thing you can do, in my opinion, especially earlier in your career, is to play up your juniorness or ask people to take a chance on you. The other things that you shouldn't do is go in blind. Do not just assume that you're gonna go in there and have a question about binary search trees or length lists or something like that. Don't make assumptions. Make sure that you have asked what I am gonna be interviewed on if they will not tell you. Do some research on Glassdoor and Team Blind and see if you can find the types of questions they've been asking. Okay, and very lastly, I save the worst for last because data structures and algorithms have been written to ad nauseum online. You can find every freaking data structure and algorithm for every interview that you ever want to know. Do you know why people don't pass interviews? It's not because data structures and algorithms are so difficult to learn. It's because people are learning random things instead of the buckets and patterns of problems and how to match these patterns to unstructured questions, right? No one's gonna tell you in an interview, hey, um, use binary search to figure this out. They're gonna say something like, We have a partially sorted array here full of numbers from some sort of calculation we're running. It's partially sorted and we want to find the highest and lowest numbers of the day or something like that, some stock ticker type of algorithm or whatever. You should probably hear, oh, sorted, partially sorted, array, binary search, boom. That is your clue to use binary search. Or if someone says, we want to find the closest path between two different points in a network for a person doing routing or something like that. You say, Oh, a network finding the closest path, that would be breadth first search, or maybe I would need to use an adjacency list or something in a graph or something like that. You just know from hearing it, you have a pattern that matches to the type of problem. So, how do you build up this intuition? So, first of all, I would check out a few core data structures and algorithms to know binary search, searching and sorting algorithms like bubble sort, insertion, merge sort, quick sort, how to deal with arrays and linked lists, how to traverse these and look through them in your primary programming language. Learn about trees, binary trees, binary search trees, learn about graphs and traversal patterns like depth first search and breadth first search. Learn when to apply each build these data structures from scratch. Try to really build them from scratch using your primary programming language. If you're trying to figure out binary search, write out a problem that allows you to explore how to use binary search. If you want to know how to build a linked list, build a linked list using JavaScript. Same thing with trees, binary trees, and binary search trees. Figure out how to do these in your primary programming language. Then use something like AlgoExpert or Neat Code or look at the article that I have linked in the show notes below and learn when to pair these types of solutions with the types of problems that you're going to get. Learn buckets of problems. Don't study random ones. But if you study those core data structures, you're going to be ready for 99% of the interviews out there that have something to do with data structures and algorithms. There's really not that many out there. I think people really overthink this. I'm a bonehead. I am not the smartest or brightest bulb on the tree. I got all the way up to the final rounds at Google, the on-site, and did pretty freaking well from doing this. I didn't study 500 leap code problems. I barely studied for an hour a day. It will take a few months if you really are dead set on this. And I do think that that is the risk you take if you only go for these companies. Now, I have a son. If he wanted to get into software, I might tell him, because we're in the Bay Area, to only focus on these types of problems, to only learn data structures and algorithms, because I think that if he does that, he will have a much smaller pool of companies where he can apply to. But if he takes a ton of time, six months to study all this and cracks one of those interviews, he's set for at least 10 years, in my opinion. So that is the trade-off. At this stage in my career, where I have not gone into big tech, I'm not going to spend a lot of time learning how to do these puzzles because they're not going to be useful to me in my career or the places that I'm applying to at this stage, system design, which is outside the scope of this particular episode, is something that I need to spend more time on at this stage in my career. And honestly, that's not that difficult to study either. You can use the same framework or pattern that I've laid out here to do all this. You practice with a person, you read up on the material, and then you actually try to do it. Record yourself talking through it. If you can teach something, you've retained 90% of the information. If you cannot teach it, you've illuminated and exposed some gaps in your knowledge. All right. All the resources are in the show notes, like I've said a bunch of times already. I really hope you find it helpful. I hope you find it useful. And I hope, if nothing else, that you stop treating interviews like they're all the same. Do some homework, figure out who your audience is, figure out what you're going to be asked, do some investigation, and then try to go in and crush it. Good luck to you out there. I know you got this, and I'll see you around. That'll do it for today's episode of the Develop Yourself podcast.

SPEAKER_00:

To learn more about becoming a software engineer with us, then check out FarcD.io. If you're not quite ready for that, then jump into our dev30.xyz program, which is 30 days of working on your mindset, habits, and JavaScript skills. See you next week.

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.