Introduction
After graduating from SSAFY, I had been eager to try an internship. Not necessarily a conversion-track one — even an experience-based internship would have been great for building real-world skills.
But lately, frontend internship postings were few and far between, and the handful I did apply to rejected me at the resume stage more often than not.
That's when I stumbled upon Wanted's Pre-Onboarding Internship.
It's not a traditional internship where you commute to a company every day, but I applied because the free curriculum looked solid and it seemed like a great opportunity to develop collaboration skills.
Honestly, since it's not actual work experience, I didn't have huge expectations — but it's been a better experience than I anticipated, so I decided to write a Week 1 retrospective.
What Is the Pre-Onboarding Internship?
Pre-Onboarding = Pre + Onboarding
Pre: beforehand, in advanceOnboarding: the process of helping new employees adapt quickly to company culture and their role
Onboarding is the process of helping someone who just joined a company get settled in. So "pre-onboarding" is training designed to help you build the skills you'll need to work at a company — before you even get hired.
Over 4 weeks, you work on company-assigned projects to sharpen both your technical and collaboration skills, and Wanted actively supports participants in their job search.
How to Apply — What You Need: A Pre-Assignment
To participate, I first had to submit a pre-assignment. The task was to build a simple Todo app with basic authentication, meeting 10 specific requirements.
Since it was a Todo app, the functionality wasn't particularly complex, so I was able to finish fairly quickly.
Week 1 Assignment
The Week 1 assignment was to discuss and select a "Best Practice" for the pre-assignment Todo app with teammates, then refactor the original code accordingly. During our first Discord meeting, everyone was a bit awkward and quiet — and before I knew it, I had somehow become the MC(?). Naturally, I ended up taking on the team lead role. I had always wanted to try leading a team of strangers at least once, so I was happy about it!
Best Practice
Through discussion, we were able to narrow down everyone's shared priorities:
- Separation of View and Business Logic
- Readable and reusable code
- Component reusability
- Guaranteeing data consistency with the server
Based on these criteria, we settled on four key Best Practices:
- Using the Context API to separate business logic
- Extracting shared code into hooks or utility functions
- Designing reusable common UI components
- Refetching server data whenever a data mutation event occurs
Key Code
1. Separating Business Logic with the Context API
2. Designing Reusable Common UI Components
Week 1: What Did I Do?
I Became Team Lead
As mentioned above, I ended up as team lead this round. It happened at SSAFY too — somehow, before I realize it, I'm the one steering the ship. I wasn't like this back in school, and I honestly can't pinpoint exactly when this became part of who I am.
I'm equally comfortable as a leader or a follower, but this time I wanted to shift my mindset — less about "leading" the team, more about "following" the team. Not in a passive sense, but in the spirit of building a horizontal relationship where everyone is an equal, and my job is to be considerate of teammates and help everyone's strengths come together.
Project Setup
As team lead, I handled the initial project setup. Setting up a GitHub organization from scratch was new territory for me — a bit unfamiliar. The deadline was tighter than I expected, and I knew the rest of the team couldn't get started until I had the environment ready, so I felt a real sense of responsibility and urgency. I remember sitting down right after our morning meeting and not stopping to eat or shower until the project setup was done.
Week 1: What Did I Feel?
After more than a year of studying… what have I actually learned?
During the first Best Practice selection meeting, looking at my teammates' code made me feel a wave of self-doubt. Some of them had written code that was far better than I expected — genuinely impressive. For the pre-assignment, I had focused entirely on getting the features working and paid no attention to code quality, and I felt real remorse about that.
What did I learn in a whole year at SSAFY? Mostly just churning out SI-style project features — a loop of functional self-replication. I never once received a code review throughout the entire program. That's what made the "peer learning" approach of this internship so valuable; seeing my teammates' code taught me more than I anticipated.
I want to grow — seriously.
Going through this Pre-Onboarding Internship has ignited a fierce desire to improve. I'm not commuting anywhere, I'm not doing actual work, and the code I write won't be used in the real world — but I believe that even within a small experience like this, real growth is possible.
I didn't come in with grand expectations, but seeing the excellent code written by teammates who have been studying development for even less time than me made me genuinely excited about how much I can grow through peer learning.
I want to be a teammate who adds value to the team.
On the collaboration side, I want to be a positive influence. One question I've been turning over lately during my job search is: "What does good collaboration actually look like?" and "What does 'communication skills' even mean?" and ultimately, "So what does good communication look like in practice?" I want to keep working toward my own answers to these questions.
I want to write good code.
I want to write code that is readable, extensible, reusable, and maintainable. Above all, I want to write code that is structurally sound from a design perspective — the kind of code where anyone who sees it thinks, "Wow, this is really well written." Lately, working on personal projects, I've been rushing to implement features quickly because progress felt slow, and I've been cutting corners on design. Going forward, I want to make it a habit to think through the architecture before jumping into implementation.
Final Thoughts, and Looking Ahead
I feel like we got off to a great start with a solid team! It had been a while since I last collaborated with others, so it felt both unfamiliar and exciting — genuinely fun. And in the middle of what had been a pretty solitary job-search grind, this experience lit a fire in me and gave me strong motivation to write better code.
I don't know yet what Week 2's assignment will be, but I plan to give it my best from the perspective of good design and good collaboration.