TLDR: I wanted to share snippets of my journey in battling the struggles of onboarding and the anxiety of being a probationary employee. I am not aiming to brag in this post but rather to inspire others in the tech and IT industry who are going through similar struggles as I did. I wanted to share some insights and perspectives that I learned and leveraged during my time on probation, in hopes that it will help others see the silver lining amidst the challenges they're facing.
Onboarding
Looking back at my first week, the benefex culture left a great impression on me regarding how they welcome new joiners to the company. Tech and office gear are provided to you as part of the welcome kit. I can't remember where I took the photo of the welcome kit, but they have something like the standard gift given to you on your first day 😅.
The first week was filled with sessions that focused on the company values, rules and safety regulations, and, most of all, security policies. I was with four other people; there were five of us in the new joiner's batch at that time, and they were also fun to hang out with.
As soon as I was given access to developer resources, I immediately got to work exploring the knowledge base while being careful not to make any changes to moving resources and tickets. It's like being a toddler again and exploring the nooks and crannies of a new house, but with awareness this time, of course 😊. Being a new joiner, I have my "I-am-new" card to play, which basically grants me the privilege to sit in meetings and ask people questions while their patience is at the "oh, you're new here" level. And the additional literal piece of mind and "can-chill-in-the-middle-of-the-shift" buff effects 🪄. But I know it won't last for long. I've been told several times to "take it at a learning pace" by others in the office as I am constantly seeking ways to get busy, or "look busy." And you know what? They were right; responsibilities will eventually come after you've grown into the role. So it's really about finding the balance between grinding on the job and taking things at a learning pace to avoid stressing yourself out.
First month
Copping up with the timezone problem
I am assigned to work with a remote team from the GMT+2 timezone (EU location), which is the timezone of our company's main office. I am on UTC+8 timezone by the way. I was made aware of this a month before I officially joined the company. What I did was strategize a plan for learning and developing new habits over a span of 1-2 weeks. I used time-blocking on my calendar to act as reminders for when I would eat and when I should sleep. The work to be done would still fall on me personally, of course, to develop the discipline to follow the things that I set.
It felt really weird at first, since I am accustomed to waking up at 5 or 6 AM and getting out of bed. When I was learning this new schedule, I had to wake up at 9 AM to get 7-8 hours of sleep. I was bad at it for the first week, and I really tried to push myself to stay up until 12 or 1 AM. But hey, "if there's a will, there's a way." So, I got my act together and forced myself to follow the new schedule, all while making adjustments to my habits to ensure I didn't affect the number of hours I slept. I stopped doom scrolling and watching series an hour before I went to sleep, and I also made some changes to encourage drowsiness before bed, such as turning the lights completely off and not engaging with devices an hour before sleep.
By the time I joined the company, I was already accustomed to the schedule. I am still working on it to this day, but I'd say that I was good enough at it when I joined the company. Enough to last the whole shift, at least 😄.
The onboarding developer experience
Now we get to one of the best parts, the developer experience. Now the developer culture in benefex is great in a way that they give you the creative freedom on how you work and deliver your tasks. They'd let you choose your device, and what operating system you can use as long as you adhere to the security policies and company guidelines. I pushed my hardest to negotiate with the IT team that i be permitted to install and use Ubuntu-linux on my work laptop. And they agreed, but they could not promise the support when something breaks. TBH, i somehow low-key regret i did not choose the MacOS option till this day. That could be my only ticket to work on an apple device and i clearly missed it. But in my defense, i choose to work with Ubuntu because i've already have a developer workflow setup for it that is easy to re-setup again and again, so yeah, i traded of the opportunity to get my hands on an apple device for my own comfort.
When it comes to setting up your developer environment, they have a runbook that you can follow on what things you can install and the options that you can use to setup the dependencies of the different tech stacks that are used for software development. I personally added my own flavor to the guide since the one that they got was for macOs and are using the brew package manager for installing the dependencies. And again, it's that creative freedom that they grant you for how you deliver your work. An absolute 👌.
The only major thing that i noticed when working with their microservices is that they haven't really streamlined the process for running their services on local environment. I mean yeah sure, if you're a developer you can figure it out right? That is true, but the added benefit of having a streamlined way of running services saves developers from the mental drain and stress of trying to figure the system out. Patterns such as the three-musketeers helps to reduce this issues of running parts of the microservice system regardless of which environment. But yeah, i guess having the roles of developers and operations engineers separate has it's costs. And for me, this is definitely something that can be improved moving forward.
It wasn't much of an issue for me getting accustomed with the tech stack on the java-springboot side of things since i myself worked on springboot microservice architecture back at my previous company. But i clearly am lacking for the application that were written in Go-lang. And i'll cover more of the things that i realize i need to learn later on.
Team cadence and ways of working
My role in benefex is not really something that needs to cover a 24hour coverage so i am following the timezone of GMT+2 and their working hours. Although my line manager told me that he's open to which time i would prefer working, i still followed on my normal practiced schedule, which is mid shift in UTC+8.
I must admit that i am in a bit of a shock when i started working with my team. Few words: "They don't dilly dally". They'd go and sit down and get things moving and done fast. Reviews and comments flying in and out of the github pull request. Reviews being requested in moments, the whole conversation is carried on in github and supplemented on the team channel. I was trying to catch up with things being talked about and as a new joiner, it hasn't been an easy time. This has been a shock for me since at my previous company, we dont have QA and so i would go on a ceremony for minutes to make checklist of the acceptance criterias that i need to check before conducting a code review and functionality testing. So yeah, i also had to make adjustments on how i'd do things since the process that i was accustomed to just isn't going to cut with how fast changes are being thrown back and forth through the PR.
And what i find cool about working my new team is that they'd like to be straightforward on things and really take a small minute of their shift to jump in a call to help you with your blockers. They are also very supportive and encourages people to ask questions whenever unsure so that everybody can give their thoughts and correct the understanding.
Defining the learning curve
Now one of the interesting things about the time when I joined is that the company had long planned to send two employees from the UK to Cebu to coach and work together with the newly formed engineering team in Cebu. I, along with three other guys from another engineering role, was up for the challenge of working with the team they were going to send over. Days moved on until the fateful week, when we finally got to meet Scott and Liam from the UK. Liam was set to mentor the other guys, while I worked with Scott. Scott showed me the ropes of the system stack, how we do deployments, the best practices currently being followed by the team, where we are now, and what we are trying to achieve—basically, the whole package of everything I needed to know, along with the opportunity to ask questions. I worked with them for two whole weeks and even went on trips with them on weekends during their stay in Cebu. I was really happy with all the new things I learned, though I also felt a bit lacking, as there were topics we discussed that I needed to see for myself to really understand.
Some things I realized are that my knowledge of Java and Spring is still quite basic, and that the framework and language have much more to offer in terms of learning. Another point is that we are working with MongoDB, which is a NoSQL database, meaning I need to learn and get used to using it, as opposed to the relational databases I have been accustomed to, such as PostgreSQL. Lastly, there's the cloud infrastructure technology. Previously, I worked with AWS technologies for deploying and shipping software. Now, I have to learn Google Cloud Platform and Kubernetes deployment to understand how we shift and deploy software for our different products.
Speaking of products, growing domain knowledge presents a whole new challenge. We have many emerging products, and although I am assigned to the API Gateway project, there will come a time when engineering resources need to be allocated to supplement the workload of other teams. Thus, I also need to account for learning the domains of these different products. To keep track of these things, I've taken the opportunity to write about my experiences and journal them, so I don't lose direction or my mind with all the information that needs to be learned.
Gaining traction
Taking on tasks and assuming ownership
Weeks and days went by, and every day seemed like an opportunity to learn something new. Remember when I said earlier that my "new-hire" card wouldn't last forever? Well, the team decided that I should take on tasks bit by bit as part of the onboarding experience. And so I did. My first major task was addressing a tech debt by rewriting a service originally written in Go-lang into Java Spring Boot. And boy, I did not enjoy reading Go code. Maybe it was because I didn't really know it, but I made some progress by reading and familiarizing myself with some if-else patterns. Along with the help of the IDE’s IntelliSense magic, I was able to trace the code and slowly understand the logic of the application piece by piece. The way I tackled this was by drawing diagrams, mostly in C4, and also flow charts to illustrate the functions and responsibilities split between the different Go classes. I can't say I did a great job at understanding the Go code, but it was enough for me to devise a strategy for the Spring Boot implementation. We wrote a thousand lines on that rewrite, and up until now, the PR has just been stockpiled since we couldn't get QA resources to test it due to a lack of people. But since this was a tech debt task, it wasn't really major, and the Go service is stable, so it will be fine—for now at least.
After that, I took on tasks to provide support by participating in code reviews. It was a good opportunity for me to learn things on the fly and understand the coding conventions we had on the engineering team as a whole. Our team was really small, with just two backend engineers, including myself, laser-focused on the project effort since it was a new and ambiguous endeavor for the company to develop APIs for integration with external systems. Bit by bit, I gained knowledge and got used to the coding style of my fellow engineer on the team, and I also received mentorship from him on things I didn't understand. With every PR merge I was involved in reviewing, I felt a sigh of relief that even if I was just checking out and reading someone else's code, I was still learning. I give myself a pat on the shoulder every time we close a ticket and mark it as done, and I try my best to maintain a professional demeanor even when things seem to be floating in the air and the situation is full of uncertainty. Because as everybody says, "we'll get there eventually."
Getting involved
In my second month, I started to answer questions from other engineers who were newly hired to the team. Having been in their shoes myself, I really sympathized with their need for support, especially as new employees. I slowly began to raise my hand in meetings and ask questions about the domains when I got the chance, and asking questions helped me understand how we arrived at the current state of things. Most people tend to complain when there is something they don't understand or when things are handed to them and aren't as pretty or easy to work with. Instead of complaining, I shifted my questions to "Why was it done? What is the decision behind it?" This thinking has taught me empathy, allowing me to put myself in others' shoes and try to understand the trade-offs that were made. In software engineering, some problems are not as easy to solve as others, and that's when trade-offs and hard decisions are made. The people on the team are not shy about answering such questions, and I am really thankful for the level of openness that other engineers on the team have.
Perhaps the most intimidating part of my experience as a developer at Benefex so far has been being included in the on-call alert support rotation. Now, I am not entirely scared about it, as I've held similar roles in my previous company. However, being new (just a few months) on the team gives me a daunting expectation. Scott reassured me that I can pair up with a senior engineer from the product-specific team if I need support for production access and action items. He mentioned that we just need everyone to take a share in looking into and investigating alerts to act as the primary layer of lookout and be able to triage them. So escalating to a senior team member is nothing to be ashamed of. So yes, I'm now with the other engineers on the support rota, and I’m kind of praying to the tech gods that I don’t get any incidents on my day of patrol. 😄
I also became more involved in discussions on the knowledge base and made updates to pages that needed improvement. During times when I am not writing code and am looking for things to do, I read updates on the knowledge base across different areas just to stay informed about the information being revised, created, and the discussions surrounding them. I try to maintain this habit because being a developer doesn't just mean you're paid to write code. It's also our job as developers to maintain and create documentation and to get involved in the decisions that contribute to our collective efforts and products.
Hurdles I encountered
Of course, my onboarding was not without its down moments. Aside from realizing the huge learning curve and knowledge gap that I needed to address, I also had to keep an eye on the things that are important and deliver value to the business. These are the items on the project board that need to be moved to "done." One way I tried to contribute was by double-checking the PRs that senior team members were working on. Even though I was just a second pair of eyes on the review, it was a great way to learn, especially when you're sometimes learning to do things on the fly.
However, there was one review that I really struggled with. It involved setting up security for the gateway project, and I didn't have the knowledge of the concepts being used in the implementation. So, I took a quick course on Spring Security over the course of two days. I felt the need to complete the course quickly to grasp the material, or else I would never keep up with the conversations, and the quality of my review would suffer. I pushed myself during that time, taking notes so I could revisit the example implementations shown in the course. By the end of the two days, I was able to review the PR and found that the effort to take the course was truly worthwhile. I gained a basic understanding of the areas to focus on and how things worked, allowing me to provide feedback and request changes to improve the implementation in the PR.
Another kind of problem I frequently encountered was the conversations happening between senior team members, where I often felt left out or like I was missing out. I needed to stay sharp and pay attention to things so that I could be useful, I told myself. I made some efforts to set up notifications on the team's knowledge bases to send me emails whenever there were changes to the pages, as well as updates on the team project board. I also organized my email folders so that related items were grouped together instead of just piling up in the inbox. Furthermore, I explored using GitHub notifications directly in the Chrome browser to alert me when there were conversations or PRs requesting my review, ensuring I wouldn't miss any updates.
And lastly, with every new experience comes the hard struggle of understanding. Whenever I encounter a completely new concept, I feel sluggish working with it, and my progress often halts due to uncertainty and self-doubt. To combat this, i've practiced the habit of writing things down, even if I'm not getting the terms exactly right; I just write everything down. At other times, I invest time in mapping new concepts in my personal notes into diagrams that help me visualize my thoughts. Of course, some of these may not be entirely accurate since they are new to me, but translating my thoughts into something that allows me to associate concepts has been very advantageous. It also helps alleviate my tendency to overthink and doubt myself. As I write things down, I try to pep talk myself, reminding myself that "even if I haven't figured it out today, if I keep at this, I'll understand it eventually."
Making it official
Three months as a Benefexer were quick, full of learning, fun, and most of all, very challenging for me. I've done things I haven't done before, such as collaborating with a lot of people in a face-to-face manner. I'd say that I haven't gotten much talking and hanging out with other people since I was mostly working remotely. I also picked up some stories and lessons from the new colleagues at the office, with whom I had deep conversations about their professional lives, which were really helpful for me as a growing professional.
By my third month, I had already transitioned to a remote work setup since the role was advertised as remote. So, I am back in my apartment in the provincial region of the archipelago, which I also enjoy because I am close to my loved ones and the cost of living is much cheaper than living in the big city. My manager got a 360 review of me from the engineers that I worked with, and then I just waited.
In our one-on-one, my manager happily shared with me the remarks and feedback from the other engineers, including his feedback on my performance. It was mostly positive, with some areas to improve, of course. But it was overall positive feedback ⭐. I was really overjoyed when it was made official and announced to the engineering team. I am really grateful to all the amazing people at Benefex for their support during my probationary period, along with my team and line manager.
Conclusion
Being a new joiner at a company has challenged me and, at the same time, made me anxious about my skills. As I conclude my narrative about how I navigated my probationary stage as a new joiner, I'd like to recap the things I have tried and learned on my journey:
-
"Try to strike a balance with everything you do 🧘♀️"
- This also applies when learning new concepts. As a new joiner, I have realized the things that I am lacking and that I need to work hard to supplement them. However, there are also things that need to be delivered that add value to the business. Having a balance between the time to learn and the time to work on delivering value is important, as too much of one can impact our performance as professionals.
-
"Responsibilities will eventually come to you; take things at a learning pace 💆🏻♀️"
- I guess what I am trying to say here is to enjoy the time to learn when you are new to an organization. As the complexity of the role and the ways of working slowly reveal themselves, taking the right perspective and pace is important to avoid pushing yourself to the point of burnout. Onboarding only happens once when you join a new organization, so keep things interesting and fun.
-
"Master the skill of developing habits and discipline 🎯"
- Change is constant when you are a developer and this also the same not matter what your profession. There's always something you are going to be chasing to learn. Mastering the skill of developing habits for learning new things, along with the discipline to keep going, creates a huge advantage for you not just as a professional but also as an individual. Don't be afraid to make adjustments to your habits if something is not working out, or if you need to change your habits for something that may benefit you, such as getting the appropriate hours of rest daily. You must build the discipline to maintain the habits that benefit you.
-
"You'll figure things out eventually 😊"
- New things are scary and weird to work with, especially since they are something you’re not used to. Bear in mind that this is part of growth, and that stepping out of your comfort zone is always the first step toward improvement. Figuring things out does not come with time alone, but with the effort you put in to try and understand something. Talking to other people and sharing your understanding can help you level the learning curve, as you can also learn from other people's perspectives on the concept. I find it surprising that I can wake up tomorrow with a more clarified understanding of something that was difficult for me to grasp yesterday. To share what I've done, I also thought hard about that concept before ending my day. This is truly an example of how we eventually figure things out.
That being said, every onboarding experience is truly different from person to person. Even if the challenges vary for each individual, we can approach these hurdles with an optimistic perspective and a positive mindset. Thank you for reading through this long narrative post. I hope you gained something new from it and that you will be able to apply the lessons I have talked about here. Cheers, and I hope you enjoyed the read! 👋😊
Top comments (2)
Great job settling in. I tap into your grace that I will do the same in 2025.
I'm Rooting for you man. Good luck