My first year as a graduate software engineer is soon coming to an end, and I thought it would be a good time to share some of the lessons I’ve learned that may help future graduates. Some things were expected; more were surprises, but each one is invaluable to becoming a good engineer as you continue to develop your skills.
These learnings aren’t necessarily engineering-focused, so they can be applied to anyone in a graduate position at a company.
For those looking for a quick overview (being a graduate software engineer means your days are very full, after all!), you’ll find the top five lessons listed below. Following this, you’ll find a bit more context for each.
Key takeaways
1: You don’t need to know it all
2: Your ‘buddy’ is your savior
3: Ask questions, then ask some more
4: Prepare before asking your questions
5: Feedback is always good
How it started
I started looking for internships during the final semester of my master’s degree. I sent out a lot of CVs, and the process was quite stressful. However, after a while, a Tines recruiter reached out to me on LinkedIn about a job. I went through the interview process, and when I was officially offered a job at Tines, I was both happy and scared.
Why happy? Everyone at college dreams about getting a job straight after they graduate, and now I was getting the opportunity for both an internship and possibly a full-time position afterwards.
Why scared? Ruby is the main backend language used by Tines, and even though I had tried plenty of languages during my studies, I hadn't encountered Ruby. This is where my first lesson comes in.
Lesson 1: You don’t need to know it all
Even though we learn so much in college, there will always be lots not covered, and this is okay. The team at Tines helped me understand that we need to give ourselves time to adjust to our new environment. I was given time in the beginning to study, follow tutorials, read documentation, and do exercises so that I could get up to speed with understanding the language I was going to be working with. A good knowledge base is super important.
After that, I needed to be introduced to the real workflow, to the codebase, and to the tools that Tines uses. I needed to grasp a large amount of knowledge, and I would not have done that so smoothly without the buddy I was assigned at Tines.
Lesson 2: Your ‘buddy’ will be your savior
After my experience this past year, I strongly believe there is a huge benefit to having a buddy when you’re onboarding with a new team, especially for graduates. During onboarding, we can feel lost and overwhelmed by the influx of information. Wherever you begin your career as a graduate, you should request that you be assigned a buddy or mentor to help guide you to success.
I was given priceless guidance by my buddy at Tines. I knew from day one what I needed to do because we had a plan to follow. I knew who to ask questions to when I had them about anything, and here I learned a third lesson: that it is okay to ask questions.
Lesson 3: Ask questions, then ask some more
I’ve been lucky in that everyone at Tines is super nice and eager to help, no matter what questions I have.
In the very beginning, it was my buddy who I reached out to most. No access to a website; something was wrong with my GitHub request; I broke something; what now? It can be difficult to ask questions very often when you’re new and feeling unsure of yourself, but the alternative is far worse. If I hadn’t asked all those questions, I would have wasted so much time figuring everything out on my own, not to mention the added stress of doing that.
On the other hand, from my overthinking came another lesson; to always be prepared before you ask.
Lesson 4: Prepare before asking your questions
Asking questions is a fast and efficient way of getting things done. Don’t know how to make a mutation? Not sure how to handle this exception? Don’t know the syntax of the loop? Ask somebody.
However, it’s important to remember that behind every answer is a person who has their own tasks, their own deadlines, and likely not much visibility into the project you’re working on. To save them time, provide as much context around your question as you can. What is it you’re working on, when does it need to be completed, and what information are you sure of at this point?
From my experience using this approach, it has actually sometimes given me the answers I needed without having to ask anyone. By writing down the context, including what approaches had worked and not worked, the answer sometimes found its way to me.
It’s like the rubber duck debugging theory. If you don’t know what this is, hear me out! Imagine you have a problem to solve, but you aren’t sure how to approach overcoming it. Place a rubber duck in front of you and start explaining out loud to it what you’re doing and the issues involved. This method may seem funny, but it’s actually very effective.
I then create my pull request for feedback, which leads me to my final lesson.
Lesson 5: Feedback is always good
When I put the request in for review, it’s always nice to see "approved" right away, but what if I get lots of comments on how to do it differently?
I learned that reviews are a way for me to learn and improve. For me personally, improvement means progress, and I really enjoy progress – I’m motivated by it. Every item of feedback we get is good; it gives us a chance to consider possibilities we didn't think of.
To minimize the back and forth on my pull requests, I try to think of other solutions to the problem I am solving – sometimes I succeed, and sometimes I do not. Sometimes I have a solution that solves a problem with changes in a couple of files, but after a more senior engineer reviews it, it turns out there is a simpler way by only changing one line of code.
Hopefully, these learnings are actionable for anyone starting off in a new position, and the underpinning message for each can be carried on as you progress through your career.