I've been on the same team the whole time so far, though it's name, manager, responsibilities, and workers have changed. Here's some random notes from reflecting on my first two years as a pro.
Software engineering isn't 100% coding. Especially at more senior levels. Deciding what to code is a huge part of the job, code needs to have a why and how agreed on beforehand.
But knowing how to code independently is a requirement. Especially at a company with a competitive recruiting process, you'll be expected to know how to figure out how to implement your team's ideas.
Just because you can code independently doesn't mean that you can work independently. Employers want engineers that work well on the team. That means ones that listen and communicate effectively. Ones that document their work. Ones that mentor and support other team members. Ones that design and implement clear and concise solutions.
Prioritization is the key to successful software engineering at a fast moving company. At most jobs, there will be way more work than you have the time, energy, or focus to do. A huge part of the job is prioritizing your time to work on the high-priority things. It's also useful to recognize moments when there's less pressure and use those to work on things that you enjoy or are especially good at. A good manager will help you prioritize your projects, defend your time from outside asks, and encourage you to pivot your priorities when the company needs you to.
Recognize that reading code is harder than writing code, and at jobs that have established codebases for you to work on, you'll have to be able to read and understand the existing code. Reading and understanding code is a skill that you'll have to develop through practice. Hopefully whatever form of software engineering education you had leading up to the job provided that practice, not just the skill of writing completely new code. Once you get good at reading code, you can lookup answers to undocumented questions in the library you're using by reading a bit of the source code; don't be afraid to do so.
People have a tendency to add code more than they delete code, as that's what we're taught to do. However when working in existing codebases, it can be valuable to remove code and complexity from the system to make it simpler, which implies more reliability, and makes it easier to understand and change later. This definitely doesn't mean doing code golf to reduce the lines or characters of the text of the code without removing complexity. The goal is to make it easier to read, so clever tricks that aren't easily understood are counterproductive, even if they take up less lines.
Provide sources. When someone asks you a question about something you worked on, don't just answer it, provide proof. If they want to know about some data trend, answer it and link a graph that shows it. If they want to know about the architecture of a system, answer it and link an architecture doc. If they want to know what the behavior of your work is, answer it and link the source code. This habit can also be applied proactively. That means that commit messages, test plans, and code comments should contain links to prove what your commit does and why, if it actually works, and how it works. This will prevent people from interrupting you six months later to ask about a project you've completed, and help yourself remember how things work and why you did them a certain way.
Get close to the experts. Don't be afraid to talk to the most senior engineers or get code reviews from them. Ask them questions, voice your ideas to them, solicit feedback from them. After all helping you grow is a part of their job.
Be honest with your feedback. People sometimes won't give critical feedback to a coworker because they don't want to hurt their feelings or give them a bad performance review. Remember that they're a professional, and that your feedback should help the team achieve it's goals more efficiently. On the other side of that, solicit feedback from your coworkers and actively try to address it.
Working as a software engineer is about thinking, not coding. Coding fades into the background when everyone is competent at it. When everyone can implement any plan then it doesn't matter much who types it into the codebase. However many software engineers relish the coding parts of their job, because they can get into a flow state. Coding forces you to make a lot of little decisions, and slowly craft something functional. It's not unlike woodworking where there's just enough mix of thought and tedium to make it into a mental state of flow.