How can someone prepare for their first full-time software engineering job?

Come prepared to ask a lot of good questions and help your managers fill in the onboarding gaps by pitching ways you can be helpful or areas that are interesting to you. The company is trying their best to onboard you, but it's a two-way street and anything you can do to take guidance well and demonstrate that you'll seek out the right work when there is any missing structure will seriously help.

Again, it's up to the company to get you rolling properly, but your role is not passive. Get engaged in it because nobody is ever quite organized enough to have you going properly and anything you can do will only help.

And lastly, I'll say: Be eager, but don't be in a hurry. Nobody expects you to be up to speed right away and don't feel you need to rush it. If you are eager, the pace will take care of itself. Don't feel like you need to know everything on day one.

And if something isn't clear, get help and offer to document the solution! I feel like this is sometimes the missing step. Newbies (either to the company or professional development in general) are often in the best position to provide good documentation because they are the ones who have the perspective to need it, and the energy to contribute however they can.

A lot has been said here, so I am going to point out one very important thought: Learn and do not repeat your mistakes.
As a junior developer you are expected to make mistakes. For example when your code is reviewed and you can apply these recommendation in your future work this is the best satisfaction for your supervisors.

Know how to write a program in the domain of the position. On your own. from scratch. If you'll be doing desktop work, then you know how to create a desktop app. If you're doing web work, then be able to create a full stack application.

This program doesn't need to be complex, nor optimal, but it has to behave like a real program. It should save data, interact with the user, use a DB if it's a web app, etc. Your program should demonstrate some of the key expectations a user would have in the domain.

Work on the program for a while. Keep a list of the things you think you've done wrong and how you'd like to improve. You should even try improving them on your own.

Once you think you've hit a limit, stop, take your knowledge, and write a new program. From scratch again. Preferably with different tools, maybe even a different domain.

Do this all on your own. You can ask a search engine, but avoid asking people, or in forums, for specific help. There's nothing you will be doing in these programs that hasn't been done, and working, a million times before you. Learn how to look it up and work through it.

The reason I say this is that I've met many people who have never actually made a full program. Especially not from scratch. This teaches you so much about how to program. You'll encounter so many of the problems that you'll face on a job. It builds confidence and ensures you won't ask trivial questions once on the job.

I don't have much to add to this (as one also starting their full-time career), but I was also recommended "The First 90 Days" (amazon.com/First-90-Days-Strategie...)!

1: Become familiar with the term "Imposter Syndrome", realise that everyone around you also has it, and it never completely goes away. Just identify how it relates to you and why, and it will help you to be comfortable with who you are and boost you confidence.

2: Throw your ego to one side. Everyone knows what you're capable of, but time constraints don't care for your prowess, just get the job done and don't over-complicate it with your vain efforts to show off.

Don't be afraid of the code review and "looking stupid". Your mistakes are all opportunities to grow and contribute to the company.

You are in a unique position in that as someone new, you still have a degree of objectivity. Things that may be clear because of familiarity with company culture may not be so evident to you as the new kid on the block. As Ben said, if something is not clear, create a quick write / snippet / bullet points that clarify or document a solution. In the end, communication is the only effective means for communicating ideas :) Your perspective can be a good mirror for an organization, and by filling in the gaps you are becoming a better asset to your new employer.

I don't expect much output. The key is to keep working - if they get stuck, work on something else. The lines are a bit blurry around asking too few/many questions, making progress vs falling into rabbit holes, but hopefully a happy medium can be found.

Pre-hire, they should be familiar with the languages and primary tools (IDE, OS). I don't care if they haven't used the frameworks.

Alaina -- pumped to see you posting on dev.to! Many moons ago you wrote a very nice tweet about my Medium blog, perplex.city, which I now sometimes cross-post here now that our whole team works on dev.to, where you now post, where...etc. etc. Small world!

Anyway, at the moment I'm but a data scientist in training, so I can't speak with too much expertise about engineering teams, but I have watched a handful of people come aboard dev.to and Texts.com (dev.to's corporate ancestor), and I think the most successful ones were the ones that asked Ben the most questions and weren't afraid to suggest new things. So I would say identifying someone on your team who seems open to "mentorhood" and bothering that person a lot is a good idea.

As a software engineer beginning his corporate life, you should know well that a client who pays real money to your company for some work, expects perfection and skilled work. Any mistake is hard to explain later to the client. Try to work on your mistakes, learn from other's work and never take your manager's word personally. Learn and grow. Stay awesome and keep compiling.

Don't forget: They probably existed before you arrived, so don't pass judgment on any technology/code they are currently using. Ask if they have heard of "the alternative" when you discover something that isn't what you thought it should be (i.e. Using X DB instead of Y, Tool A instead of Tool B). If the company is progressive, they will already know about "the alternative" and it may be in their plans to change... it may not because "the alternative" is not "blank_" or sufficiently stable for their uses.

Always ensure your solutions match their requirements for uptime, stability, support and capability. Your answers may sound great from an academic perspective, but many academic answers are terrible solutions in the real world when you have 1 day to do something that you could have spent 3 weeks on while in school. (Maybe a side project opportunity to show off a bit??)

Be on the lookout for a quick shortcut that was taken because of a "fire"; notice how they solved the problem and Why. The why of everything is MUCH more important than the how. There are always 5 potential solutions to a problem, with 100 trade-offs between them. Knowing why the team chooses a certain solution can make you more immediately "useful" than having memorized 20 other technologies that may or may not really fit their codebase or solution matrix of today.