Alternatively: what do you expect from new grad/junior software engineers that join your team?
Thanks in advance for your thoughts. 🎉
Alternatively: what do you expect from new grad/junior software engineers that join your team?
Thanks in advance for your thoughts. 🎉
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.
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.
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.
This is the best answer so far. There is nothing more that infuriates mentors more than their mentees not learning from mistakes.
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.
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.
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.
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.