I got my first swe job this past August and it honestly has not gone well. I've enjoyed it, but it is clear that I am not seen as reliable and definitely not known for completing things fast.
I know this sounds like a normal junior dev, but I mean more than a normal beginner. Example: I have now been on this team for 8 months, and I made 2 costly mistake back-to-back that is pushing back the release of a production feature by a while month at this point.
Long story short, screwed up a step I had done before in the fall without realizing. Then when it was fixed I submitted a ticket for a prod systems account rather than a QA one not realizing there would be a difference. (Just so many mistakes all in a row).
The struggles came way before this though. When I first joined I struggled to even know how to start things. I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.
This gets down to the issue. I don't think my team is necessarily the most ideal to learn on (my manager has been gone since December). The senior engineers also seem to assume I know more than I do (like the credentials above, it seems obvious there would be an account for QA and one for Prod, but I didn't know to assume that). But, the thing is though, this team isn't a bad one. I can make excuses all I want, but an experienced engineer joined the same time I did and is doing great.
I have identified some issues. I certainly didn't ask enough questions when I started and I definitely will wait around for people to get back to me sometimes rather then be proactive. I also tend to spend too long tackling an issue or trying to fix something I think I messed up rather than raise it to the team that I am having an issue. The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.
Honestly, I am a little deflated. I know imposter syndrome is a thing, but that doesn't count when I am actively slowing the team down or causing problems. I take a really long time when finishing stories unless one of the seniors is giving input. It just sucks because I did well in my CS classes and worked hard, and I feel kinda like a disappointment. Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems. I don't know anything about performance (again cause manager is gone) but if I get put on PIP because of this, I feel like I can't help but see it as a statement on my potential and ability.
I know I should just focus on improvement, but I am not sure how. Should I be writing reminders to myself to always double check everything? Should I write down the steps to every process? Its hard for me to know whats a junior engineer error and whats an error I shouldn't be making at all.
---
Second, let's adjust your expectations a bit. You're expecting to be great after 8 months. Nobody is great after 8 months.
> I am actively slowing the team down or causing problems. I take a really long time when finishing stories unless one of the seniors is giving input.
When I hire junior engineers, I expect them to be worse than useless for about 6 months (because they're contributing nothing of value, and taking time away from more experienced people who do the onboarding), and maybe to be net neutral after a year. Some are a little quicker, some take longer. And I expect them to have a senior engineer (or several) "giving input" forever. That's what it means to be junior; you aren't expected to do anything alone. (Most senior engineers aren't really expected to be able to do anything alone, either; if the senior SWEs on your team are any good, they're checking each other's work and talking through plans/designs with each other.)
> Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems.
I think I'm a pretty solid senior engineer. I've led and managed teams for a while. I was promoted from new-grad up to staff level at a FAANG company, and have consistently gotten good performance reviews and shipped solid code that solved real problems, sometimes problems that more experienced engineers had tried and failed to solve.
With that said - I've caused three production incidents in the past month. We had release procedures that were poorly documented that helped cause two of them. The third was just a silly typo bug that I didn't write a strict enough test for, and that made it through code review. The cleanup from that third one slowed down our release, and had a knock-on effect that delayed a customer-visible product launch by a week. It's a mistake I wish I hadn't made, but I'm also not going to get fired over it. It happens to everyone.
There's a famous quote from Thomas Watson, longtime CEO of IBM: "Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?"
---
Now, to get into the underlying problems - it sounds like your team/company is really, really bad at onboarding and training.
>this team isn't a bad one. I can make excuses all I want, but an experienced engineer joined the same time I did and is doing great.
Part of being more experienced is that you've seen more different things. Senior engineers are a little harder to surprise, because there's a good chance they've seen something at least comparable to their projects before. This makes them more valuable, obviously, but it also makes them qualitatively different. You're not experienced now; you should focus on becoming experienced through the work you're doing. I guarantee that that more senior new hire was useless the first couple quarters at his first job, too.
>I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.
This is idiotic on the part of your mentor/team/manager. A healthy team will have a backlog of bugs or small features that they've more or less figured out, but haven't had the time to implement - those are the kinds of things you should give to new hires to get their feet wet. If you've been there 9 months, you should probably have gotten through a starter project that's actually productive, but again, it shouldn't be anything new. If you don't feel like they can effectively mentor you, that's a problem with them.
> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.
That senior engineer should be fired, immediately. That's inexcusable. I don't care how needy a junior engineer is, or how many times you've shown them something. You show them again, teach them how to find the documentation, and do everything you can to make it so that they don't need the help. What you don't do is refuse help that they still need.
---
Finally - how to improve. Two things have to happen. First, you need to find someone who can actually mentor you specifically. This should be someone at least a couple levels above you who isn't an asshole and can show you the ropes, who is themselves reasonably well-respected on the team, and you can bounce ideas off of and who you feel comfortable asking questions. In an ideal world, this would have been done proactively by pairing you up with someone more senior to do a project together after you'd been around for a few weeks, but if that didn't happen, and you want to make this work, you'll have to be more proactive. A good manager should help, but if that feels weird, go to someone you respect (NOT the person who refused to answer your questions!), schedule a 1:1 meeting, and strike up a conversation - "hey, I saw you were able to diagnose XXX problem, and you seem to really understand YYY process - can you walk me through how you did that?" People love talking about stuff they're good at.
Second, you need to find a way to phrase the problems you're having as problems with the team rather than problems with you. You can start this with your manager (I know you said the manager has been out for... four months?... but there must be someone filling in). If you don't know how things work because there's no documentation, tell them that. If you don't feel comfortable asking questions in meetings, tell them that. I've gotten both of those comments from junior engineers before, and we took them as serious problems, and fixed them - that's important feedback, and any leader worth anything should see it as such.
Oh, and keep asking questions. It drives me nuts when anyone - junior, senior, engineer, manager, PM - doesn't ask questions. The alternative is that they'll just guess, and that doesn't do anyone any good.
Your experience is not unusual, it seems that many tech companies are terrible at onboarding not only juniors but devs in general. It seems almost like a systemic problem to be honest. Many companies are good at this but too many aren't.
I think one thing that might help is more industry focus in CS degrees. CS is great but a "year in industry" and vocational training would be welcome for many as part of their training. Data structures and so on are great but until you've worked with the plethora of tools and processes you will encounter on day one in the industry, being thrown in at the deepend will be baffling and overwhelming. CS degrees and most day to day work as a dev are very different. A practical heads up on things like cloud infra, monitoring tools and CI/CD pipelines (to name just a few things) would be good.
I will be honest if on month 9 someone asks me how to stick some code onto the integration test platform for the 10th time I am going to make a snarky comment.
Similarly, if on month 6 someone asked me how to log time or make a jira ticket I would probably be of the opinion that we are pretty far along for that kind of basic workflow not to be known.
There are limits to how long a new employee gets to be useless at everything - so without knowing which process we are talking about I would probably hold off on that firing button
My response would be to answer the question when they ask it, then wait for a calmer time and ask the process questions if you need to (or better yet, ask the junior employee's manager first):
* "Hey, it feels like we've been through X a few times now. I'd rather you ask if it's not clear, but is there something that isn't clicking for you in my explanation?"
* "I was a little surprised when you asked me about X, because that's something that we usually cover in first-week or first-month onboarding. Was it not covered then? Is there something unclear in the documentation from then?"
I feel ya. I've been there. But now what I do instead is sit down with them and have them work up a document with screenshots (if necessary). We then go back through the process using the document as a guide to fix any mistakes.
Bonus: Everyone can use the document.
Imagine thinking a company is going to fire potentially high value senior engineers for getting frustrated with junior engineers. Do the seniors need to chill? Sure. Fired? Come'on.
Pretending that underperformance is OK doesn’t help people - it’s the kind of thing that leads to them being put on PIP “out of the blue”.
Junior engineers aren't expected to do this alone, your senior engineers should be there to help you as you learn to do this yourself.
For me, it's still a bit intimidating asking questions to people 2+ levels above me, but the biggest thing I've learned is that those people want to help me. For more senior engineers, it's their job to help you: You're not wasting their time.
My first dev job came after mid-way through a PHP course in college. Prior to this, I had also completed courses in Java and C++. At $10/hr (boy was I desperate), I was hired on to replace the outgoing fullstack web dev (basically at an email advertisement spamming company).
I was supposed to "get up to speed" with my replacement within a couple weeks of being hired. It was unwritten and unspoken, but basically I was to become the ad agency's sole fullstack web developer. At the time, I knew zero front-end and the PHP that I did know was murky (5.x) at best.
I had no chance in learning enough to replace the then sole fullstack dev and quit because, I just wasn't ready at the time to absorb front-end web technologies in that short amount of time. Boss warned me that when I give a deadline for a project, it may as well be prophetic - however, I was scared sh1tless giving any kind of projection on any kind of project with me as the sole developer doing things I've never done before; it seemed to me to be absurd.
Fast forward a few years, I just couldn't land any programming/web job because my experience didn't line up with what was requested - even when I thought I was around 70%+ qualified. After a while, I got fed up with the esoteric requirements, even for junior positions. It's exhausting reading through countless job listings trying to find something that may fit. So, to this day, I just code for fun - like a locally hosted movie server that I prefer over Plex. Sorry for the ramble. I'm estranged by the industry in regards to hiring for junior positions.
I'm long past my junior days and this still bugs me. In case it helps anyone else, now I give my estimations with two [low, mid, high] qualifiers next to them:
1. Uncertainty: this is where I signal whether I think the task is well defined and we have the expertise to deal with it or not. The estimation gets a multiplier (however stupid I think the task is) when this is not low, and I make it clear that uncertainty can be reduced by either better defining the task or breaking it into an "exploratory" phase (where we try to come up with a tech-demo to get a better "feel" of that new thing) and then an execution phase that will turn it into a reality (which will be estimated _after_ the exploratory one is done).
2. Environmental risk: this signals how external factors can impact the task (e.g.: the client is complicated to work with, this necessitates collaboration from a third company that may or may not be fluid, we require key people from the team that is busy doing something else, etc.)
I've found that this both reduces my anxiety and tunes the client's expectations much better (it becomes much easier to explain after-the-fact why two tasks that had a similar estimation ended up taking wildly different efforts).
To add an even more backing to this, here are some tasks I gave to a new hire.
+ change four placeholder images for the correct ones, and learn the process to check it in
+ find out why one text element has the wrong font
+ change the favicon
This demonstrated to me that he was familiar with git and he said smart things about react so I gave him more. Your manager sucks not you, stay in there it will click in time....unless you find a better role for you
As far as actionable advice goes, it sounds like you should be documenting most of the process things you're unaware of. This acts as a reference doc for you while you do things (checklists help avoid dumb mistakes, if you find that being common), an onboarding tool for future hires, and a consensus mechanism for your team.
Hmm, by the 60th time I’ve taught them how to make a commit in git I’d probably be pretty done.
I agree with the general sentiment though.
The only thing I would take issue with is the first paragraph where you try to calm down the OP:
> Okay, first things first - take a breath. This is not that big a deal. If you're at a company that's big enough to have a PIP process, then there are two possibilities: (1) it's well-established enough to know that junior engineers aren't productive for about a year after hiring, or (2) it's completely incompetent. If it's (1), even if you actually are way below average, you still have some runway left. If it's (2), they almost certainly have enough of a reputation that you can "fail" at your current job without it really harming your long-term career path.
This way things are at least in US, is next to impossible to harm your long-term career path by failing at one job. One needs to be at least prosecuted to harm their long-term career.
OP, if tomorrow you'll get fired on the spot, in a year time frame your most-likely will find yourself better of than you are now (and, frankly, likely to be better off if you stay at your present company).
Also, unless the sprint duration is four weeks and there's no dailies, I really can't see a junior being able to delay anything by 1 month in ANY sane company. Unless you're preventing people from working, actively sabotaging things (and skipping code review processes!), I really struggle to see how a Junior Developer would be able to slow a team down like that. If this is happening, that's a huge red flag, and you're not in a good team/company. I really don't think you're the problem.
> When I first joined I struggled to even know how to start things.
That's how it is with new companies. I'm at this for 20 years and at some places it took me six months or more to unravel the massive amount of stupid code and processes before I was productive enough.
> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point
I'm a team lead and I ask basic questions all the time. Sometimes to juniors or interns.
What kind of things we're talking about? Opening a PR? Simple programming questions? Opening up tickets in JIRA? This is basic. But deciphering convoluted code or navigating convoluted processes? Using an arcane shitty ticketing system? That's not really basic level anymore. But even if it were, that senior engineer was out of line...
PS: If you think we're being "nice" to you on the replies out of sympathy, it isn't. This is for real. HN is the kind of community that would call anyone on their bullshit.
If you had to ask someone how to open tickets? Create a short doc or wiki with those instructions.
That's a good way for even a junior engineer to start producing value, for established teams they often have tribal knowledge without realizing it.
Also you'd be surprised how often basic questions actually are not basic at all, when instead people are all assuming everyone knows the answer and are too far in to ask the question.
Ideally yes. But realistically no.
Ideally there would be management available and coaching on any junior SWE, or at least you'd hope so. Realistically he may be looking at the business end of a PIP.
Ideally there would be blameless post mortems. Realistically there's no such thing, if you fuck up bad enough you're going to be shown the door.
Ideally if you're a great software engineer you would be with a company for the life of the company. Realistically, the politics and toxicity of workplaces limit the career of any employee.
A junior being able to delay a process for a month means gross incompetence from everyone else involved.
We as developers have the duty to push back against stupidity in the workplace. The labour market is in our favour, those companies should die.
> I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.
> my manager has been gone since December
> I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.
To summarize: you have no prior work experience, you're assigned tickets beyond your abilities, management is MIA, your team doesn't support you, and people make you feel bad for trying to improve.
It's not you, friend.
As a junior engineer, a lot of responsibility falls on your environment to help you grow and gain more independence in your day-to-day problem solving. Your environment is demonstrably not living up to that obligation, and they should not have signed themselves up for it if they weren't prepared for it.
I've been on teams that have been similarly inhospitable to juniors. Several of us went out of our way to provide that support, because it's necessary. But nobody higher up had planned for that need, so our schedule was impacted anyway.
It's not you. Try to look for other teams (possibly within your current company!) that are willing and able to nurture your growth. Juniors aren't independent; that's almost definitionally the difference between a junior and a senior. Cut yourself some slack, and try to expect more of your working environment.
As to your other points, it sounds like it may not be a good team for you to learn on because everyone is expected to behave senior.
For what it's worth though, I think you have a good attitude. You're willing to put in the work and learn, and you're practicing self-awareness about what you don't know and need to know. You'll be fine. Just try to interact with as many senior people as you can and ask questions. Don't be a jerk when you start getting some knowledge. Keep learning even from those people who are less experienced.
He was hired behind my back, and began a React project using some "admin template" that we didn't need, and now it's a dirty mess. He had a wedding+honeymoon planned before he started with us I guess, which took him out 2 weeks shortly after starting. But he also missed half days of work whenever a contractor showed up at his house. Meeting calls were attended with of his wife making outbound sales calls in the same room and frequently with his dogs barking like crazy the whole time. He often traveled on the weekend and emailed that he "got stuck" and wouldn't be in until Tuesday or Wednesday. On days he showed up for a full day it was typically 10:30am to 5:00pm. I had to change pretty much every code commit to use it.
If you're showing up and producing anything of value there is probably someone around who can help you stop hitting the process bumpers. My guy wasted my time by not showing up often enough to get support.
Having him hired behind your back is obviously not his fault. Wedding/honeymoon should be a non-issue as well as long as management was made aware. Being expected to show up to work regularly and in an environment free of distractions should be a no-brainer, but for lots of people (especially juniors), working from home is something they aren't used to.
As far as the work itself, as a junior, why was he starting any projects at all without supervision/guidance? All of his code should have required PRs (maybe they did - again not enough details?) Juniors generally don't know how to write production quality code, it should be expected that code will be reviewed and issues addressed before being merged into the codebase. They're juniors because they don't know what they're doing and as seniors/staff engineers it's our job (whether it's fair or not is irrelevant) to help them get up to a baseline of proficiency.
Seems like the company and the junior were both contributors to his failure.
For a Jr remote SWE position, I would expect heavy pair programming the 3 first months.
First off a Jr shouldn't be working on a project all by themselves, obviously. That's on management to fix, an employee shouldn't be expected to perform at a higher level than they were hired at.
>Meeting calls were attended with of his wife making outbound sales calls in the same room and frequently with his dogs barking like crazy the whole time.
The idea this would happen "frequently" is crazy.
As a meeting leader myself if someone showed up to a (virtual) meeting with such noise/distractions in the background I would absolutely stop the meeting immediately and let the employee know they need to find an appropriate place. Once they did I'd resume the meeting. If claimed they didn't have access to a quiet/appropriate place at that moment I'd have them leave that meeting (or at least mute themselves) and speak to them offline about appropriate behavior during meetings.
The stuff about him missing work (presumably without using PTO or LWOP) should be met with an immediate formal reprimand. Any other instances after that should be termination.
Not the employee's fault...
> But he also missed half days of work whenever a contractor showed up at his house. Meeting calls were attended with of his wife making outbound sales calls in the same room and frequently with his dogs barking like crazy the whole time. He often traveled on the weekend and emailed that he "got stuck" and wouldn't be in until Tuesday or Wednesday. On days he showed up for a full day it was typically 10:30am to 5:00pm. I had to change pretty much every code commit to use it.
Those are issues where firing would be appropriate if they happened more than a couple times. Especially if they happened early in the job (aka probation period in most countries).
"You're not working the previously agreed amount, quantitatively!" is probably the least controversial reason for firing someone.
Agreed. I happen to work for an imperfect company, if you can believe that.
I did my post-mortem homework, and certainly concluded I could have done more and sooner about the situation. I was too busy trying to code for both of us to put my management hat on when I should have. Lesson learned!
I'm gonna come right out and say the thing most people here are too polite to say:
If your description here is at all accurate, you're on a bad team, a sinking ship, and your team is scapegoating you (and maybe other junior devs) for their downward spiral. You should be looking at moving to a team or company where you can grow.
Like, your manager has been gone since December?? Who's in charge? Who's assigning these stories to you? Who's making sure these mistakes don't happen again?
And I'm also going to say this: YOU have not caused any production delays. Whoever put you in a position to do things you weren't prepared to do is. But really, most likely: it was going to be delayed anyways and if it wasn't those incidents it was gonna be something else.
As for the senior dev who you think is doing great: either they know this is a fucking gong show and they're already looking to leave, but are keeping it professional, or they're coasting along for other reasons. Sadly, the "This is Fine" dog mask is one thing you definitely learn as you get more experienced in tech.
This sounds like it’s your first job so people should be forgiving and helpful. If you are at big corp (since you mention PIP) then why isn’t there a better onboarding?
Anyway yes you should probably be writing more stuff down. A lot of what you’re learning isn’t taught in class which is the processes and dynamics of the actual team and company.
So a lot it would be new and an adjustment period, not only to the job but work life in general. Adjustment to my first job was hard. Being in the same work space for a full work day was difficult when friends were just studying. Interacting with people twice my age. Being the youngest person in the office.
With this new environment comes new difficulties so what comes as common knowledge or second nature to experienced employees can be confusing or hard to grasp for first timers. Having said that, not grasping this or acting forgetful or needing something to be explained multiple times can come across as incompetent or often rude. When that’s happened to me in the past it’s given me the impression of “this person clearly does not give a shit or is stupid because this is the 5th time I’m explaining it”.
So yes I recommend taking good notes.
Other strange flags is your Manager being away for so long. This whole post reads as things you should bring up with your manager. Not having a manager around since December may even be something you want to bring up to HR so you transfer teams.
So yes, definitely write down every process and take notes on everything you learn. Also review and summarize your notes so they're actually useful. That way you hopefully won't often have to ask the same question twice. But any time you feel like you're spinning your wheels or are unsure what to do, I'd encourage going ahead and asking. Over time you can also probably identify who's best at answering what kinds of questions, ideally allowing you to ask the right people, while not pestering any one person too much. But keep in mind sometimes you can actually be saving the senior devs' time by asking a quick question early rather than having a bunch of wasted work or delays later on.
This requires motivation, capability, and opportunity from the team members. Maybe no one cared, maybe no one was capable to, maybe no one had time.
You should have received more active immersion from your team from the beginning. Since they let you down, you still need it. If they seem unwilling to admit that maybe they are partially responsible for you still needing help, you might be better looking for a new team that sees collaboration as a two way street. I think you should be seeking mentorship.