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.
The point isn't to make companies better at onboarding, it's to stop juniors entering their first job feeling completely at sea.
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.
I would rather spend time 9 times, or 10 times, and make sure the person understands it. However, if the solution is screenshot from 1st attempt itself, I am sorry by the time we get to the 9th version, I am at my limit both with the junior and the manager.
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).
---
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.