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 transferring schools, but since I started working, I’ve changed jobs quite often.
After going through so many moves, each time to a different company and a different role, I sometimes think changing jobs is like traveling. It’s a journey of leaving familiar neighborhoods and people behind and encountering new cultures in new places. From the outside, moving to another IT company, still as a developer, may all look the same, but in reality every move feels completely different. The people are different, the company is different, and the destination 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, I picked up much of my knowledge about the OS and infrastructure the hard way, by banging my head against real problems in the field. For example, I learned what an inode was after frantically googling the error message “No space left on device” even though there was still plenty of storage left. When I ran into a problem, I’d google the error message, read answers on Stack Overflow, and try to form a rough picture of what was actually happening at the infrastructure level. If I still didn’t understand something, I’d dig deeper, and if I still couldn’t make sense of it after that, I’d leave it as a black box again.
So whenever I moved out of the realm of web development, first to build monitoring services at SK C&C and then to my current role working on Kubernetes Service at NAVER CLOUD, my honest feeling was always about 80 percent excitement and 20 percent worry. Each time I was pushing myself toward lower-level work, so along with the excitement of gaining new experiences, I also worried about whether I could do the job well and whether my abilities might fall short. At the same time, I figured that since I had managed to adapt and find answers before, I’d probably find my way again if I kept grinding this time too.
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 onboarding, I spent almost all of my time learning about the products I was responsible for and the company’s shared internal systems. I was especially impressed by those common systems, which were used across NAVER and its affiliates. Building them separately for each organization or team would have taken enormous resources, but because they were centralized and owned by dedicated teams, they were very convenient for the people using them. Each system had solid guides and support channels, and the more widely used shared systems even had training videos on the internal video platform. I was particularly impressed by the shared Kubernetes platform called n2c.
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 line in the book [Take Control in 90 Days] that said, “You shouldn’t be meeting your neighbors for the first time when your house is already on fire,” and that was why I made a point of greeting them early. I thought it would be a good thing to make myself known, even if only online, and that kind of first introduction gets harder once you’re past the early onboarding phase.
Reflections of an experienced hire
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.