My experience preparing for Naver Boostcamp Web·Mobile 10, completing the Basic course, and taking the problem-solving test.
The password you enter is used to open, edit, and delete secret comments.
No comments yet.
I completed the Basic course of Naver Boostcamp Web·Mobile 10th cohort, and today is the first day of entering the Challenge phase.
In this post I want to describe the entire experience: preparing the application, completing the Basic course, and taking the problem‑solving test. I was never very confident about writing application essays, so I read many other posts when preparing mine. I hope this article can help people who are planning to apply for the next cohort.
Unlike last year, when applicants could choose to enter the Basic course through a coding test, this year everyone who meets the eligibility requirements must first submit an application and then enter the Basic course.
For about two weeks you experience Boostcamp in a light “preview” format similar to the Challenge stage. After completing all missions for two weeks, you take a problem‑solving test, which determines whether you advance to the Challenge phase.
My first interest in programming began during undergraduate classes where I learned Processing, Arduino, and web development. Since these courses focused on design, the main goal was often to produce interesting and unique visual outcomes.
However, beyond simply following instructions, I became curious about how the code itself was structured and how it worked internally. Repeated patterns and copied code began to bother me, which made me want to understand programming more deeply.
During the winter vacation of 2021 I took a bootcamp course through Codeit using a government training card. However, the curriculum was quite basic and did not significantly improve my programming skills.
Later, when I decided to pursue development more seriously in my senior year, I had already used my training card and did not yet have the skills required to enter well‑known bootcamps. I joined a paid bootcamp during my fourth year, but because of project issues and other limitations I ended up with incomplete CS knowledge, weak coding‑test skills, and an unfinished portfolio.
I was able to build frontend projects, but I still faced several problems:
Because of this, I felt that even if I managed to get a job, it would be difficult to grow properly. So I spent about six months improving my previous projects and studying coding tests.
At that point I knew clearly what I needed.
Boostcamp seemed like the environment that could provide all of these.
I spent about two weeks writing the first draft and revised it roughly three times before submitting.
At first I assumed that a portfolio would also be required, so I focused more on preparing my portfolio than the application essay. Later I learned that this cohort only required the written application, so I hurriedly finalized the application form.
I highlighted how developers can survive and grow in the age of AI. I also referenced key values of Boostcamp such as self‑directed learning, sustainable growth, strong fundamentals, and collaboration.
Rather than focusing on employment itself, I emphasized that Boostcamp is fundamentally a learning program and described the type of developer I hoped to become after completing it.
Because there was a strict character limit, I selected three experiences that best represented me and used one example per question.
Instead of mentioning several cases briefly, I tried to structure my answers as: "problem → process → solution" so that the story remained clear and specific.
During the Basic phase, participants complete one main mission each day (excluding weekends), along with smaller tasks, peer feedback, and a daily reflection.
Rather than solving problems with predetermined answers, participants must interpret the problem themselves, decide the scope of implementation, and submit their own solution.
For example, participants must decide:
Some people implemented only the core requirements, while others interpreted ambiguous parts differently and implemented multiple approaches.
There was no single correct answer. The goal was exploration and interpretation.
Although the submission deadline was flexible, it was helpful to keep pace with the schedule because later missions sometimes relied on earlier ones and peer feedback was more active earlier in the submission order.
In our group, once submissions fell below roughly 8th–10th place in order, the amount of peer feedback dropped significantly.
Participants compared their answers and exchanged feedback.
At first everyone approached the tasks very differently, but over time the overall quality improved as we absorbed good ideas from each other.
Personally I focused on readability and documentation quality, since I value user‑centered design. However, because I lacked formal CS and backend experience, I struggled with architecture and system design.
Through peer feedback I was able to learn how other participants approached algorithms, efficiency, and technical reasoning.
Most missions were too complex to solve completely alone.
Rather than avoiding AI tools, I tried to approach them as part of being a developer who works alongside AI.
Instead of simply asking "How do I do this?" I first defined the problem and wrote out my reasoning, then asked AI questions like:
"I am trying to solve this problem in this way — is there a better approach?"
This helped improve the quality of my questions and my understanding.
The environment where others could review and critique my code was extremely valuable, and it helped me see my own level more objectively.
After finishing the Basic course, participants take a problem‑solving test.
Since I had very little coding‑test experience and the format had changed this year, it was difficult to estimate the difficulty level. I prepared mainly by solving past Kakao coding‑test problems.
The exam included a mix of multiple‑choice questions, written answers, and coding problems. Internet searches were not allowed, but reference documents such as official language documentation were provided.
Because my CS knowledge was limited, I solved the problems I could as quickly as possible and skipped the rest.
Most participants solved about two problems, and I also finished with two solutions.
The difficulty itself was not extremely high; the main challenge was carefully reading long problem descriptions and identifying the actual requirements.
Although it was impossible to learn everything in two weeks, I felt that my way of thinking about problems improved significantly.
In UX design, defining the problem is always the first step. However, when coding I often skipped the design stage and jumped straight into implementation.
Through this experience I realized once again how important proper design is.
The Challenge phase begins today. I am nervous, but I hope I can complete it without giving up and eventually write another retrospective.
