Oct. 10, 2022

How Not To Get Fired From Your First Developer Job

Are you wondering what your first day will be like when you finally land your first developer position? I was scared. I thought I’d get fired and found out as a fraud. In this podcast episode, I shared what it was like for me. I left no stone unturned and shared an excessive amount of advice for people that might feel anxious about their first job.

As a bonus, I shared my experiences with my 2nd and 3rd developer jobs too. I hope this episode helps!

Dev Interrupted
What the smartest minds in engineering are thinking about, working on and investing in.

Listen on: Apple Podcasts   Spotify


🤝 Join our junior friendly developer community:

🔥 Want more personalized help from me? Here are the paid mentorship and review services I offer:

Don Hansen:

I want you to listen to me right now. If, if you ever get a job as a developer, if you ever land that first job, you are going to be a fraud. You are going to be found out and you're gonna be fired. At least that's exactly what I told myself when I was trying to find my first developer job and going through all these interviews and dealing with all the rejection, and I'm like, No one is ever, ever going to hire me as a developer. And if they do, I faked my way into it. I am telling you I had imposter syndrome like no other. So today I'm gonna talk about what it's like. What it's actually like on your first day as a developer. Um, at least what my experience was like, and that's what I'm gonna share. Now I want to alleviate some concerns. Cause I know a lot of people, they're scared, they're curious. Um, you know, like, are they gonna be supported in their first role? And you know, if they are hired, um, did they stretch the church too much? Is too much gonna be expected out of them? Are they, What if you're moving across the country, get this job and. They're still unsure about you, and you're wondering if you're really gonna keep that job for very long, and you're worried about your financial situation, your career. So many people have these concerns. This is why I think this video's important. So I'm gonna share my first day with you. I'm gonna share how it went, all the worries that I had, and I had many, uh, so hopefully this will. I think it'll help alleviate things if that imposter syndrome is like really setting in right now. So my first day at my company, Let me back up a little bit. I remember going through an interview process for my first job. It was in Chicago. I worked all three of my, uh, developer jobs in Chicago. My first job, I was living in Northwest Indiana and. Remember this interview process in Chicago. I remember the hour and a half train ride, and I think it was like a half an hour to take this, uh, supplementary train to get to the building. And I remember walking in, I was super intimidated. Like everyone was super kind and nice, but it was just intimidating. I like, I had never. In my, like, I was almost ready to quit or quit as becoming a developer like so many times throughout my journey, I thought I just wasn't good enough. I was just scared and I was, I, I felt like I was an intelligent enough and like this showed, I feel like this showed in my lack of confidence in the interviews. And I remember my interview process. It started with a couple phone screenings, one with hr, uh, one with my, uh, soon to be first manager. And it was a really pleasant conversation, but I always at the back of my mind thought like, he probably doesn't know enough about me. Or maybe he just saw that one project that. I ki like it was my best project, right? All my other projects, they were much shittier, poor conventions, right? And I only had that one project. Could I really replicate that? What if they're actually gonna hire me based on that project and I can no longer, you know, perform well? Because that doesn't really resemble my skills. So, , I had all these worries and I remember going through each part of the interview process and then talking to the entire team in different parts of the company, and then eventually I think the co-founder, co ceo, or old ceo, I don't know. I just talked to a bunch of people. That's all I know. And I remember I finally at the offer, it was crazy. Like I . I was so happy. I was so fucking happy that I finally, finally landed my first software as a develop. and that lasted for like a very short amount of time. Then I'm like, Oh, okay, well I'm gonna read the contract. There's nothing that guarantees me this job if I do accept it. This is all the way in Chicago. Uh, what happens if I get fired in like two months cuz I'm found out that I'm a fraud or I don't know. I had all these thoughts going in my mind and I remember. I was able to negotiate my salary app. I think it was offered at 70,000 in Chicago. This is like six or seven years ago. Wait, yes, around six years ago. Um, it was for a UI engineer role, uh, JavaScript React, stuff like that. Uh, little react, a lot of Java script in the css, uh, because it was on top of a, uh, jengo. And so I was basically, I, I would dive into some of the template stuff, but mainly it was a lot of css, a lot of CSS template stuff, and a little bit of. Um, yeah, so I negotiated a little bit higher. I got the position, I decided to commute. There's no way I was gonna try to rent an apartment this soon, So I commuted. It was a long commute, was like somewhere between an hour and a half and two hours each way. I was so exhausted. But I remember my first day and I, I didn't get a lot of sleep. I know that I walked in. Um, I could not be excited. Like I, I was kind of excited all up until this point, but I walked in and I'm like, Man, now this is serious. Now I'm actually like, I walk in and I'm actually getting paid to walk in right now. Uh, much higher chunk of money than I've ever been paid before. And so I sat down at my desk and I remember. . Um, so my boss is actually remote, which is interesting. It took me years to meet him in person. He was remote, which also kind of shifted my perspective on remote workers. Um, well we could do a, a video on that if you guys want, but, um, Yeah, I remember sitting down and I'm like, I have to start doing stuff. Like I, I, I'm just sitting here burning cash. I gotta start doing stuff. And I remember like, everyone kind of just came in. They were super nice. They, you know, just saying hello, introduced themselves. I'm like, You guys are paying me just a bullshit and talk like, like, this is probably a problem with my personality because I'm like, if I'm getting paid this amount of money, like I, I'm not used to getting paid this amount of money. I, I need to do something. I need to provide some value and. later. Learned the best thing that you can do when you first start a job. Like have those conversations with employers. I think one big piece of feedback that I've gotten from multiple managers is I didn't take the time out to create those connections early and I did, cuz I'm always like trying to get stuff done and I'm. Very at, at first, when I first start a company, I'm always trying to get stuff done and do it effectively and provide my value and for, you know, whatever I'm worth. And I, I always have to do something. And so the feedback that I got is I need to take time. Like that first week you imagine like you're getting paid a whole week, a lot of money just to talk with people. This feels weird, right? Like if you switch from an hourly job, which I came from to something like this. It feels very weird just to sit on my butt and talk to people and get paid for it, but that's what I highly recommend you do. Talk with design, talk with qa, talk with product, talk with the developer team, obviously, um, get to know people and just bs, right? You don't have to be this amazing conversationalists, but just like being kind and humble and, you know, ask questions about what they. Right. And how are we gonna be working together? I'm super curious about that. Um, sometimes that'll be revealed in the interview process, but you, you can ask really simple questions like that just to, you know, at least introduce yourself, start to build that bridge. So, I didn't do that. I kind of did for the people that did stop by my desk. But I remember finally connecting with my boss. Um, we had to stand up. I'm, I'm in the standup. Everyone's talking about all their projects they're working on. I remember thinking, Man, this sounds super complicated, , uh, is this what's gonna be expected of me? Um, okay, cool. So I'm trying to listen, I'm trying to pick up everything so that I can hit the ground running. I get them with stand up. I really. Didn't get anything out of it. But the point of me getting pulled into the standup was just me integrating into the team and getting to know the team members. And, but at the time I didn't look at it like that. I'm like, I'm just, you know, probably a little bit of anxiety and just trying to, like I said, hit the ground running. So I got back to my desk, I talked to my boss. He's like, Okay, cool. For the, your first day, we're gonna set up your environment. Um, Let's go ahead and share a couple articles with you. I, I actually just got done with the documentation. He was super proud of it too. And so, I mean, it was pretty good documentation to be fair, but it was, man, the setup I'm used to, like personal projects, um, setup is much easier than a code base where, you know, like a dozen developers are working on it. Um, so long setup. And I started going through step by step by step, and I remember hitting a few roadblocks, and every time I'd hit a roadblock, I would try to do a little research on my own, figure it out, and then I'm like, Man, I don't want to share on my first day. With my boss that I'm getting stuck like this looks bad. I remember thinking that. And so I would take a little bit longer to work through it and then I would even ask, like I, I would ask like a developer on the team, like one question. Then I would make sure I wouldn't ask them a second question cuz they're gonna think that I don't know what I'm doing. So ask another developer on the team a different question. It was ridiculous. the amount of like tiptoeing that I was trying to do cuz I was so scared that I. Of, uh, how people perceive me and my technical abilities. It was crazy. Like it's, it's actually to, to feel this way and have these problems. It's, it's actually more common than you think. But looking back at it, I could have just reached out to my boss or asked a few questions to a single developer and like everyone was super friendly. I think a lot of developers just want you to put a tiny bit of effort into it, but then when you get stuck or if like it's very. Domain, specific word, like you need that extra context cuz don't trust the documentation, the internal documentation of developers. Usually it's an in progress thing always. And sometimes the documentation is wrong, right? And so, I had to kind of navigate like what's, uh, what I'm screwing up and what's kind of faulty with the documentation and what I'm just misunderstanding. And so I'm telling you, just ask your manager, ask another developer. It's not that big of a deal like. There are some companies that'll have you spend a week setting up your environment. Right? I worked at a startup with like a hundred employees, so you know, it took about a day, but I thought I was gonna get that done within an hour. I was never given a timeline of when I was gonna get it done. So, um, I didn't realize that's all my boss cared about, like just attempted for the day and if you have any questions, bring 'em to me. That's literally it there, and I was creating all of this ex extra chaos in my head, all this extra anxiety in my. My first day was stressful because of me. No one else, right? Maybe you can relate to that. I know a lot of people will kind of get anxious on their first days, but I'm telling you man, a lot of people don't realize this. They're scared that they're gonna get found out that there are fraud, that they're gonna get fired, and it, you know, sometimes you're, It's a big deal. To start deposition. Sometimes you're moving to a new city and it's just completely an overhaul of your life. It just switches everything up and sometimes you have to make accommodations for it. You're like, I'm really put a lot, putting a lot of effort into this. I wanna look good. I don't wanna screw up. And one thing, even talking with the cto, I, and one of the interviews I actually brought him onto my podcast. Um, he mentioned something that I think a lot of junior developers need to. companies aren't going to hire a junior developer just to fire them right away. Right, And that sounds obvious, but a lot of people haven't internalized that, that hasn't resonated with them just yet. Comedies put a lot of resources and energy, um, into hiring a junior developer, knowing they're gonna have to onboard them, knowing there's gonna be a ramp up time. And I think you gotta realize that and be a little bit patient with yourself. Understand. that as a junior entry level developer, as long as you're, you know, pretty honest with your resume, I get sometimes there people are trying to stretch the truth, but as long as you're not blatantly lying, you know, lying about, like you, some people lie and say their personal project was, uh, a professional company and they were a software engineer that got paid on. Like, that's, that's a bullshit lie that's gonna get you. Like if you do, usually most people won't get passed and look, get caught with that. But if you do make it pass, Yeah, I would be a little bit worried that, you know, maybe you misled the employer into thinking that your skill level, skill level is higher. But like that's an exceptional situation. Most people, you know, they're kind of just presenting your projects and. This is what I can do. And sometimes you're trying to, you know, add a little, um, icing on the top to make it look really good. You like really curate your present presentation. Like that's all normal stuff. And at that point it's an employer's job to like really figure out exactly what you can do. So for 99% of situations when an employer hires you, like they understand you're gonna take time to ramp up, it's okay. And even if I wouldn't have gotten my environment set, That first day, I would've had that second day. To be honest, I probably could have had a third day to set that up. And at that point they're probably gonna think, Okay, you know, Don's getting tripped up with something, let's go ahead and help him out. But that's just it. They're gonna help me out and they're gonna figure out like where I got tripped up. Right. Cause a lot of, a lot of building up junior developers is about teaching them, um, kind of a mindset and the, the right way to build their own internal process and system for debugging stuff. Solving problems, right? And I highly encourage you to be open to that process. Some developers are gonna be more candid. Um, That's another, we could do a whole video on like feedback, et cetera. But like I think most developers, even if they come off like they're too blunt and sometimes people feel that as like a personal tech. A lot of developers like want you to be a good developer on the team. They just wanna build a good product. They want it to be efficient. Um, and then some developers, quite frankly, won't even give you the feedback that you. And so I highly encourage her. Like I actually, I'm gonna be frank with my, uh, first boss. He hired me, you know, I'm still friends with him. To this day, we're probably gonna play video games. This. To be honest, but, um, he was too nice with the feedback. There's feedback that when I talked to other developers, they gave me some, like, good conventions to follow and like they were a little bit more critical and, um, was my code pretty good? Probably maybe he was right about that, but like, I remember working at my second company as a developer, they were super critical and I got a lot of good feedback from that. So, you know, you're gonna get all types of different feedback, but when you start your first day, go in, meet people. Build relationships or at least start building that bridge early. Right. Um, and kind of get a feel for like, um, just what other people do in their jobs. As a new developer, you're gonna try like, Knowing what design does, like their day to day, their actual steps they take to get their job done, you're not gonna know that you're gonna have this feeling. Okay. They kind of build a, build a design out, right? And maybe I'm gonna use that design to build out the ui, et cetera. But like, how does that actually work? Um, do they just, do they come up with the idea and they build the design? Or do I come up with the idea? I tell them. Kind of like what our requirements are and then they mocked that out and then they delivered the design. Um, what about qa? Like where do they come in? How do I interact with qa? Um, where does product come in? I remember I used to think that product was my manager. The product manager was my manager. I was very confusing for me. I had no idea what he did. And it took some time to figure out all these different departments and how. Basically integrate into my workflow as a developer and what they do and what their expectations are. And like, cuz I want, and I think you should want to be able to, you know, pull your weight with a relationship, with your product manager, with qa, with whoever else that you're engaging with. You wanna pull your weight and be able to effectively give them what they want from. To an extent, right? And sometimes you're, you'll figure out how to push back and what to push back on, et cetera, down the road. But like you wanna know their expectations. You do. You're gonna be in interacting with other people on the team unless you get a job and just like you as a developer and you have one other person that's like, it's a super, super small startup, you're gonna have different departments take time to figure out. What those departments do and how you're gonna engage with those departments. But also there's gonna be like a lot of internal dialogue that doesn't make sense. A lot of acronyms that I remember my first developer job was in the health field, and I'm learning all these health field acronyms that I'm like, I have no idea what this is. And so I would literally say, What is this? And. That that was super helpful because if I just kept my mouth shut, I would've been so lost. It would've taken me a lot longer to figure out what they're talking about. And I've learned as someone, if I don't know the answer, just ask. I don't know if you've gone through a coding bootcamp or you've talked to other developers and you've been scared to ask that question. I'm telling you, everyone else has that question that's at your current. If you don't understand something, it's gonna take you a lot longer to ramp up and be able to actually do your job effectively and grow as a software engineer. If you don't ask that question, just ask. People want you to ask. If you don't ask people on that team, they're gonna assume, you know, like you should have probably learned that in traditional education. Um, but a lot of people kind of float through traditional education. They don't ask questions for whatever reason. Right. But like a big lesson in just learning things is ask the question if you have it. Um, especially with like these, um, internal definitions that, and kind of just the internal culture of the company, you're not gonna know that, right. I, I remember like first day I was just setting up my environment. That's it. Super basic. And when I look back at it, like that was a dream to be able to do that and spend all day it. I, But you know, after that, you know, you're slowly gonna pick up bugs, you're slowly gonna pick up features. It's gonna take time. Every company has their own timeline with the ramp up thing. Um, But I, I just, I wanted to create this video because I, I feel like so many people are scared of this first day. They're scared of actually landing that job and getting caught as a fraud. They're scared that they're not going to be able to provide value and just get fired. They're scared that they're making a big transition in life. Right? And what if it fails? What does that failure look like? A lot of people see that failure. I mean, a lot of people see it as not getting that job. And I always say like, If as long as you don't quit, you're eventually gonna get that job. Most aspiring developers don't get that job because they just quit it, you know? And that's due to a lot of other things. But land that first job, get to know your team. I wish I would've done that. Um, So that's kind of my experience. I, I really don't think it's valuable to go into like weeks and weeks and what that looked like at my first job. I think that's a different topic is every company is gonna have a ramp up time that's a little bit different, but just know solely you're getting introduced to bugs and getting introduced to features and you're exploring the code base. First week you're gonna be diving heavily into the code base, just trying to figure everything out. I highly recommend that you start with like a super minor bug. You'll play around with it once you get your environment set. And then just kind of see if you could try to spot that bug, because you're also gonna be navigating the actual app. Try to use it so you understand it from a user side. This whole process, it takes a long time. Give yourself time, be patient with yourself, um, but also talk with your manager and get realistic expectations for like how long this process is going to be. Ask, hey, you know, on average, um, how long am I gonna take to set up my environment? On average, how long is it gonna take to even be able to t tackle some basic bugs? Um, as a junior developer, you're gonna have those questions. You can ask other engineers on the team, but um, It. Those questions are okay, and they will be answered in time. Be patient with yourself. Now, my second position as a developer. Um, I remember my manager, I remember basically kind of just being told to, you know, meet some people on the team. Right. Did that again. So this is like, I worked at my first position for a year and then I, they started transitioning at a WordPress, so I moved on to my second position, which it was heavy react stuff, heavy job script stuff. And so I remember just being told, like, navigate the code base, you know, and I, I knew this whole process again and I was able to do it a little bit faster, but for my second, I just dove into the code base and I try to get it up and running and I would break stuff and play with it. And then, you know, once it would reload and I would see a feature broken, you know, from the user side. obviously not in production in the dev environment, but I just played around with that and then eventually my manager would kind of just, he'd take me into, um, a room and he would provide tons of context around some of the more complicated concepts. Cuz I think one thing like this is true for a lot of different developer positions. You're gonna have people sit down with you and explain how the features are implemented, some of the conventions and kind of just the giant flow of data and how everything. , um, integrated together. So we had several meetings with that, but he was pretty busy. And I think the biggest progress that I could make was just exploring the code, trying to break things, even trying to solve some really basic bugs in the beginning. And if I didn't solve them, okay, but the attempt to do so allowed me to explore deeper and deeper into the code base. And that's what I learned. Like that's probably one of the best things that I can do, mixed with, you know, Senior engineers and my manager providing me some extra context around the app. That's how I'm gonna grow as a software engineer. That's how I'm gonna kind of hit the ground running for the most part. Right. Um, and then just, I actually took, no, I didn't take enough time. It took me a while to learn this lesson, but like I still did attempt to create those bridges with other departments and I, I realized with my second, QA does diff or things differently here. Um, design does things differently here. The engineering team does things differently here and, um, that's gonna, it's gonna vary across different companies. I think the best thing that you can do is just, just listen. Talk with other people. Be open to feedback. Cuz the more open you are to feedback, like the engineering team is gonna slowly introduce you to all the different pieces, the moving pieces of their process, of their team. Um, just be open to it. Listen, understand it might be a little bit different than what you're used to. And try to understand why they do it a certain way. And I would even like my first position into the second. I'm like, this is different. We did it this. In my last company, I'm really interested in why you guys chose this way. Can you explain it to me and learn about that? Right. These conventions, these processes exist for a specific reason and sometimes it's very, , it's very specific to the problems that company and that, or even that team faces versus your last company or your last team, right? That's why it, like a lot of these processes can just be altered quite a bit to where it's like a very different process. And I think it's important to try to understand why it is the way it is. Um, but the, yeah, I jumped into bugs quicker. I jumped into features more quickly. Um, That was pretty much it. Then I kind of just hit the ground running and, you know, then it evolved a little bit differently than my last company. And I was actually doing heavier feature work, a lot of more JavaScript work. And then my third company, um, that was definitely an upgrade in position. The expectations were much higher. Um, and I, I was pretty much expected to hit the ground running pretty quickly. And it was, I wouldn't say it was a sinker swim situation. I still feel like I was cod a tiny bit. Um, I feel like I was coed the appropriate amount, but it was very minimal and I got to dive into the code and I got to meet other people on the team. And I actually did a better job initially with that. But then I kind of, I think I kind of pulled back later on. For a variety of reasons. Um, but I was, I was really honed in and focused on the code, cuz in my mind I'm my third company, my mind was just in another place, so I was moving more slowly and I was, I, I don't feel like I was as productive, but that was like a, that was a personal situation either way. Team was friendly. I remember, uh, someone being let go on the team, so like she was going to, I was gonna work with her to like build some pretty good features out and then she left. And so I kind of like it, It was a bit of a sink or swim situation, which I love. I actually realized I really do love those situations, but, um, I, that's startup culture in general, but yeah, it. I almost feel like the process was almost the same for each company, but that ramp up time was reduced and the expectations were just higher for how quickly I would hit the ground running. And the process was different for my third company as well. And, um, I worked with a good team, very smart people, and each company I worked with very smart people. And that's, that's the other thing, um, I feel like, or I felt like in the past, I actually, my imposter. For development work has gotten so much better. I know where I stand and I'm comfortable with it. Like I still have a lot of room to grow. I would, I, I still have a lot of room to grow, but I don't, I don't feel that anxiety anymore and learning something new, I'm very confident I can learn it and I'll figure it out. And I, I think a lot of my conventions make sense and I'm able to explain those conventions. Um, but in the beginning it's super hard to. . Assess yourself. Assess your growth. I remember thinking, am I growing fast enough? I remember talking to all the engineers on each team and each company. I'm like, These are brilliant people. I remember thinking, man, like why am I on this team? Why am I getting paid this amount of money? Um, these are really brilliant people that I'm working with. I feel like I'm not even on the same level as some of these people. I remember feeling. I don't know where that came from, but over time, with each company, my perception of them, they, they were still brilliant people, but my perception of them lowered because I realized I was putting them on a pedestal. And my perception of myself and what I could do raised, and I found that I actually was more equal to their skill level and I could contribute with them. Right? And so I think that was part of my problems. I put all these engineers on pedestals and I don't think it helped me, and I don't think it helps a lot of people. I think you have to realize all these engineers, even senior engineers are human. and some of the best senior engineers that I worked with were actually open to my feedback. Or like, they would, they wouldn't get impatient when I'm like, That doesn't sound right. Why do you do it this way? And I would have, um, an engineer that I remember one for my second company, um, I'm just gonna call 'em out, Dan. We would have constant conversations about conventions and kind of just the right way to do things and he was. I, I remember he was always willing to, he was even willing to argue, but it was always with super good intention. And he would like have a conversation like you were his equal. And I, he was much more senior than me. He had a lot more experience than me, but he would still treat me like he valued my opinion. And that's the kind of team you want to aim for, and you can kind of gauge that in the interview and feel that. And the way, like, and I think you should, I think you should put the effort into that and what kind of, um, you know, what you can even ask engineers that you're talking with in the interview, what kind of feedback they give and how they give it and what they care about. And, um, Like you just talk with them, have a normal conversation, ask them like, what's your opinion about this certain convention? I've been doing it this way, et cetera. And like, you know, if you disagree with them, like you could disagree in a dis uh, in know, not, I was about to say disrespectful way. You can disagree with them in a respectful way, in a way where it's challenging their. Their convention, their perception on things, and you can kind of poke it a little bit to see why they came up with that opinion. You can get a feel for like, why they believe a certain convention. You could even challenge it in a different way. Like, okay, now I understand your process. I, I understand your thinking, but, um, what about in this situation? I remember encountering this problem in one of my personal projects, like granted it was a personal project, but like that convention, if I applied it here, it might not have worked. Um, or I kind of feel like there's a better convention or a better way of handling this data. Um, I'm just curious what's your opinion on it, right? And so when you get a developer that's across the table from you, like you can kind of see when people are thinking and considering your opinion, and if they're willing to do that and just acknowledge it, even if they disagreed, that's okay. Like, you know, a senior engineer is gonna have a lot more experience than you. It's okay, like you're gonna find that they're gonna challenge your ideas a lot more. And that's, that's okay. But if. If you can see that they're willing to think about it and consider it. I think that's a really good sign that that's an engineer that is going to treat you with respect, that's also has some humility and you're gonna feel like you're talking with someone else and kind of working together towards the same problem. At least that's how I would go about assessing whether I'm gonna be working with an engineer like that. Um, different company cultures are very different, but I feel like that's something. Assessing in the interview because that's gonna help you grow. Uh, cause I know a lot of junior developers, it's very easy to take feedback personally. And I think a lot more engineers take feedback personally when they don't feel like the other person has good intentions or they're being judgemental or like, you know, there's kind of a power dynamic. And I think the more you can normalize that a little bit, understand that they're still gonna know a lot more than you, but they're gonna treat you with respect like you're on the same level. I think that's a really good dynamic to aim. Um, yeah, this is a bit of a rant and I kind of just wanted to share my random thoughts with this, so hopefully this helps. Um, I think my main message is my imposter syndrome. Created so much trouble for me. My anxiety around getting fired and especially when transitioning to a new career and I was about to like fi with my first position. I eventually found my first apartment in Chicago. That was a big move, big investment contract, a year long contract at a sign. Like a lot of this is really scary and you wanna make a good impression. I find that if you can just go in, engage with people, have a good healthy conversation, be humble, be open to learning, but also willing to speak your mind and, um, challenge things in a respectful way once you feel like you have enough information to do so with the mindset of just coming to an actual, um, with the mindset of like trying to gain more knowledge from that interaction or. Yeah, I think just humbleness and being willing to speak up and ask questions. When you have those questions, I think you're gonna have a good time. I think you're gonna find that you know a lot more than you think you do. I think you're gonna find that the employer hired you for a reason and they're paying you a lot of money for a certain reason. I think extremely few people are actually frauds that make it in. and managers want to work with you and keep you. And I think it's the attitude that you go in that matters. So the more you can do to alleviate that anxiety and understand like you actually are valuable once you can sh you know, get that mindset. I think you are set. I think you are actually. Heading in the right direction, you're gonna grow as a software engineer. Your career is looking successful. And I don't, I, I'm essentially saying, Don't worry. Which is kind of, it feels kind of like, um, over simplistic, but it really is that simple. I think you have to trust the process a bit, and I think you have to trust that you do provide real value. If an employer hires you and pays you that amount of money, have confidence in yourself. Um, Yeah, that's it. I have nothing more to add. I feel like I'm just ranting at this point anyways. If this helped, let me know. Um, I am happy to create more videos that, um, allow you to overcome in Imposer syndrome. Cause we all face it. It's a very real thing and it, looking back on it, it's always silly. , it always holds you back. It doesn't need to. And I think it's okay to be little. Just accept that you're gonna have this imposter syndrome and be like, That's what it is, right? But I'm just gonna go in today. I'm gonna have a good day. I'm gonna meet with the team, I'm gonna work on features. I'm gonna do the best that I can. And it pretty much works out almost all of the time. When you have the mindset that I talked about, you just go in with that mindset and do your best. Um, it usually works. . Now there are, there are variables that can affect that, but like most of the time it works out. Uh, yeah, that's it. If you want me to talk about imposter syndrome more, let me know. Um, and by the way, if you are listening on the, the podcast, or even if you're watching on YouTube, you know, feel free to reach out with comments. Uh, you can comment below on the video, but we'd love to have you in our Discord community. It's completely free to join. The link is in the description. Feel free to. And, um, just engage with other aspiring developers. I think you'll realize that your, your worries are pretty common and sometimes it just helps to talk to someone else that has those same worries. So that's it. Um, have a good rest of your day and see everything.