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.
---
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.