Tears shed, the real reason for accepting me is…

In the second to last week before leaving, during the “1 on 1 meeting” with the team leader, I asked her why she chose me in the first place. She said, “My resume had the skills they were looking for”, “She thought I was a Fast Learner”, “I was honest during the interview, if I knew something, I said it directly, if I didn’t, I also said it directly”, “I was punctual during the interview” (maybe they were influenced by me putting on a suit in front of the computer at 4:30 in the morning).
After the conversation, I felt even luckier to have gotten this job. To be honest, I was very clear at the time that with my level, I definitely couldn’t deceive them by pretending. And from more conversations, it was obvious that they were well aware that a first-time Coop student didn’t know much. Their main goal was to have me learn something and at the same time, have me do some work for them.
Coop students generally do not touch production-level things. But the problem also lies here, usually one person is responsible for testing on the lab and then deploying on production. Since I couldn’t deploy production services, there wasn’t much work left for me.
Of course, these may all be because my position is a Service Engineer in operations, so it may not be very representative.

Only got into the groove in the last month

At the beginning of the last month, the team leader gave me a series of tickets to change the Kafka Endpoint in all service configurations. Among the 8 services managed by our team, each one had a different deployment method. Some used Chef, some used Ansible, and there were also K8s, Docker. I feel that these final tickets were the most valuable part of this internship.
When trying to reconfigure each service, I needed to understand the architecture of each service and its deployment method one by one. Most importantly, I needed to ask for permission from the colleague responsible for that service. This ticket finally allowed me to truly understand my colleagues and what each person was responsible for. Various knowledge learned before was applied at this stage. Deployment with Chef, git workflow, using environment, quick text processing with vim, and various bash commands.

About the experience where I was unfamiliar with git and dug a hole for myself by using rm -rf *

There was a task requiring me to update a git repository on a server and redeploy it. However, the git on that server required a password that I didn’t know. I thought since I could pull with my own access, why not change the access username to my own. The idea was indeed correct, but the only method I thought of to switch users was rm -rf * and then reclone.
Looking back, it sounds quite silly, but luckily my colleague found out when checking the server’s bash history.
Him: “Did you use rm -rf *?
Me: “(feeling guilty) Yeah?”
Him: “The deployment information is stored locally, and now you deleted it”
Me: “Ah, I messed up (ﾟДﾟ)w”
Since my task was to redeploy this cluster, this task got stuck for a long time then. If it wasn’t for my colleague, I might have been stuck for even longer. I owe him a lot for this!

After completing that series of tickets, the team leader told me that I had met her expectations and to do something on my own.
During previous discussions with colleagues, one colleague had a task to convert an Ansible deployment script to Chef, but he hadn’t done it for a while because he had previously converted the script from Chef to Ansible… Now because of the requirement from above, he had to switch it back. If it were me, I wouldn’t have been motivated to do this.

After experiencing the complexity of a big company project, I finally completed this conversion in the last week before leaving.

The holiday-like life comes to an end!

The long-awaited college life is finally about to begin, starting with online classes from the beginning. Now I can finally see what undergraduate life is like.

Hopefully, when looking for a job next semester, I can be as lucky as now\\٩( ‘ω’ )و///