I will start out by saying that these stories don't apply to me personally. In my 15+ years as a software engineer, I've been fortunate enough to not be let go from any job. But I have known several developers who were let go, for a variety of reasons. And this post is about them mainly.
You can learn from their mistakes in order to avoid such things for yourself in the future. Because (almost) all of these situations could be avoided to some extent. Most of these are pretty obvious, but still worth discussing. Because there are things that you can do avoid these situations going into the future.
Consistently missing deadlines
Everyone is going to miss deadlines in this job at some point in time. It's just a part of the process. When you have 2-3 people in different departments, with their own unique needs, and their own unique ideas as to how things work, you are going to encounter an abundance of bugs and errors as you try and code what each person requested.
And that means, you guessed it, that you will miss deadlines. But ideally, as time progresses, you'll get better and better and the chances of being late delivering a project go down drastically.
But what happens if month after month passes and you still have yet to be on time? And what if a year passes and you still can't quite come in on target?
Typically that's when it becomes an issue to a company. Because often times your missed deadline, means that somebody else will inevitably miss theirs as well.
More often than not, the company will do everything that they can to offer some form of assistance in order to prevent this from happening time and time again. And most of the time, this works. I've sat down with plenty of younger developers for hours on end in order to ensure that they can hit their hard deadlines.
But sometimes, regardless of how many resources are available to a developer, they just can't quite hit that next mark, for whatever reason. And eventually, to save the rest of the team, these developers have to be let go.
Not an easy choice for anyone involved, but it happens.
You lied on your resume
This one needs some context, because everyone lies on their resume to some extent. The kind of lying that I am referring to though, is the kind where you have zero idea what that thing on your resume means.
I worked with a developer once that was freshly hired and seemingly still new to web development. But they claimed to have known React, Express, Node and Postgres. Enough technologies to for sure get hired at a small to mid level software company.
This person even had a fantastic looking personal website and enough side projects to go up against any mid-level or senior developer at this company.
But the problem was that for weeks after being hired, that person couldn't even get past the first step in his first assignment. Their JavaScript was that of a someone who had just heard of the language and there was no React in sight when looking at their code. Clearly something was awry here.
Developers even took time out of their own schedules to sit down with them and help them out in some capacity.
After about a month though, little to no progress was made and the issue was escalated to higher management. After some investigation into the issue, it turns out that this developer had used various online templates for their portfolio, where essentially no real code was written by them.
Duplicate websites were found with the exact same design, layout and sometimes even copy. Which confirmed that this developer really had no business working on a full-stack React application.
Like I said, everyone lies on their resume. If you aren't a master at React, but you know it to some level where you can pick it up quickly, there really isn't too much of an issue. But if you've never really written a single line of React and you get hired to do it, odds are you will waste alot of peoples time.
My rule of thumb is to really just focus on what you do know, and to leave out everything else from your resume. Because if you get asked about that cryptic topic that you kind of, sort of, heard of, your broken answer full of hm and ums just won't do and it might definitely hurt more than it helps.
Failing code reviews
In order to keep quality standards, many tech managers will perform frequent code reviews, in which some portion of your code is put under the microscope for peer review. And typically, these processes are pretty casual. You might hear a few pointers on how to better write certain things for the next time, but usually nothing more than that.
Sometimes, bigger issues are found with the code however. This can include problems with the overall architecture or even worse, security issues. But this is also a part of the code review process and is to be expected.
The issue really arises when developers fail to implement what they have learned and they continue to write the same unscalable and unsecure code over and over again. Because that potentially can cause liability issues for the company.
As mentioned though, I've rarely seen this happen in the corporate world. Most developers stay late and come in early to address any issues that they either encounter or produce in their code. I have done that myself countless times during the course of my career.
But on a rare occasion, there have been developers who "accidentally" continue to make private server side passwords available through a console log for the world to see. And that might be either because of their lack of knowledge on how client-server architecture works, or because they have relatively unsecure ways of testing the website.
In either case, doing something like that can definitely bring attention from management and put your job on the line.
And lastly...
I've rarely seen a developer get fired at any corporate job that I've worked. In fact, I can count the number on one hand. But it can happen and it isn't a fun time for any party.
The company loses a developer and the developer puts their career at risk.
So don't miss too many deadlines, avoid lying on your resume and if you make a few mistakes in your code, clean them up and make sure they don't become a frequent occurrence.
And that's really it. You can still delete an entire production database (as I did), and keep your day job. Just don't do it too often.