Breaking Into Software Engineering: Part 3 - Starting Your New Job!

hey thanks for tuning in and welcome to the third and final video in this three-part series about breaking into software engineering so the first video that I recorded I was focusing on how you go about your application process and the things you want to focus on so that you can start to get noticed by recruiters and how you can go through that the next part was really about interviewing so if you think about now that you've done your applications and you're actually getting to sit down and talk with interviewers what do you need to focus on for that what do you have to practice what's the interview process like what should you look for and even if you compare these two things they're very different sets of skills that you want to practice different things you want to focus on right making your resume stand out now that you've done that okay how do you stand out in the interview there's definitely overlap but I think there's really specific things you want to focus on for that so in today's video in the final video we're going to assume now you've got your your job okay so now you don't have to focus on um you know putting your applications together you don't have to focus on your interview techniques and I want to kind of compare and contrast What You Did In Those first two phases to this Final Phase um now that you you're you know in the job so um so with that said I'll jump into the material and um if you could do me a favor and like the video if you enjoy the content subscribe to the channel That would be awesome it lets me know that you're enjoying this content you want me to make more so okay let's assume that you've now got your job awesome work um you know it's it's really not an easy process to get to this point but now that you have it what are the things you should be focusing on what should you be doing so I have a couple recommendations to start and they're kind of General um but I I like to encourage basically everyone to do this if you're new at a company or you know especially Junior and earlier in your career so the first thing is that you're going to be spending time doing domain learning and if you think about software engineering right so software engineering is applicable to so many different Industries you could be working in agriculture you could be working in automotive you could be working in finance like so many different things and that's going to involve domain learning right so keep that in mind that when you join a company and you're starting to do work you're going to be spending time doing that a lot of companies may have some expectation that you have some of this knowledge beforehand but many companies will also acknowledge that given that software skills are generally applicable across many different domains they expect that there is a lot of ramp up time especially for more Junior folks so do anticipate that you will be doing this kind of learning on the job especially a lot in the beginning just to get ramped up and with that said the next part is a really ask questions and it sounds maybe kind of obvious like yeah you're new you're going to have questions to ask but I mean it like actually ask the questions right so um I'll explain a couple different aspects of this so the first part is I think a lot of people that are new are afraid to ask questions and you know I don't blame you it's you know it can be really intimidating you're the new person there's people with lots of experience you don't want to bother them and take time away from them this is a I think further compounded if you're working remotely right um you're like you can't really gauge if you're you kind of feel like you're just bothering people by interrupting them if you're shooting them a message that kind of thing but um you know I I do really want to encourage you to be asking questions um it's number one how you're going to learn um and hopefully the place that you're working at has kind of created this safe place for you to to be able to ask questions right so that the more senior people can dedicate the time to answer stuff for you uh maybe they've paired you up with like a sort of like an onboarding buddy or something like that right where you have someone you can reach out to that's maybe not your manager um maybe it could be your manager as well that you can kind of go to and ask questions but hopefully they create a safe place for that and the second part to asking questions is that and I think a lot of people I don't know like it's an oversight where yes asking questions will hopefully get you answers so you can do things but the other part to it is that when you're a new person you're actually coming in with different perspective right so I'll give you some really you know simple examples maybe maybe one example is you know you're putting up your first set of uh you know pull requests and code reviews and you're going through the process of that and you're like hey like um you know why is it that um these tests take um you know 12 hours to run in our our continuous integration process or um I have all of these build warnings and like maybe that seems concerning to you like you have genuine questions about this kind of stuff um I think it's a really good opportunity to kind of surface those different perspectives and be able to ask people about that right um I've definitely seen situations where you know maybe more tenured people can be like oh yeah like um you know the warnings or something like here's the history there here's kind of why it's at that State but maybe they're going but you know what it's been a while since we talked about you know situation X where we couldn't resolve the warnings or we did say that we wanted to kind of start reducing those maybe I'll take a note and we should you know bring up that conversation again or the tests take too long and you know if you're not being vocal about that kind of stuff maybe the people that have been working there for a while are complacent about it right um and that's kind of crappy they're just used to it but maybe there's an opportunity to improve that um so it I don't mean go in and ask questions and pick apart stuff just to to blame people for why things are a certain way but I think if you go in being genuine and trying to seek to understand um and and you present yourself that way I think people will be you know more receptive to trying to help educate you on you know why things are that way but it also opens up some doors for people to start thinking about these particular situations and hopefully come up with ways to make them better maybe it's things I haven't thought about in a long time right or just a different way of looking at it you could be the person that ends up kind of helping that okay so those are a couple of really basic things really General um and I I think it would be worth kind of talking through probably what your first set of projects would look like um I think it's pretty typical that uh new folks when they're starting up generally assign some lower like lower risk type of things that you can contribute to and this is really just so you can do a little bit of exploration in the code base you know you're not going to have all of the the knowledge of where all of the different parts of the system are and that kind of thing and you're still maybe trying to feel out how you need to be writing tests and what types of test coverage there are and so really if they can scope down the area that you might be impacting it's it's kind of setting you up for Success like if you make a mistake it's not gonna you know blow up everything that the company's doing that kind of thing so this generally looks like um smaller bug fixes right fixing bugs is important um it maybe isn't the most exciting thing but it's important to do uh and if it's scoped down narrow enough it's something that you can maybe go researching through the code figure out how some specific areas work and then actually contribute a fix which is awesome and if it's not a bug fix it is generally a small feature area right so it might be about trying to it could be like you know adding a new dialogue in a you know a user like facing application it might be enabling some API feature um that's maybe been asked for but hasn't really been a priority that kind of thing so you might be delivering that so it can help some people but if it's not it's not like a mission critical type of thing um then I would say generally these types of things probably don't feel super exciting but they're meant to be kind of like a stepping stone learning opportunity and if you do well with them and maybe you have to do well at a couple of them generally will give people the confidence and you the confidence that you can work on a little bit more complex stuff so the other thing that I wanted to point out about this if we start to contrast some of the other videos and if you can go watch those if you haven't um where I focus on the first two phases of breaking into software engineering like a lot of that focused on the the more theoretical side of programming right like if you're gonna go practice um your algorithms and data structure questions and your system design stuff a lot of that is focused on I don't know like these particular scenarios that you can get quizzed on and I think that there's something to be said about doing that kind of practice work so you can you know really nail those first two steps but when it comes to reality like I would I would certainly argue in my software engineering career I I don't sit down on a daily basis and say like hmm which which is the most you know perfect data structure to use for this situation if I think back to this you know Elite code question or um oh yes this is exactly like the the micro Services System design question where there was this little trick that we had to look for um it it just doesn't really end up flowing that way um I think those are just really contrived examples that you end up practicing and don't get me wrong there's there's value in those in those scenarios there's value and understanding the data structure but I I would argue that the way that that stuff is presented in the real world when you're at your job is just not that set up for you right so yes if you pick the wrong data structure that you're using in some algorithm that you're designing yes maybe it's not as performant certainly I'm not saying that's not the case but um you know it's it's not like you're gonna you fail the interview it might go up for code review and someone's like hey you should try using this other thing right like you didn't just fail it might have might be a recommendation for someone else to to go fix it or perhaps no one notices it because it's not actually that big of an impact in the area that you're contributing to so it's just a lot less theoretical um a lot less contrived examples and a lot more um what's the current situation we're dealing with um and just a lot more I don't know like Hands-On that way I would say so that's just a a big difference and I think that people that hyper focus on you know the theoretical um practicing of those questions can often struggle a little bit if they don't kind of have some of these other more what I would call like real world practice so with that said um when I talk about like real world practice the next thing I wanted to kind of you know bring up is that you're you're now working at a business right obviously so you've been you've been hired somewhere you're working for a business um part of a business and a big part of it is that there is some type of you know income for that business right there's customers paying for the software the services that you're helping create and that means that there isn't infinite time to go solve problems and that also means that time is part of a constraint that you have to deal with so um when it comes if you reflect back to like you know trying to practice programming questions and you know trying to make your your application uh for your job seem perfect before you submit it that kind of thing like there's going to be other business constraints that come up time is certainly one of them there might be many other things that kind of get introduced um as you're working on different projects but there's going to be other constraints that you have to factor in and that will mean that if you were thinking about designing some micro service architecture um from your system design questions or your which algorithm is the most optimal to do something there's going to be different constraints that you have to try and interpret those now and apply your knowledge and if you practice those other things great maybe that makes it easier for you but you have to apply your knowledge with these new constraints so you can keep making progress the point that I want to drive home here is that there isn't in many places there's not an opportunity to to basically to sit back and try to create perfect code a lot of people will hear about um I guess like a thing that's that's called the 80 20 rule um people have different ways of kind of saying this but um you know one way to look at it is like doing some doing 20 of the work to get 80 of the value kind of thing right like this becomes like a real thing where you you don't have um you know all of the time in the world to go make something perfect sometimes it's good enough because it will allow you your team and the business to get to the next phase at that phase yes if things are continuing the same direction yeah maybe you can go back and improve that thing a little bit more but what's very common is that in the real world things change right you might pivot as a business your team might have a new priority that comes up and if you would have kept taking the extra 80 of that time to go get the last 20 percent of that value you may not have afforded yourself this opportunity as a team to be able to Pivot to the other thing right so I bring this up because I think if you haven't had experience in the industry a lot of people aren't used to this it feels uncomfortable to be like I didn't get all the time to make this perfect um or if you have to rework something or scrap something people are like I just wasted time um but things change right if you can learn from those experiences maybe you created a prototype of something and it has to be scrapped maybe you're the feature that you added was a stepping stone so that you could onboard customers get some feedback and now go on to the next phase right all these things are they're real scenarios and I think keeping that in mind that it's not just about kind of sitting around trying to draw up the perfect algorithm all the time um will be helpful to keep in mind um one final thing I kind of want to touch on I'll keep this video hopefully pretty short is that um you're going to be collaborating with people now right in in most places um you'll be working on a team on projects with other people um maybe the you know the in the beginning the bug fixes and the small features you're doing they might not feel like there's a ton of overlap with all your teammates and stuff and of course this can look different in other places but you are going to be working as part of a team most likely and working on a team means that you're going to be dealing with different personalities right so this is just another like thing to layer into into software engineering right it's not just um trying to design an algorithm that solves a very particular problem it's now designing the algorithm that that fixes the problem or meets the you know has a solution to a a different problem it's adding in the constraints of the business so maybe it's time maybe it's different other things going on in the business that impact your design and now it's also working with other people to make sure that your what you're creating will integrate with um you know the team Vision it is up to the standards that the people on the team have um the design philosophy um you're going to be getting feedback from those people like all of these other types of interactions get mixed in and I think if you're not prepared for that kind of thing if you're not thinking about it it might be a bit of a surprise um it might not feel comfortable um and you're probably not setting yourself up for Success if you're not trying to factor in ways that you can optimize collaboration right so I want to want to kind of throw that out there it's not just about how do I become a better you know coder per se like how can I just practice literally coding better and better I think part of being a software engineer is working on teams effectively with other people so try to keep that in mind as you're starting your journey because I think if you prioritize some of that early on and make it you know part of your your focus um you'll be set up for success okay so in summary all three videos right from from start to where we're at now first video we're really diving into how you go through your application process and what you want to focus on there right so startups versus maybe bigger companies maybe different ways you get identified trying to think about your application from the perspective of the the hiring company right so that's part of it then you're going through interviews now that your applications worked and the some of the things that you might have to encounter there and how they vary from Big Tech to startups different types of questions that might get focused on those were some generalizations I gave before and then you get the job awesome so congrats and now that you're you're at the job like what should you be focusing on right so I kind of brought up that you might have some smaller things that you're contributing to like bug fixes small features you're going to want to prioritize learning um and asking questions asking genuine questions not to criticize and just you know um like stir the pot I guess um and then the the last part I was trying to bring up is that around some of these other more real constraints from the business and the fact that you're going to be collaborating with people so hopefully this helped a little bit it's a little bit of insight into kind of how you can take some steps um to break into software engineering and how to start making progress once you've done that and again if you like this video thank you so much if you can uh you know like it on YouTube and then subscribe to the channel if the content is valuable to you and I would really appreciate that so thanks and take care