How I Navigated My Journey as a Junior Software Engineer
This is just a story of my time as a junior software engineer. Just a story.
The Interview Process
My very first job didn’t really have a formal interview. It was an early-stage startup with a small team, and they just needed someone to help build their product. I started as a freelance software engineer, and things went well. Three months later, they offered me a full-time position.
However, after nine months, I started looking for new opportunities. I wanted to learn more about software engineering, but in a different industry. I applied to several companies and got some interviews.
I interviewed with three different startups, all in different fields. One of them was Ruangguru, an edtech company, which I ended up joining as a backend engineer.
My interview with Ruangguru was tough, but I was also a bit lucky. I managed to do very well because the questions they asked were mostly things I had experience with from my previous job. They focused on system design and my past experiences.
Learning Through Doing
Most of what I learned about new technologies and software engineering practices came from hands-on work. I picked up TDD, CI/CD, microservices, event-driven architecture, and much more by applying them to projects. Even before joining Ruangguru, I didn’t know Go, but I learned it by using it in the project.
During some one-on-one chats with various people online, I sometimes get asked about this: “Do you need to learn a programming language or technology before joining a new company?” Some might say yes, but in my experience, it’s not always necessary. As long as you have a solid grasp of software engineering fundamentals, learning new things isn’t too difficult. Of course, you should let the interviewer know that you might need time to get up to speed.
But this isn’t an excuse to stop learning entirely. You still need to read, watch, and study. It’s just that sometimes, what we learn doesn’t perfectly match a company’s immediate needs.
Being Proactive
In my regular one-on-one meetings with my manager, I always pointed out areas where our development process could be improved.
For example, we had a code review system where someone had to approve a merge request before it could be merged. This process sometimes slowed us down because we had to wait for reviews. I realized this was something we, as a team, needed to improve. So, I brought it up with my manager, and we discussed potential solutions to make things better.
Another example is that I loved to share my ideas about system design when we discussed new features, even as a junior back then. I was really happy that my colleagues and manager listened to my ideas—even if they weren’t always the best. The most important thing was that these discussions often led to even better solutions.
I also liked to take on challenges or new responsibilities. You can read my story about TDD here.
Proactively Scheduling 1:1s
While there were routine one-on-one meetings with my manager (usually once a month), I also made an effort to schedule one-on-ones with colleagues and seniors. As a junior, I didn’t have much experience with careers, software engineering practices, or other related topics. So, I asked for their advice, shared their experiences, and sought their opinions on various things.
It’s worth noting that I usually built a relationship with them before asking for these one-on-ones, and I think that’s really important.
Asking for Feedback
In my one-on-one sessions with managers or colleagues, the first thing I usually asked for was their feedback on my performance. Since it was a one-on-one setting, I felt we could be honest with each other, especially after building a good relationship—which, again, I believe is crucial.
Commenting on Merge Requests
I was glad my company allowed every engineer to do code reviews, not just managers or seniors. So, I would leave comments on merge requests where I thought improvements could be made. The most important thing was that I was always open to discussing my comments. I think that’s important because sometimes I was wrong, and I could learn new things from those discussions.
Asking for Help
I wasn’t afraid to ask for help. I think that’s really important, especially when you’re a junior. I asked for help when I was stuck, when I didn’t understand something, or when I needed advice.
I don’t believe in “stupid questions,” and as a junior, I think it’s vital to ask questions.
For example, I tried to limit how much time I spent dealing with bugs. If I couldn’t solve something within two or three hours, I’d always go to my colleagues or seniors for help.
How did I ask? First, I’d explain the situation, then what I had already tried, show what I’d searched for online, and then ask my specific question. Usually, it was related to a task I was working on, so in those situations, it was crucial to ask for help so I didn’t block the team.
I think that’s everything I can remember for now. I’ll update this post if anything else comes to mind.