Ask Experienced Devs

Good advice already in this thread, but I'd add: ask smart questions, and when you're engaging with a senior/mentor, build the picture for them. Everyone (including your mentor) expects you to have questions - they want you to ask questions, rather than just spinning your wheels for days and days. But they also want to know what you've tried and what you've looked at for resources. And despite appearances, they don't always have the entire code base committed to memory. :)

For instance - suppose you'd been asked to, using the UI, return a piece of information from an external API and display it within the UI.

Bad question: "Hey, so I tried to integrate that third party API, but I'm not getting a return."

"Okay - what kind of code are you getting? And what do the docs say?"

🤷‍♂️

Good question: "Hey, so I tried to integrate that third party API, but the return I'm getting from it is a 401 error. That should be an authentication error - but just in case, I pinged their server from our server, and they can reach each other. The documentation says that I have to use our key to get a JWT, but hitting the endpoint it says gives me a 401 error. I double checked our token; I've got the right one. And I'm sending it in the header as 'auth' like the documentation says. Where else should I look?"

"Oh yeah, that's a tricky one - you have to encode the token before you send it; let me see if I've got an example where you can see what that looks like....."

One of the things that will happen over time, based on the questions that more senior SDEs ask, you'll be able to 'rubber ducky' problem solve by asking yourself the questions that they would usually ask you, and it's shockingly effective to help you sort your own problems out and clear your own blockers.

I'd add things like

• plan before you act (be that design before code, or something else of the sort)
• avoid asking the same question multiple times (take notes, study up on things, and try to not ask the same question or make the same mistake over and over)
• write useful tests and have good test coverage

1. Paying attention and caring about the quality of your output go great lengths. I’ve seen even supposedly senior devs doing a shitty job out of laziness to check what they’re doing.

2. Getting proficient with git and it’s usefulness. It is one of the single tools that can make you incredibly more productive.

The concepts you should know/are expected to know are really going to depend on the company you're working for and even the team within it. In general as a new grad you're expected to be learning, and you will slow down the dev that's assigned to be your mentor. That's 100% okay, it's part of their role as a mentor to be interrupted by you and help answer your questions so don't feel bad about asking for help when you need it.

One useful skill you can start to pick up immediately is learning how to discover things within the company. If you ask your mentor a question and they just give you the answer, don't hesitate to ask them to show you how they got to that answer. Whether it's debugging, navigating documentation, etc, the most successful new hires I've seen have been ones who have showed that curiosity and used it to learn how to navigate within the company's codebase/systems.

Another big change when you've only done internships in the past is to remember that your career is now a marathon, not a sprint. During an internship you often have a fixed amount of time to achieve a set goal so you can push hard and get there, knowing you're done at that point and can take a break. Now that you're working full time there will be more work waiting for you so if you keep pushing too hard you will burn out. Through trial and error you'll need to find a pace that you can work at sustainably over an extended period of time. Yes, there will be times when you have to push hard for an important deadline or if things are on fire, but hopefully that will be the exception and not the rule. I don't have any good advice for proactively avoiding burnout though. It's something that you have to learn by experiencing it and trying to reflect and see if you can identify any early warning signs. I'm almost 20 years into my career now and it's only in the past 4-5 years that I've started to be able to catch burnout before it happens and flag it to my manager.

If somebody more senior than you tells you to do a thing a certain way and you don’t understand why they think their way is better, ask them to explain it, but do it in a polite way. Asking the question shows you’re engaged in the process and not afraid to share your own input.

If you hear the explanation and still disagree, let it go and do it their way. Even if they’re wrong, they won’t want to hear about it from you at that point. You win some, you lose some. Being able to disagree and commit is huge.

Whatever the tech you're using, find the primary documentation for it, and read it carefully until you understand it properly. Rinse and repeat for 30 years and you'll be a guru.