A very belated retrospective on the Pre-Onboarding FE Internship. It's been over a month since the internship ended. After finishing, I had to apply to 20+ positions on Wanted as a graduation requirement, so between polishing my resume, sending applications, and attending interviews, the month flew by.
I've already posted through the Week 3 assignment, so I figured it's time to write a final retrospective. I skipped Week 4 since there wasn't a whole lot of new material to cover…!
What Is the Pre-Onboarding Internship?
https://www.wanted.co.kr/events/pre_ob_fe_12
Pre-Onboarding = Pre + Onboarding
As the name suggests, "Pre-Onboarding" means a step that comes even before the typical company onboarding process. Just as companies have onboarding for new hires, the goal here is to build the skills needed to hit the ground running — before you even join.
In my case, I was searching for internship opportunities to get some hands-on experience when I stumbled across this program. Of course, the Pre-Onboarding Internship isn't quite the same as working as an actual intern. But the curriculum covered a lot of topics I was genuinely interested in at the time, so I decided to apply.
How to Apply
- Required materials: pre-assignment, Wanted résumé
You need to complete a pre-assignment provided by Wanted and submit it via GitHub. For reference, the August cohort I participated in had a 3:1 applicant-to-acceptance ratio — meaning two out of every three applicants didn't make it…!
What Did We Do?
1) Company Assignments
Over four weeks, we worked on a new company-issued assignment each week. Assignments were announced on Tuesday afternoons and had to be submitted by midnight on Friday. The catch: you had to submit both an individual version and a team version. So within 3.5 days, you had to finish both — which was more demanding than it sounds.
Here's a quick overview of each week's assignment (with my personal GitHub links):
- Week 1: Refactor the To-Do List submitted as the pre-assignment (GitHub link)
- Week 2: Implement infinite scroll (GitHub link)
- Week 3: Build a search bar (GitHub link)
- Week 4: Data chart visualization (GitHub link)
Four assignments in total. They might look simple on paper, but even the small details gave me a lot to think about — each one had real learning value.
Looking back, some assignments overlap across different cohorts, which makes me think Wanted rotates through a fixed pool of company-issued tasks. So if you get stuck on something, searching for how previous cohorts approached the same assignment can be both educational and a time-saver!
2) Lectures
Lectures ran every Tuesday and Friday for three hours each, throughout the four weeks. As I mentioned earlier, the curriculum was the main reason I applied — and it lived up to my expectations.
The instructor was a junior developer who came from Wecode (위코드), a coding bootcamp. Their teaching style was excellent — they focused on what really mattered and explained concepts in a way that was easy to understand. The Q&A sessions were just as valuable.
A desire for better code
At SSAFY (Samsung Software Academy For Youth / 삼성 청년 소프트웨어 아카데미), the second semester is essentially "take everything you learned in the first semester and go build projects on your own." There were no code reviews, and I had no idea what "good code" actually looked like — so my code quality was stuck in place the whole time. I kept wondering, "Is this mess of code I've written really acceptable?" but never got a real answer before the semester ended.
This internship gave me the chance to finally address that question. I learned what good code looks like and explored the methodologies behind writing it. It felt like finally scratching an itch that had been bothering me for six months at SSAFY.
Here's a rough breakdown of the lecture curriculum:
- Week 1 – Session 1: Things to know for working as a team (Git, ESLint, Prettier, Husky, etc.)
- Week 1 – Session 2: CI/CD with GitHub Actions
- Week 2 – Session 1: Rendering optimization & Advanced Hooks
- Week 2 – Session 2: useEffect, Separation of Concerns
- Week 3 – Session 1: Cross-cutting Concerns and Context API
- Week 3 – Session 2: Dependency Inversion, TypeScript
- Week 4 – Session 1: Software Testing
- Week 4 – Session 2: Execution Context and Closures
A wide variety of topics — all aimed at writing code that is readable and maintainable.
3) Peer Learning & Collaboration
The Pre-Onboarding Internship is built around the principle of "peer learning." I'll admit I was a bit skeptical when I first heard that phrase, but working alongside teammates turned out to be surprisingly educational — seeing how they wrote code and communicated taught me a great deal.
Over four weeks, we completed four assignments. Three of them required both a team submission and an individual submission (the fourth was individual only). Each time we worked on a team assignment, I pushed myself to explain my code clearly and logically. And seeing teammates' code — sometimes taking a completely different approach, sometimes more robustly structured than mine — I was able to borrow the best parts and improve my own. That experience really drove home how important it is to read a lot of good code.
What Did I Learn?
If I had to sum up what I took away from this internship in a single phrase:
Designing software that's flexible in the face of change
That's it.
As I mentioned earlier, this internship was where I finally found answers to questions that had been nagging at me throughout my SSAFY projects: what is good code, and how do you write it?
Everything covered in the lectures — separation of concerns, dependency inversion, Context API, TDD — all of it was in service of "designing software that can adapt to change." Learning these concepts helped me understand what approaches lead to readable, maintainable code, and it made me want to keep studying and applying these ideas going forward.
Reflections
Collaboration is hard
Beyond the question of what makes good code, I entered this program asking myself: "How do I become a teammate who has a positive impact on the team?" I saw this as a great opportunity to build real collaboration experience — working with people I had never met before.
The answer to that question? I still haven't found it. I'm still figuring it out. Honestly, collaboration seems like something that never gets fully figured out. The people you work with keep changing, and the business context keeps shifting — so it seems like you just have to stay flexible and adapt to each situation as it comes.
Communicate intensely, decide quickly
On this particular team, I couldn't stand watching things stall in silence, so I naturally stepped up and ended up as the team lead. That meant channeling a lot of energy into making decisions quickly and dividing responsibilities fairly and efficiently — more as a leader than just a teammate.
Honestly, I'm not sure I was a great team lead. But it was a valuable experience for recognizing where I need to improve when I'm in a leadership role.
I'm someone who places a high value on fairness and efficiency — I tend to want to hear everyone out and find as much common ground as possible. But that approach can make me indecisive. I believe fast decision-making matters, and I came to realize that sometimes the right call is to move quickly toward the most appropriate solution, even if it means a minority opinion doesn't prevail.
There's so much left to learn
In Week 1, looking at my teammates' code hit me with a wave of self-doubt and a burning desire to grow. After three rounds of team projects, I found myself thinking, "Wow, my code has really been garbage this whole time," and genuinely questioning what I had actually learned at SSAFY.
That experience made me think: I really want to get good at this. Like, really good. So I started putting in much more effort — thinking carefully about how to split modules, what unit of responsibility each one should own, and whether a given piece of logic actually belonged in the file I was putting it in.
Looking back at the To-Do List code I submitted for the pre-assignment versus the refactored version I built on my own after the internship ended, the growth is genuinely visible. It's one of those rare cases where the improvement is concrete and measurable — and that felt really satisfying.
Closing Thoughts
It was a short program, but I learned and grew a tremendous amount. If you've ever found yourself asking the same questions I had — "What is good code? How do I write it?" — I'd strongly recommend the Pre-Onboarding Internship. The lectures are free, so you've really got nothing to lose.
I'll keep applying and building on what I learned here, working toward becoming a developer who can design software that adapts gracefully to change.