Another Senior SDE/tech lead here with 20+ years of experience including FAANG and some top Wall Street companies.
There is a lot of good advice given to you. I have read about a dozen top posts (at the moment), and haven’t seen something major I would like to correct. I am not going to give you full answer, repeating most of what already being said. Instead, bellow are few actionable items I would like to emphasize.
1. Prepare to leave the ship. Start looking at codding/algo problems, preparing answers to behavioral questions, probing your network, etc. Also, if possible, look inside your company, are there teams that you will be better fit for you? Do not wait for PIP, as in a lot of companies you can’t transfer while you are in PIP.
It’s not you, but life is too short to be on the team that doesn’t nurture you. More so, as starting junior getting right exposure to good engineering culture at the beginning is critical to your professional growth. I can’t tell you how many times I got to interact with basically smart folks that could have been a good engineers but who were damaged by early exposure to toxic software development environment.
On top of this, as of now, you are going to be interviewed as junior or even out of college, with lower expectations. A year or 2 down the road you will find that expectations from people who interview you will start to raise significantly. If you don’t grow now to meet them, you are putting yourself in a bad spot latter.
You might not need to leave your team, but being ready to do this will give you comfort, and looks like you need it.
2. Find good mentor. And another one, and another. Look both in inside company and outside. Be prepared to iterate through a few, and learn to be a good mentee. I saw at least one offer here, try to take it. Also, ask proactively here. If you leave me your throughway email in comment, I may be able to help you too (mostly depending on our timezones).
3. Start asking a lot of questions. It’s bullshit that you have been at the team too long to do this. It doesn’t work like this.
At the very least, you can think that if your standing with your team is damaged starting asking basic questions will not damage it significantly more (you might find that it actually improves it, but no guaranty).
Also, think about it as a skill you are developing: the skill to ask questions easily and early. You will need it throughout your career.
Few tips on asking questions productevly:
1. If you don’t know or understand something it is a legit question. If context is in person conversation or meeting it is OK to ask it right away.
2. If you need to find somebody to ask the question or ask for the help. You will end up with having 1 or 2 persons you are most comfortable asking questions, and as result asking them a lot of them. This is anti-pattern. Do not overload just one favorite coworker, go out of your comfort zone and reach out to other people.
Make for yourself a small SOP (Standard Operational Procedure) to ask questions, and timebox, say, 10-15 minutes to try to answer question yourself before reaching out for help: 3 Google searches using different queries, looks through product documentation, search through internal system(s), maybe post on the question board (different questions land themselves to different research steps). Also amount of preliminary naturally research depends on the urgency.
Communicating to your coworker that you did your legwork before asking for their time is a good thing and will save you few embracing incidents when the answer was right in front of you (happens to me far too often and is not that big deal).
After getting help from coworker (and naturally thanking him), ask how you could have found it by yourself. This will teach you to be better at searching information in the future, and in lot of cases it will turn out that there was no reasonable way to do so.
Also ask your coworkers what their preferable communication channel is to be asked for the help in the future and do your best to use it.
If person you asked doesn’t know the answer, make note to ping them when you learn it and ask them if they are interested in it.
Document your finds at least for yourself (it will take time to develop reasonable note taking system, aim it to be adequate, not perfect). As a stretch goal see if you can also document it for others, like updating internal wiki, etc.
There is a lot of good advice given to you. I have read about a dozen top posts (at the moment), and haven’t seen something major I would like to correct. I am not going to give you full answer, repeating most of what already being said. Instead, bellow are few actionable items I would like to emphasize.
1. Prepare to leave the ship. Start looking at codding/algo problems, preparing answers to behavioral questions, probing your network, etc. Also, if possible, look inside your company, are there teams that you will be better fit for you? Do not wait for PIP, as in a lot of companies you can’t transfer while you are in PIP.
It’s not you, but life is too short to be on the team that doesn’t nurture you. More so, as starting junior getting right exposure to good engineering culture at the beginning is critical to your professional growth. I can’t tell you how many times I got to interact with basically smart folks that could have been a good engineers but who were damaged by early exposure to toxic software development environment.
On top of this, as of now, you are going to be interviewed as junior or even out of college, with lower expectations. A year or 2 down the road you will find that expectations from people who interview you will start to raise significantly. If you don’t grow now to meet them, you are putting yourself in a bad spot latter.
You might not need to leave your team, but being ready to do this will give you comfort, and looks like you need it.
2. Find good mentor. And another one, and another. Look both in inside company and outside. Be prepared to iterate through a few, and learn to be a good mentee. I saw at least one offer here, try to take it. Also, ask proactively here. If you leave me your throughway email in comment, I may be able to help you too (mostly depending on our timezones).
3. Start asking a lot of questions. It’s bullshit that you have been at the team too long to do this. It doesn’t work like this.
At the very least, you can think that if your standing with your team is damaged starting asking basic questions will not damage it significantly more (you might find that it actually improves it, but no guaranty).
Also, think about it as a skill you are developing: the skill to ask questions easily and early. You will need it throughout your career.
Few tips on asking questions productevly:
1. If you don’t know or understand something it is a legit question. If context is in person conversation or meeting it is OK to ask it right away.
2. If you need to find somebody to ask the question or ask for the help. You will end up with having 1 or 2 persons you are most comfortable asking questions, and as result asking them a lot of them. This is anti-pattern. Do not overload just one favorite coworker, go out of your comfort zone and reach out to other people.
Make for yourself a small SOP (Standard Operational Procedure) to ask questions, and timebox, say, 10-15 minutes to try to answer question yourself before reaching out for help: 3 Google searches using different queries, looks through product documentation, search through internal system(s), maybe post on the question board (different questions land themselves to different research steps). Also amount of preliminary naturally research depends on the urgency.
Communicating to your coworker that you did your legwork before asking for their time is a good thing and will save you few embracing incidents when the answer was right in front of you (happens to me far too often and is not that big deal).
After getting help from coworker (and naturally thanking him), ask how you could have found it by yourself. This will teach you to be better at searching information in the future, and in lot of cases it will turn out that there was no reasonable way to do so.
Also ask your coworkers what their preferable communication channel is to be asked for the help in the future and do your best to use it.
If person you asked doesn’t know the answer, make note to ping them when you learn it and ask them if they are interested in it.
Document your finds at least for yourself (it will take time to develop reasonable note taking system, aim it to be adequate, not perfect). As a stretch goal see if you can also document it for others, like updating internal wiki, etc.