I moved to my current company, NAVER CLOUD, at the end of August last year. When I was in school, I graduated straight through without transfering schools, but since I started working, I’ve been changing jobs quite often.
I’ve been through this many changes, each time to a different company and a different position, and it makes me think that changing jobs is like traveling. It’s a journey of leaving familiar neighborhoods and people and meeting new cultures in new places. From the outside looking in, someone might think it’s all the same because I’m moving to the same IT company as a developer, but the reality is that each job change is a very different experience. The people are different, the company is different, and the purpose is different.
Changes in work domains
Looking back at my journey from job to job, I realized that I was working with lower and lower level technologies. Five years ago I was doing web development at RIDI, then at SK C&C I built a cloud monitoring service as SaaS, and now at my current company I’m building PaaS for a managed Kubernetes service. It wasn’t intentional, I just chased the companies and positions I liked with each job change, but it just happened to be this way.
It’s funny when I think about it, I was weak at the low level. When I was in university, my graduation project was about web and mobile app development. Even then, some of my classmates were working on Linux-based network traffic control, and some of my seniors even created a simple OS. But at the time, I didn’t even understand what it was, even when it was explained to me. I didn’t know anything about Linux other than the most basic commands, and I managed to keep up with the CS classes at university, but I wasn’t at a level where I could brag about it. I got a job as a server developer at my first company after graduation, but I was just an application developer. I knew very little about the abstractions underlying the code I was writing. It was just a black box. I was aware that I could simply specify an IP address and port number in my code to connect to a remote location, and underneath that, I had a superficial understanding that I was sending and receiving packets in some way over the TCP/IP protocol as I had learned in class. I had no experience with actually peeking at packets or utilizing the commands involved, and in fact, I didn’t have enough knowledge to do so.
As a result, much of my knowledge of these areas of the OS and infrastructure has been gained from scratch. For example, I learned about the existence of inodes by googling them, frustrated by the error log “No space left on device” when I had plenty of storage capacity. When I had a problem, I’d google the error message, look at the answers from the stackoverflow, and try to get a vague idea of what was actually going on at the infrastructure level. If I didn’t understand something, I’d dig deeper, and if I still didn’t understand something, I’d leave it as a black box.
So whenever I moved out of the realm of web development to develop monitoring services for SK C&C, or to my current position as a Kubernetes Service developer for NAVER CLOUD, my honest feelings were 80 percent of excitement and 20 percent of worry. Each time, I was challenging myself to work at a lower level, so along with the excitement of gaining new experiences, I was also worried about whether I could do this job well and whether my current capabilities were insufficient. I also thought that since I had somehow adapted and found answers in the past, what would happen if I tried harder this time.
Looking back on it now, about 8 months after joining, I feel that this challenge has reestablished the slope of my learning/growth curve, which has been a bit sluggish, and I’m hopeful that my experience in infrastructure as well as web and application development, which I’ve had some experience with, will be a good asset in the future as a senior engineer.
Adjustment
Everyone has a hard time adjusting to a new company, even experienced employees. Even if your company has a good onboarding process, it doesn’t dramatically ease the transition. The pandemic has made this process even more difficult, especially if you’re working from home. Even if you’re able to collaborate online, it’s still not the same as being face-to-face in the office. It’s hard to get a sense of the company’s atmosphere and unspoken rules from home, and it’s not easy to reduce the emotional distance between coworkers. That’s why I personally prefer a hybrid work arrangement that involves some office visits rather than a fully remote work environment.
At the beginning of my onborading, I spent almost all of my time learning about the products I was responsible for and the common systems in the company. I was particularly impressed by the common systems in the company, which are used by NAVER and its affiliates. In fact, building these systems separately for each organization or team would require a lot of resources, but it was quite convenient for the users because a separate team was set up for each system. Each system has a good guide or inquiry system, and in the case of common systems that are used a lot, there are also training videos on the internal video sharing platform. In particular, the Kubernetes common platform called n2c was quite impressive.
As this was my first job change in a work-from-home environment due to the pandemic, I faced a different kind of softlanding challenge than usual. The first was that it was not easy to communicate my adjustment process and get verbal and non-verbal feedback on it. To solve this problem, I wrote a “1st month review report” about a month into the job and shared it with the team. It summarized what I’d been working on over the past month, the hurdles and positive experiences I’d had from a new hire’s perspective, and then I wrote down my thoughts on Plus Alpha for new team members. No one asked me to write this, but it was a way to share “here’s how I’m adjusting beyond the monitor” when we can’t see each other due to the pandemic. It’s the kind of thing you’d get to know naturally on the way to and from the office, or share over tea.
The second was collaborating with coworkers I hadn’t seen in person. Before the pandemic, we would have exchanged greetings and tea time in the office to familiarize ourselves with each other and reduce the distance, but this was not easy in a remote work environment. To that end, I intentionally greeted my coworkers early, even if it was just through one-on-one conversations on Messenger. There was a sentence in the book [Take Control in 90 Days] that said, “Your house shouldn’t be on fire and you’re just now greeting your neighbors for the first time,” and that’s why I intentionally greeted them. I thought it would be a positive thing to put my face out there, even if it was just online, and it’s not something you can do after the first few days of employment.
Career changer’s podium
Most experienced employees are nervous to hit the ground running and perform at the top of their game, and the usual advice is to take it easy and not get too worked up. Of course, it’s better to be calm than to be overwhelmed and screw things up. However, it’s important to note that delaying planning and establishing your role and direction in the organization can often lead to problems down the road. You need to think early on about what you can contribute to the team and define your territory. This will only get harder as time goes on, and the first impressions you make early on will have more impact on your work and evaluation than you realize. It’s a career challenge that you shouldn’t be too anxious about, but you can’t afford to be too relaxed either.