In today’s post I’m going to tell you how to not get fired from your first job as a programmer.
This is because the last thing you want to happen is to spend all this time and effort in learning to code only to get fired after a couple of weeks in your first job.
This has happened to people and it sucks. It’s not fun.
If you’re new here by the way I’m Peter Mukundi. I’m a mentor and coach to aspiring developers.
So, if you’re looking for content for yourself and you’re looking to get in development, I highly recommend checking out my blog from time to time as I offer actionable tips to help you land your first job.
Alright, let’s talk about how not to get fired.
My basic advice here is pretty simple but before I give you that advice, I want to talk about the layout of what I see as far as what you’ll potentially get hired into.
There are two types of companies really that I see.
So, the first company that you don’t really have to worry about getting fired at least from what I’m seeing is usually a bigger company with established HR department.
Meaning something like a separate HR department.
Also, if the company has a very stringent process for hiring developers. In other words you have to do multiple interviews, a lot of coding challenges and white boarding at those companies.
Because that process is so good at hiring people, they’re going to know who you are. They’re going to know pretty well from a behavior perspective who you are.
They’re also going to know from a technical perspective or technical abilities where you stand.
So, there’s going to be very little chance that you’re going to show up after a couple months and they’re going to be like!
“And here we thought you were the perfect fit for that position!” At such companies, they’ll have known you’re not that skilled at software development in the very early stages of interviews.
So, if you get hired into a company like that, I think there’s not a ton to worry about.
As long as you don’t mess up and like show up drunk to work. Or you just don’t show up to work at all.
That’s on you!
If you go to a smaller or medium-sized company who doesn’t have that HR department.
Or doesn’t have the long interview process or doesn’t have a real stringent technical process for filtering out people who just aren’t going to be technically skilled.
That’s where the risk comes in. They can let you go after a few weeks or a few months because it is very hard to asses talent.
Is super hard to assess skills as a software developer. And companies throw millions and billions of dollars at this point to assess technical talent and they still can’t really necessarily figure it out.
For instance, in my previous companies, they just focus on the behavioral aspect of it and maybe some take-home coding homework to assess that candidate’s abilities.
Then they just go with who they like.
And that’s really dangerous because the company can find out three months in that this person really doesn’t know what they’re doing.
And once they find out that you’re not that resourceful, that’s where the risk comes in.
If you get hired by a company like that, that’s where the risk increases.
As far as like how do you not get fire at the end of the day, you have very little control over things.
You can control how much you study. How much you work. And what attitude you bring in but at the end of the day they could still fire you even if you’re a very hard worker.
My simple advice from what I’ve seen from different people who I’ve worked with and different people who I’ve seen get fired from both of these companies is very simple.
Basically, you want to be the type of developer who is resourceful, who is somewhat self-reliant and not helpless.
And the only way that I can really see people cultivating that when they’re learning to code is to really focus on building project after project.
Getting comfortable with doing things outside of the scope of a tutorial, a book, a course and even class.
And really constantly creating projects to the point where they’re very comfortable with ambiguity.
They’re comfortable without a clear direction and things. Meaning they don’t need to have somebody standing over them telling them what to do.
What happens a lot of times when you go to a company for the first time is that they’ll start you small.
They’ll give little tiny bugs to work on but as you progress, they’re going to give you more and more challenging things to work on.
They’re going to have you build new features potentially, and if you’re not comfortable with being handed something and kind of figuring things out, it will be a nightmare.
I recommend having at least a structure, how to figure things out because you’re going to need help in the early days.
If they hand you something and you don’t know what you’re doing. You don’t even know how to ask questions for help.
That’s where the risk increases.
They’re going to see you as this helpless developer who needs tons and tons of mentorship and support.
And that may not be what they’re looking for. Some companies are very supportive but others they want people who can produce early and fast and have that fast learning curve.
What I have seen separates people is, people who in their process of learning, they focus on building projects. They get very comfortable getting frustrated.
I don’t care who you’re but it sucks when you’re stuck on a bug on your application, potentially days at times only to find out it was like a spelling error.
But when you’ve gone through that process more than one time, more than a few times, you start to understand that it’s pretty typical to get stuck.
So, when you get thrown into an environment like that at your first job, you’ll not start crumbling under pressure.
You’ll have been used to it.
What I’ve seen from some people contrast that. They love the academic side of programming.
So, they love the theory and tutorials. They love being walked through things.
You can absolutely increase your skills that way to a certain degree.
But somebody who leans heavily in that side when they get to the first job they are likely going to be overwhelmed when tasked with building something.
There will be no tutorial or course for that and so it will be overwhelming and the pressure will be too much.
The way I look at this is, you want to put yourself through the fire now, to bleed now and practice so that when you go into battle it’s not that bad.
You’re not going to freak out when it happens.
You want to put yourself in challenging positions before you get hired so that way it’s not that big of a deal.
If you’re in the process of learning something, focus on building projects.
Of course, you need to have the academic side of things and you also need to have tutorials to help you through but you really should shift your focus to building projects.
If you get stuck doing that, it’s absolutely normal.
That’s the life of software developers. Problem-solving and working our way through challenges.
I hope this simple advice helps you, sets you apart and gives you the best chance of staying hired at your first job.