From Hired!… to Fired! Avoid these 2 Developer Career Death Traps
As an engineering manager I’ve had the privilege of promoting engineers on my team and offering people their first role in tech. It’s one of the most rewarding parts of the job. Besides all the meetings of course, that’s the icing on the cake 😉.
Unfortunately, I’ve also had the not so fun task of promoting people OUT of the team 😬. I’ve also spoken to a few junior developers who finally landed their first role…. then got fired.
We will explore the top 2 reasons I’ve seen people get canned and what you can do to avoid this unfortunate scenario.
Most of the time, it’s not your fault.
You can’t always avoid the chopping block. You can write great code, meet all expectations and still find yourself out of a job. Stability is a myth.
Layoffs. Bad managers. Company mergers. Asteroid destroys the office.
While you can’t always avoid these situations, there are 2 ways you can decrease your chances of writing code for free… again.
Grab my Ultimate JS Guide. LinkedIn stuff. Unit testing stuff. Side project stuff. All the stuffs. STUFF. Click here and steal it.
Step 1: Level Set
The single most common reason I’ve seen developers get “let go” is because there was a mismatch in expectations.
- No 90 day plan.
- No manager feedback.
You think you’re doing well but the team is silently frustrated.
Your notice to leave the team comes out of the blue… to you at least.
Your manager isn’t some sadistic bastard. In most cases at least. The reason they didn’t confront you or offer feedback is because they are human. They just want to focus on their work and avoid conflict. It’s not right, but it’s reality.
On day 1, you should set some practical milestones with your team lead or manager. What does success for you look like in the first month or two on the job?
If they don’t give you a plan, make one yourself and present it to them.
For a junior developer it might look like this:
Days 1–30: Get all repos running locally on machine and understand code review and deployment processes. Get at least 2 small features into production.
Days 30–60: Participate in an on-call rotation and learn process for critical incidents. Understand the full software development lifecycle. Be able to fix small bugs with little help.
Days 60–90: Take on a mid-level difficulty feature and deploy to production. Contribute to technical discussions.
Once you’re aligned on what success looks like, it’s no longer a guessing game and you have proof that you’re where you should be or have an idea of where you need to improve.
Step 2: Brag
You launched that critical feature, onboarded the new dude and helped the juniors on your team get their work done.
You feel pretty damn good when it comes to yearly review time.
You’re blind-sided when you’re actually the one who’s cut from the team when they do a 10% reduction to help the CEO buy a new Yacht. I mean, he really needs that Yacht so you understand… right?
In some organizations, it’s not uncommon for your manager to NOT be involved in the daily activities of the engineering team. They may regularly speak to the team lead but not every engineer.
This means they see your work through the lens of the team lead or judge you on useless metrics like lines of code written and number of bugs fixed.
You have to learn to spotlight yourself… but don’t be too obvious about it.
Don’t brag about your accomplishments — educate instead.
Fixed a critical issue?
Document the fix and have a short lunch and learn to go over the root cause.
Launched a feature?
Offer to demo it next time there is a meeting.
Lastly, keep a document where you track every interesting thing you’ve done. This makes it way easier to “prove” your value to the team (and yourself) when review time rolls around.
Now you’re no longer “whats-their-name-again?” — you’re that engineer who everyone knows.
I just want to see you win.
If you’re reading this, you’re likely at the beginning of your career as a developer. I’ve made so many mistakes that I’m shocked I haven’t been fired multiple times. It took me around 4 years to learn these 2 fairly obvious lessons we’ve gone over here.
I don’t just want you to avoid those mistakes, I want you to stand out and push yourself technically and in other aspects of your career so that if you do find yourself writing code for free, it won’t be for too long.
Getting hired is the first (and shortest) step of your developer career. What you do AFTER landing the role is where it counts.
Get hired and (hopefully) not fired with Parsity.io — a coding training program for motivated career changers. OR just grab some free stuff. No judgment…. I mean a little maybe.
