.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
#245 - What Developers Get Wrong About Interviews
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
I spent a few years as an engineering manager, and my buddy Zubin, a former Google engineer, is currently hiring developers at his company. Between the two of us, we’ve seen the good, the bad, and the totally avoidable when it comes to technical interviews.
In this episode, we pull back the curtain on what really happens during interviews. What are hiring managers actually looking for? What are the most common mistakes that cost people the job? And how can you stand out even if you’re early in your journey?
Interviews are high stakes, high pressure, and if done right, high reward. We cover:
- Why trust matters more than being perfect
- How AI has changed the interview process
- What to do when you don’t know the answer
- How likability can make or break your chances
- The worst way to prep, and what to do instead
As always - hope it's helpful!
Shameless Plugs
🧠 (NEW) Parsity's The Inner Circle Program - a highly customized roadmap to take you from 0 to hired. For career changers who want to pivot into software.
💼 Zubin's LinkedIn (ex-lawyer, former Google, Brian-look-a-like)
👂🏻Easier Said Than Done Podcast
Already a developer? Check out 👉 Not Another Course
Serious about joining Parsity? Schedule a call with me ☎️
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 Today on the Develop Yourself podcast. I'm talking with my buddy, zubin, about interviews, everybody's favorite topic. Most junior developers think interviews are about proving you can code Behind the scenes. What managers are often asking themselves is can we trust you? And today I want to pull back the curtain a bit on what really goes on when we're doing the hiring. Fresh from the horse's mouth, zubin, I know you are currently doing some hiring, right? You're interviewing people right now, aren't you? Okay? What has that experience been like? What's it been like right now, 2025, trying to hire developers?
Speaker 2:Well, since the last time I did it, about a year and a half ago, a lot has changed mainly AI, right, and so it's really hard to actually get a meaningful signal. Can this person actually program? Or is this person vibe coding their way into an interview? How much of this is real skill? How much of this is the AI did it for me? And I know people say like, oh, if the AI can do it for you, then why do you need to interview them? Well, here's why Because the AI can do simple things for you, and when you're a candidate, chances are and you're not actually a software engineer already, professionally, chances are you're doing only the simplest things.
Speaker 2:You're sort of skimming the tip of the iceberg, so to speak, and we need to find a real signal. For the same reason, brian, that in the Inner Circle program, you and I now require people to do their baseline exercise without AI, and we've seen in the last three months the number of people saying okay, we really don't know as much as we thought we did. Like every single student is now saying that and we're pulling out the fact that AI makes you think you're better than you actually are and if you're not that good. You're not going to scope in a real world environment because most of the time for most of us unless we're in really new startups that is building a lot of greenfield stuff most of the time we're walking to an established code base I think you mentioned this in Develop Yourself recently where there are hundreds of thousands, if not millions, of lines of code already written and the AI is not going to be able to help you work with that. It's just not, you know so, yeah, diminishing returns.
Speaker 1:This is an interesting one, because I had almost the exact opposite experience during an interview of where the person says you know what, keep cursor on, and we want to see how you code with AI assisted tools and you're. But I know that's not the case for a lot of other companies, especially larger companies. You work at a much larger company. I don't have a lot of experience.
Speaker 2:I will say we're okay with that, but that's not the only basis on which we get the signal. Of course, we expect people to use the tools, but we want to know you're using the tools responsibly, intelligently and where you're in control. Which means we first need control, which means we firstly because there are multiple rounds of technical interviews, right, and so you will have some rounds where you know we don't. We're going to just talk to you about stuff without any AI. We're just going to talk to you about what you wrote. So the AI piece could have been before. That it's not that it's no AI, it's. There's a round to handle for where all you know is AI, it'll come out. We will extract that signal that all you know is through the AI.
Speaker 1:Yeah, so it's definitely we need to be using that as part of the tools. Yeah, I was a little bit surprised, actually, in my interview. I thought using AI would make it easier, but in many ways it made it more difficult, because when I either rejected or accepted code, the CTO, who was on the line, who knows a lot more than I did, was like well, why did you reject that? Why did you accept that? You know, that actually looked like it would have worked. Like what was the? What was the point of you not accepting? I'm like, oh, you're right, Like that could have worked. And then I was defending my opinions and we we had some disagreements about what I could have done. I ended up getting the offer, but it was. It was a really interesting interview. I actually really enjoyed it because it was more discussion rather than like hands-on keyboard in me coding in front of somebody.
Speaker 1:But back to the interview process that you're doing. I think there's so much misinformation about what we're looking for in interviews We've talked about this a little bit in previous shows, like the idea that we're just looking for code robots. What's something that you're looking for in a candidate when you're doing the technical portion of the interview? We can start there. We can talk about the behavioral part too.
Speaker 2:But during the technical piece, what are you looking for? Yeah, during the technical piece, we're basically looking for someone who knows how to think about a problem and who's collaborative enough to invite opinions on their approach, discuss it intelligently, present the pros and cons. You know, engineering is a place where you know people are very opinionated. Now I know a lot of junior devs are like ooh, you know, I want my code to be scalable and clean, code right. But with respect, I don't believe most people actually know what that means, because that's a never-ending continuum.
Speaker 2:What's clean for me may not be clean for you. What's maintainable and scalable for me may not be maintainable and scalable for you. And some people are really very advanced at that and as a beginner, I don't know if that's going to help. So I think you know a lot of what we look for is can you actually approach this intelligently? Or my heuristic, my sort of shortcut is can I trust that this person will get the job done? And if they cannot, in that instance, when I delegate it to them at work, will they ask the right questions such that they're reasonably likely to figure it out? Or I can trust that they will escalate correctly to get the help they need. Like these are three really important parts of it, you know.
Speaker 1:Back to the trust thing that is. That is, it seems obvious to me now after failing so many interviews, and I'm just a paranoid person. I interview honestly too much. Like you're kind of my therapist off the show, right, can I call you? Sometimes I'll zoom in. Oh, should I jump ship? Should I go to the? You're like, hey, you know, calm down, but I interviewed too often and everybody knows this about me. That knows it's in my personal life. I have to calm down, but I've done so many interviews and gotten a decent idea, I think, of what goes on in them from this point. And you're right, it's. It's about this trust thing. How do you like what did, what should candidates know about? Like showing that in an interview. Like how do you, how do you create trust through an interview with your interviewer at a high level?
Speaker 2:look this is a really hard one. So I just recently finished up this week with aline learner from interviewingio right and this sort of came up yeah, in fact I'll connect you with her because I think she's cool, very cool yourself as well if she's open to it. But you know because she's got, she's done what 200 000 mock interviews and interviewingio like the amount of data they've got is incredible and not mainly big tech right when he's big tech.
Speaker 2:so yeah, but she's, she was a developer, she's. She switched into, she became a chef for a while and she switched into engineering then, then into recruiting and now runs this business for the last 10 years, which has done amazing stuff with data right. And what we talked about is most people only think about it from the candidate's point of view, because that's what YouTube and Instagram will tell you. Oh, it's data structures and algorithms, it's this, it's being able to invert. Now Aline has recently contributed to the latest edition of Beyond Cracking, the Coding Interview with Gail Lackwell right, so they've re-released that book.
Speaker 1:Oh, very cool. They're re-releasing the book. Yeah, oh cool.
Speaker 2:And she's very kindly agreed that. You know, some students get some special offers and stuff from them Nice, which is great. Excuse me, I seem to have choked on something, but you know, she, so she, so she and I were talking about this, and most people think about it from the point of view of the candidate, whereas what the actual hiring manager wants to know and this time, like every other time I've hired, whether it's in tech or in the law, whatever it is I'm reminded that the hiring manager is actually desperate for somebody. I would really want to fill the role right now if I could. Right, yeah, but the challenge is there are lots of applicants, there's not enough time because you have to do your day job, there are multiple rounds, so this is an expensive process and you kind of have to do the due diligence and you're really just hoping that the candidate comes in and just does a great job. Now, what does a great job look like To me, and this is what Alina and I were talking about different interviews are different styles and many this is the sad thing.
Speaker 2:Alina talks about this beautifully many people don't like interviewing and they become terrible interviews. They're not incentivized properly, they're not interested or they just find it a real imposition on their time. You're going to struggle with an interview like that, but if you have a good interview, they're going to be someone who's very vested in hoping that you will do really well and they'll keep helping you, they'll keep nudging you, they will interact with you and they won't care if you didn't finish the problem perfectly. What they'll care about is how far along you got, how you thought about it Like this is what happened to me when I was at Google One of my tech rounds, because I had three or something. I didn't actually finish the problem. I knew how to do it, but it was 40 minutes. It was a complicated enough problem and I spent so much time talking about the edge cases. And it wasn't an IDE, it was in a Google doc, no formatting.
Speaker 1:That's right.
Speaker 2:Because you've done these loops too. So you have to talk to the interviewer, you have to show them that you would have finished this anyway, but you were so thoughtful in your approach. That's kind of why you ran out of time. If you ran out of time, or if you didn't run out of time, you were still very thoughtful in your approach. You were collaborative and a good interviewer will want to see that, because most real world problems are not going to be done quietly in a silo. You're going to need somebody else's help, like the entire time I was at Google, I constantly needed other people's help. Right, that's normal. Even in my current job, I constantly need other people's help because there are pockets of knowledge in organizations.
Speaker 2:So if you don't collaborate well, how do you trust someone who doesn't collaborate properly, who operates in a silo in silence without caring?
Speaker 1:and stuff like that. It's awkward too, imagine. So.
Speaker 2:It's awkward to imagine an interview where the person's just typing I know just like super silent, yeah, and they can hear you breathe into your, you know, into the microphone and he's waiting for you. It's horrible, it's not a good thing. So I think that's one way for people to show trust. The other way for people to show trust, I believe, with a good interview, is to say if you don't know the answer, don't make up stuff like. I have interviewed people over the years where they'll just make up things right and and you ask them and you're sort of leading them in the question, saying so if you do this, it's going to speak to the server and you know it's not, you know that's not going to happen, and they're like, yeah, yeah, I think that's what's going to happen. No, don't do that. Just say I'm not 100% sure. I believe it would, but it could be wrong.
Speaker 1:I would look and if that's the case I would do this. If that's not the case, I would do that, you know, especially for system design. Like don't make up stuff, you know. So it's oh my god. Yeah, oh, I used to make up stuff. Insist. Oh, this is embarrassing. I would just like rattle off, like my memorized system design one and two, the books I read from alex zoo and try to just parrot them back and think that if I get the right order of this incantation like it's some sort of magic spell that they would just like hand me the job. And yeah, it didn't work out. I'm embarrassed by a lot of those interviews. But yeah, you know, don't do that, because I remember doing interviews for mostly junior candidates, so I did a ton of junior interviews. Actually, are you doing any juniors lately for these roles?
Speaker 2:No, no, mainly junior. Yeah, it's mainly you know, like the zero to three, which is what we consider to be junior.
Speaker 1:Okay, that's pretty junior, yeah, but you know, even my interviews with seniors aren't wildly different. But what I noticed a lot was what you're saying is this trust factor can really get broken with junior interviews. Because, you're right, we want to see you win, quote, unquote. We want to obviously fill the role. We're not here to deter you, we invited you in. We're taking hours of time, we're doing our day job, which I think a lot of people don't realize.
Speaker 1:There's not much training on interviews either, if there's any at all, and most times, in fact, at the small companies I've worked at, there's been zero training. It's been like hey, are you able to interview today? What do you think you're going to ask? Ok, what do you think you're going to ask them? Okay, cool, I'm going to ask them this Okay, meet you at lunch and then we'll like do the interview and then you go in there and that and it's this super arbitrary, very subjective thing, and that those aren't good. But that's the reality of interviews. But what I remember asking candidates, junior developers, was like questions that I've obviously know the answer to. I mean, we know the answer already and they would just make up something and I'm like you're breaking the trust here. It's much better if you say like you said, I don't know, or I could probably figure that out, or here's my understanding. I'm not sure if that's right.
Speaker 2:It just ruins the relationship off the bat, yeah, and it kills the trust and you don't get a second chance to reestablish that trust Again. Another thing that Alina and I were talking about is, in an ideal world, are selling to each other and you just think about it Like I remember I just had to get this old, dead tree in my front yard cut down, right, something as trivial as that. And I like interviewed three landscapers, right, and I had no basis to know whose chainsaw was the best. I wasn't inspecting that chainsaw, you know, I wasn't looking at the truck. I was just asking them what do you think needs to be done, how much do you think this is going to cost and how? You know, are you going to clean up after yourself? Are you going to retrieve it? What are you going to do with it?
Speaker 2:You know that kind of stuff and, based on the quality of their answers, I either trusted them or I didn't trust them. You know it's as simple as that. Either one making eye contact, they were giving me thoughtful responses and saying, well, here are your options. Those are the ones I end up going with, like the ones who are more conversational. I end up going with right, because I wasn't going to inspect their chainsaws. I wasn't. What do I know about a chainsaw?
Speaker 1:Of course, that, yeah right. Have you ever had this happen? Have you ever interviewed somebody that was really, really smart, like good on paper, excellent technical skills, but just like not great personally All the time? And then, like what do you do in that situation? Like do you say, you know what, like we're going to go with them, and I think I know the answer. But I'm curious Like what do you? How do you approach it?
Speaker 2:This happened a lot when I was and because, like you said, I tend to work more on the sort of big tech side. So far, like at Google, for example, and in most of the companies I've worked with, even outside of engineering, when you reach a certain level of scale, there's always clear process and rubrics, right, they're matrices that you sort of evaluate in multiple dimensions with clear instructions on what you know. Not good, good, great, outstanding, what does it look like in that dimension? Right, and so there are these matrices. So you know, okay, so it's trying to reduce arbitrariness, that's what the matrix does. And so when you have one of those, very often they are, you know, technically very sound, but not able to collaborate, not able to communicate, will struggle in culture. Now, you know, Google, for example, has multiple runs and there's an explicit there's the culture, fit round yeah and Googling is an explicitly sort of inchoate, slightly unclear term, which is will they fit here?
Speaker 2:Which is a partly intuition-based thing, partly personality-based thing, you know, and that's important Like that's important in every organization that I've been to when teamwork becomes important, where it's of a certain size. Now, that wasn't my interview for my first dev job, when there were four and a half people as one part-time person, right, there wasn't, it was just a conversation, a coffee here. Debug this for me and let me see if you can code, if you can debug this right. But for the bigger organizations, there are matrices and you have to sort of evaluate that and these aren't public documents, so you have to basically work out. It comes down to this. It's exactly what Lynn and I were talking about. It's a buying decision and so therefore, we have to give them the certainty that they want us to be part of the team, and that's a multidimensional thing. Quite simply, it comes down to this Do we want to work with this person? Do we want this person to come into our team, into our home, and be part of this family? You know.
Speaker 1:It is that, especially on a smaller team, on a smaller team, it's even. It's so much more important. Oh my God, back before the pandemic you know this we were going in office interviews, lunches this was a big thing at startups in San Francisco. Every startup I interviewed at was like let's get a team lunch, and that was a big deciding factor. And if the team lunch didn't go well I've seen that happen. Yeah, there was a, it was a no-go. It was it's like we're too small to take a chance on somebody that's really, really smart but could corrupt the culture and destroy the team it's too inside out yeah, I hope you're enjoying this episode.
Speaker 1:Now you know that I own an anti-boot camp 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. And now back to the episode.
Speaker 2:You know, since you worked in slightly smaller, you know most startup-y sorts of places. If someone were to say, what's the most important thing, you know, if it's not coding, what's the most important thing, you know. If it's not coding, what's the most important thing? Do you think there's actually a most important thing or do you actually think objectively, it's really a basket of things that you're looking for. What?
Speaker 1:do you think? Yeah, it really is. I look at this like a general bucket of things. You kind of needed to start up like. You need to show grit. You know the ability to obviously have technical ability.
Speaker 1:Autonomy is a huge one you're trying to figure out. Can this person be autonomous? What are their expectations to? This is why I think a lot of engineers from larger companies often don't do too well at really small startups. When it's like very nebulous what your job is, what you're going to be doing. Your coding skills don't have to be necessarily the best at all. Like that, you can be pretty mid in many places and get in at a small startup and as long as you tick some other boxes I mean, for example, my background with running Parsity was actually a huge reason why I got an offer.
Speaker 1:At the last startup I was at, they said one of the reasons we got you was because of this. You know I definitely wasn't the best software engineer on the team. I was probably one of the worst on this particular team. I was with some really really top-notch people from FANG companies and they were all what I considered much smarter than me, but I was honestly better at them at some things like front-end. I understood how to do some marketing. I could help out with landing pages and marketing and also recorded videos for them Like I'm still on their landing page, I believe, with some of the videos that I was editing in my spare time. So I was working on all these different fronts and that's a hard thing to find. So it really just varies from startup to startup. You know, I think the current one I'm at they don't want me doing that stuff.
Speaker 2:I'm more of a technical lead at the new and what you said there, right, Brian, it varies from startup to startup. It varies from job to job, Like how would you explain that to a candidate who is in a position of such uncertainty that they want a single formula? How would you explain that to them?
Speaker 1:Like you know, it's hard and I do see that there are some practical things, like during an interview. You probably should do Like I for one like it. I think juniors especially have this problem. Who's probably listening to this show? They come into an interview and they're coding in front of somebody like you or me and they're thinking I'm not as technical as this person. So I'm going to almost diminish myself during the interview. I'm going to try to avoid rejection and I get it right. We all want to avoid rejection and I speak to smarter people than myself every day and I still. I still talk to them as if I'm teaching them because I want to enable the trust factor. When I'm coding in front of somebody, I want to speak my mind and show them like I'm going to teach you, basically through my coding, what I'm doing. I'll explain things as if they didn't know and this can lead to good dialogue, conversation and the likability factor. This is one of those things. You can know React and in TypeScript, in JavaScript, python, go, whatever, and you can understand system design.
Speaker 1:One of the hardest things to do is teach people the likability thing and I struggle with telling people how to do that. You definitely have pinpointed that and that's one of the reasons why we have people on camera so much. At Parsity, like weekly, they do videos. You encourage that a lot. We love to see the videos. I know it's one of the hardest things people do. The likability factor is so hard. What do you tell people that are that you know are good people, but they're coming across unlikable on camera? Well, how do they fix that?
Speaker 2:it's you the only way you fix that. Because I I categorize that as a communication problem, right? Because even if you're a good communicator, in that what you're saying makes sense or what you're writing makes sense, if people don't like you, they will shoot the messenger. That's kind of the way the human world works, right? And so we've got to accept that reality, unfortunate as it is, for what it is, and you just got to identify what it is that makes you come across that way and systematically make changes. And it's not going to happen overnight. And, yes, it's another thing on your plate that you need to fix. Yes, you've got to treat it right up there with if I don't understand how to do recursion, and I'm going to practice it.
Speaker 2:Well, this is something you need to practice over and over again, which is why we get students in the inner circle to do the weekly videos, to answer different questions, to teach different things, because then, when it's game day and they're at an interview, most of that stuff is muscle memory. It comes without thought. That's not where the effort is going. The effort is completely focused on the interviewer. And here's the other thing that I tell people is again, alina and I were talking about this, most people will fail interviews. That is just normal. I know Brian says that he's failed a ton of them. He's not the only one. We've all failed a ton of them, in fact, we've failed.
Speaker 1:Everybody does.
Speaker 2:Yeah, you have to yeah, and so if you think having one or two or three interviews again, alina and I talked about the data is very clear in this If you think having one or two or three interviews is enough, it's not. If you don't know how to generate two to three interviews per month, you need help. I'm just being really direct about this right, because you will fail the vast majority of them, and if you don't know how to improve, then you will repeat the same mistakes in the next one and you will run out of opportunities before you get successful. It is just like anything else in the world. You need the reps and you cannot simulate. I don't care how much lead code you do. In fact, I think the guest she said lead code is not a simulation of the real interview. You know now. They offer an interviewing platform, by the way.
Speaker 2:Yeah, but people oh really they offer an ai interviewer now as part of you know and I'll sort of link to that and you know, in my podcast I'll send it out to the, the students as well, but it's there for people who want to try out a bunch of problems there's an AI interviewer that is interactive, that is meant to simulate the back and forth, and even that, we'd acknowledge, is maybe 70% of the way there, but the remaining 30% is game day is different. Game day is always different because the environment is different and that's why we get our students to keep practicing every.
Speaker 2:As much as we can simulate, we'll simulate, but there is no there is ultimately, no matter how much you do spend time playing guitar hero, when you're on stage in the bands and the band is live, it's a different experience and the only way to practice that is by being on stage with the band live.
Speaker 1:There's no other way to practice that bit, you know man, I wish I was in inner circle back in the days, because I learned this just through trial and error. Yeah, and at some point, I don't know what clicked in my head to tell me I need to start explaining things on camera. Maybe I learned it from an article. I don't know where this came from, but once I did that, it was like something clicked. I immediately figured out the gaps in my knowledge. I'm like I can't explain this. I thought I knew recursion. I don't know how to explain recursion. I thought I knew prototypical inheritance. I can't explain prototypical inheritance on camera. I'm like, oh my God, I don't know as much as I thought and that led me to all sorts of cool rabbit holes and helped me reinforce my knowledge. And I've made hundreds of videos now that have never seen the light of day and have helped me tremendously in interviews, because I would have incredible anxiety during an interview and now I just don't. I mean enough reps, like you said, and something unique becomes mundane.
Speaker 2:And you develop an intuition for it. So again, I I learned this stuff back in 2003, 2004, when I was a junior beginning lawyer and I was doing trial work is I, my client's future and my livelihood depended on me being able to convince a complete stranger sitting on a bench about the facts in my case, Right Like that is, and the consequences are huge. You know, people lose.
Speaker 1:That's pretty crazy. Actually, it's pretty crazy.
Speaker 2:Their life, their livelihood, their money, yeah right, and so you take it really seriously and you're like okay, just because I understand what's going on here, can I communicate in a way, not just can the words come out of my mouth, but can it be understood in a way that's persuasive for the audience, like that's what real communication is, not what you say, but what gets understood right, which is what we teach people in the inner circle now is be understood, communicate the signal that you know what you're talking about and this is how things should be. And if you're wrong, say you're wrong, that's totally fine, that's absolutely okay, and then commit to fixing it.
Speaker 1:It's better than the opposite.
Speaker 2:One thousand Better than the alternative so much better Because trust comes. We've all made mistakes. Now I will say that another reason why you need multiple interviews per month is, again, as Brian said, most companies don't have great training for it. I don't know of any company that incentivizes good interviewing. There's no consequence for being a bad interviewer. That's the reality right.
Speaker 2:Yeah, it's terrible. Yeah, it's terrible. And so therefore, you can show up on the day, be a terrible interviewer. Nothing's going to happen to you. It's somebody else's life that gets messed up. So by having lots of interviews, you increase the odds that you're going to find a good interviewer. And it doesn't matter how well you perform. If you have a bad interview, it doesn't matter how much you know. If you have a bad interview, he doesn't like you. Or my personal pet peeve which I even saw, unfortunately, at times when I was at Google a couple of times from other interviewers, is the interviewer, without realizing it, has a bit of a prejudice. They're interviewing you to know do you know what I know? That's the wrong standard for an interviewer.
Speaker 2:The right standard for an interviewer is do you know what we expect you to know to be successful in this role? You don't have to know what I know. Do you know what is needed to be successful in this role? And a lot of interviewers will fall into the trap of oh, they should have known that, but why? Because I knew that. Yeah, but that's not the standard. Yeah, the standard is do they need to know that for the role or could they figure that out for the role and if you don't have multiple interviews?
Speaker 1:you'll get stuck. I've seen that so much.
Speaker 2:I see that all the time.
Speaker 1:It's not just in software engineering.
Speaker 2:I've seen this in the law a lot. I've seen this in management a lot.
Speaker 1:It's so annoying. I remember asking you know, people were bringing up questions to ask in one panel I was on and there were these really just like weird beneath-the-surface JavaScript trivia. I'm like this is just coding trivia. Who cares? Also, if they answered all this correctly and we hired them, they're going to be writing React code. Does this matter at all? And of course we. I obviously we hired some. Some of the wrong people. Using that strategy really bit us in the end. Yeah, I think this is that's one of the biggest like things.
Speaker 1:I wish more people knew that your interviewer probably doesn't have much training at all. You know, you got to take some of these things the grain of salt. The worst mistake I see people make is they fail an interview and then they'll like use that singular experience to like to determine what they should do for like all their next interviews. Like, oh my God, they asked me, you know, about prototypal inheritance in JavaScript and I failed. Now I got to go study all the JavaScript trivia to make sure I'd never fail again. I'm like no, no, no, no, no, no. That's one random person in one random interview you did. You cannot extrapolate that to the rest of these random people you may interview in the future and I'm like, please don't do that.
Speaker 1:If there's one thing you take away, don't do that.
Speaker 2:Yeah, please don't do that. In fact, just this week, when I was doing the accountability review for one of our students, I think they had an interview where the error that showed up in the console was you know how, when you're working with JSON or even JavaScript objects in JavaScript and if there's a circular reference, there's that error that comes out with the word circular in it. Have you ever seen that?
Speaker 2:Yes, circular dependency yeah, and so I think correct the circular reference, that error, and they sort of going down this rabbit hole of trying to understand that. I'm like no, no, no, you don't need to understand that. You need to understand why that happened and then know where to look in the code, because that's just a JavaScript stack trace. That's not actually anything tangible, like it's someone who wrote the language that way right, like you're not going to be able to understand where it's come from.
Speaker 2:It's come from some JavaScript object or a JSON, you know. String somewhere has a reference. That's, you know, a bit circular. It's endless, it's deeply nested. You know beyond what the compiler can handle.
Speaker 2:And so I'm like look at the class of problem, don't look at the error and try to understand everything about the error message instead of understand where the error message got thrown and then understand that class of problem there because you know, then you'll be able to reuse that knowledge in other interviews. But they, you know, understandably they were getting really thrown by this because they couldn't solve it, of course, but you know, again, that comes from experience, that just comes from experience, you know that's the thing, yeah, and I I feel bad when people do that because I'm like it can ruin the rest of the interviews.
Speaker 1:Then they, they over-index on one type of interview and they think, and then they get to the next interview, like, well, now I've got to ask the lead code question. Well, brian, never, brian said no one asked that. And now I got that. Well, that means my next interview is involved. You know nothing but lead code questions, and it's funny.
Speaker 2:This stuff happens in data structures and algorithms too. Dynamic programming when going for fang compute, but it's like less than seven percent of questions of like. I didn't even touch dynamic programming when I was going for my fang interviews because I'm like 93, the odds are 93 that I'm not going to be using that. Whatever the number was right. And alina and I talked about this. She's like yeah, when social media says this is a really hard thing, this gets asked at fang.
Speaker 1:Sure, maybe it got asked once in the last 20 years yeah, one time or something like if there's a knapsack problem, I'm like, well, let's not. Yeah, recursion is going to come up almost certainly in all your fang interviews. That's probably the most likely thing. Yeah, but yeah and random, obscure dynamic problem. Yeah, it's so weird. What's the one you?
Speaker 2:said oh, I mean no, I'm just saying like fear cells, so you do something that oh yeah people are going to click on it, people are going to watch it. It People are going to obsess about fear cells, but the data, tells you something quite different.
Speaker 1:Before we end this, this is a weird one. What are you silently judging people on when they're interviewing that people probably don't think about? What are some things you might silently be judging?
Speaker 2:Look, it's a hard one because I've been trained so hard on the bias thing but there's so much training. I got at Google on the bias thing, which I'm glad I did, because you just don't realize how biased you actually are. But I would say I would invert this question as what is the thing that people under-index on that could have, especially in smaller organizations where you know? You nailed it right at the start, man, you used the word likability, like I think like if you set someone's radar off and it may not be your fault, it may just be the dynamic between you and the interview if you set someone's radar off, they're probably gonna find another reason without even knowing. Subconsciously, they're gonna find things to nitpick on for sure, and I think that's that's the human thing we want to. We want to come up, show up to work and work with people we like that's the heart.
Speaker 1:This is true. I mean, yeah, people kind of realize this at some point. Yeah, I mean, I've been. I know that I've been unlikable, at least at a few places I could. I could feel it. I could feel it. I made a joke that I thought was going to land and it didn't. Yes, or you know, or I said something you know that was wrong and instead of giving me grace, the person obviously is like you should know that was wrong. And instead of giving me grace, the person obviously was like you should know that kind of feeling. I'm like, okay, I've, I've lost and that's okay, you're going to be not liked everywhere you go. I did meet a guy I think I've shared this before A guy he said he failed a hundred interviews and I was like there's no way.
Speaker 1:And I and I got on the on an interview, setting Just quiet, and people are like what does that mean to be unlikable? Like he cut me off when I was trying to explain things. He's like hold on just a second, just a second. I think I almost have it. I'm like well, that's not what I want to hear when I'm trying to give you some advice.
Speaker 2:Like I'm the interviewer.
Speaker 1:There's a dynamic here and I'm trying to help you out and you're saying, no, I don't want to hear it. And then he was sitting in silence. I said, oh, do you mind sharing what you're doing? He's like, well, I'm just trying to think so, yeah, I'm like okay, yeah, so leave me alone yeah, that's, it's not, that's not a collaborative interview.
Speaker 2:I will say that I've faced that as well my entire career, because in the sense that I I think what makes me unlikable or definitely jarring for a lot of people is that I'm I'm fundamentally a very high energy sort of person. Right, you know this um, I'm quite exuberant, I smile a lot, I crack jokes, I'm very, I'm quite extroverted socially and both in the law and engineering. They're surprisingly similar.
Speaker 2:People don't necessarily like that, you know especially I can see that they're more of the introverted type or they they find the energy too contrary to theirs. I know I've started off on the wrong foot and then I can try and sober up during the call, but then I'm also changing who I am. Now. That's not something I necessarily want to do too much. I may try and tone it down a bit which is fair.
Speaker 2:But at the end of the day, if I'm sort of an extroverted personality and they don't like that, that's going to be a fundamental problem. But then that's me also assessing their fit for me, you know, and but that's likability, right. I may not be likable to a team of quiet introverts, whereas I can be a bit raucous and I can be a bit mischievous at work and maybe that's not going to fly and that's fine.
Speaker 1:Yeah, that's, that's a good thing too. I think that's something we didn't really touch on. But yeah, it's a two way street in many ways I get it. You know people want to get the interview, they want to get the prize. It's also, you know, in some ways you have to learn to be yourself enough and if you're, and if that's going to be completely antithetical to the people you're interviewing or just be such a mismatch that it's not going to work, then maybe, just maybe yeah, and you know what being likable, you'll know if you're really honest with yourself.
Speaker 2:You know whether they're that you're, whether you would like you if you weren't you.
Speaker 1:That's a good one.
Speaker 2:That's a really good one.
Speaker 1:You know there are things that you can change. So, to end off, put yourself on camera. If you don't do anything else, start recording yourself answering some of these freaking questions. Don't over-index on the one interview you failed and what else.
Speaker 2:What's the last parting word? Well, think about everything from the hiring manager's point of view, because that's actually what kind of counts, and it'll help you get much closer to where they're at. And you'll signal that, because I know, as a candidate, we're all trained to obsessively think, oh, I need this job or I need this interview, I need to do well, and you know what your idea of well may be completely different from what their idea of well is, and you can absolutely ask them that you know you should be Again. Aline talked about this. That was a really good episode. Now that I'm thinking about it, like she talks about asking questions. If you want to postpone things, you know, because you need to postpone the interview to get better prepared, you can do things like that, but also ask people what kind of interview is this? We keep telling students in the inner circle program like oh my god, there are 9.
Speaker 2:To 14 different types of technical interview. Please find out what kind it is yeah, find out what you're doing, you know people still don't do it because they're like, oh, I want to be likable, I don't want to ask too many questions, I don't want to ruffle fur, that is, am I being too? But no, you're entitled to say hey, if I'm going to spend an hour of my life, or three hours of my life on this thing, what is this thing?
Speaker 1:What kind of interview is this yeah, what is this exactly? It's crazy that people don't ask that. I'm like that's actually the number one thing. That's maybe the one thing you should take away. What kind of interview are you walking into? Because you have no clue.
Speaker 2:It's like flying blind. It's like why, especially when the game could look deceptively similar, you could walk into a snooker tournament and think it's billiards and lose. Because this is what I keep telling the students. I'm like, just because there's a green table and there's a cue stick and there's balls doesn't mean it's the same sport. Know the sport, know which one you're walking into, oh man.
Speaker 1:That's funny.
Speaker 2:I don't know the difference between snook doing right now.
Speaker 1:Yeah, oh man, always good, always good talking to you. I hope you've got some good stuff out of this, because interviews are such a emotional and technical game to play and but there are ways you can quote, unquote, beat it. So yeah, check out parsityio slash interdesk circle if you're interested in becoming one of the few people that work one-on-one with us and other than that, we'll catch you next time. Catch you next time. 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 show notes. See you next week.
