I had planned to write technical posts mainly in English, but I am writing this acceptance retrospective in Korean in the hope that it might help later cohorts or juniors, even a little.

SWMaestro, along with BOB, was a talent development program I had heard about from seniors since my freshman year. During the previous cohort’s application period, both my algorithm skills and project quality were vague, so I remember stopping midway through the application and deciding to aim for the 14th cohort instead. This time, I felt I could explain my projects properly and bring my coding-test performance up to a stable minimum.

Overall Preparation

Acceptance retrospectives can easily become only a record of the result. What mattered more in this process was not how many keywords I memorized, but how clearly I could explain the projects I had built. This post captures how I prepared separately for the coding tests and interviews, and what kinds of questions I expected to defend.

I organized my preparation into three tracks.

  • For the coding tests, I focused less on solving every problem and more on securing the problems I could implement without mistakes.
  • For the interview, I prepared to explain my projects from structure, technology choices, failure modes, and possible improvements.
  • For CS and backend fundamentals, the goal was not keyword memorization. I wanted to be able to keep answering when follow-up questions came in.

Looking back, the most important thing was not flashy knowledge but organized explanation. Especially in the project interview, “I used this technology” mattered less than “why I used it, and where I would look if something broke.”

Coding Tests

The tests were held on Programmers for two hours. The format was 4 algorithm problems and 1 SQL problem. The first round was invalidated once because of a server issue, and then it was held again in the same format.

What I Felt From Round 1

Round 1 had a strong implementation and simulation flavor. There were simple implementation, coordinate-plane traversal, combination search, DFS-like search, and a SQL problem with string-processing characteristics. The ideas themselves were not extremely novel. The hard part was implementing them within the time limit without missing conditions.

These are the types I felt I needed to secure.

Type Preparation point
Implementation / simulation Split conditions into explicit states and write edge cases first
Brute force / combinations Quickly judge whether the input size allows brute force
DFS / backtracking Define state and visited conditions clearly
SQL Review string functions in addition to SELECT, JOIN, and GROUP BY

For implementation problems in particular, even if you know the direction, mistakes appear once the code gets long. So if I were preparing for SWMaestro again, I would spend more time solving implementation-heavy problems with a timer than digging into new advanced algorithms.

What I Felt From Round 2

Round 2 also had 4 algorithm problems and 1 SQL problem. The set included implementation, DP, queue-based simulation, and a graph problem mixing Dijkstra and DP. Personally, handling edge cases in the DP problem was harder than the graph problem.

Both rounds felt tight on time. Roughly two solved problems felt like the stable line, and I heard from a mentor that many trainees in Round 2 only solved Problem 1 and SQL clearly. If you have steadily studied the essential types for job coding tests, the test itself is not unfamiliar. But if your implementation stamina is weak, it can shake you more than expected.

If I prepared again, I would prioritize this order.

  1. Solve implementation and simulation problems regularly, even if only briefly
  2. For DP, focus on state definition and edge cases more than only the recurrence
  3. Keep BFS, DFS, and Dijkstra templates comfortable enough to write quickly
  4. Solve at least one SQL problem each using JOIN, GROUP BY, UNION, and string functions

Interview Preparation

At first, I spread the interview topics too widely, which made the notes messy. Later, I grouped them like this. It was much more useful.

1. Project Explanation

The biggest preparation area was my own projects. I expected the interviewers to dig deeply into the projects I presented.

For each project, I prepared answers to these questions.

  • What problem was this project trying to solve?
  • Which part did I own?
  • Why did I choose that technology stack?
  • What did the DB schema, API, and deployment structure look like?
  • If an incident happened, what would I check first?
  • If I built it again now, what would I change?

For example, for a Redis-based project, I prepared the caching target, DB fallback when Redis fails, Base62 short URL generation, MariaDB character set configuration, Docker Compose depends_on, and the CSV parsing flow as one connected explanation. It was not enough to say “I used Redis.” I needed to explain why Redis was necessary and what would happen if Redis went down.

For a GPT-based project, I prepared not only implementation details but also business model, cost structure, and user acquisition. The SWMaestro interview did not feel like a pure technical interview. It also checked whether a person could carry a team project to the end.

2. Backend Fundamentals

For backend fundamentals, I did not try to go infinitely deep. I focused on the range connected to the technologies I had actually used.

Area What I reviewed
Spring / Spring Boot Dependency management, embedded server, initial setup, Spring Security and CORS
REST API URI design, CRUD, JSON response, common frontend/backend integration issues
Testing When to use JUnit5, Spock, and mocking
Database Normalization, RDB vs NoSQL, MySQL/MariaDB/PostgreSQL/Redis characteristics
Cache Redis caching targets, session/API response caching, fallback strategy
Docker / deployment Container communication, Docker Compose, EC2 deployment, environment configuration
Git / collaboration Branch rules, commit units, pull/review habits

I used to try to memorize this kind of material as a list of keywords, but in interviews that becomes obvious quickly. Questions do not always stop at “what is normalization?” They can continue into “why was this schema acceptable for your project?” Connecting fundamentals back to projects was much better.

3. Collaboration and Leadership

Collaboration questions also felt important. The expected questions were roughly like these.

  • What would you do if a teammate disagreed with you?
  • What would you do if the initial plan could no longer be executed?
  • How would you communicate with a teammate using a different technology stack?
  • If you were the leader, how would you manage schedule and backlog?

I prepared answers around making the initial plan detailed, while reflecting changed requirements into the backlog and timeline during implementation. When teammates used different stacks, I planned to document contact points such as API contract, data format, CORS, and security, and check likely frontend/backend merge issues early.

In-depth Interview

I heard that the atmosphere and question direction differed depending on the division and interviewers. Division 1, where I interviewed, had a balanced mix of technical and personality questions. Personality questions were often common questions given to all five candidates.

The most memorable question came near the end. They asked which candidate in the room I would want to team up with, and who seemed suitable as a leader. It was difficult to answer unless you had listened to the other candidates carefully. Some people answered vaguely, while others chose a specific candidate and gave a reason.

The technical interview went deep around the project I had presented. If a project looked weak, they seemed to ask more persistently about planning intent and technology choices. For the coding test, printed copies of the Round 1 and Round 2 problems were handed out, but only a few coding-test questions came up across all candidates. Still, the interviewers knew the Programmers submission history, submitted code, and partial scores, so it was not something you could hand-wave away.

In conclusion, if you thoroughly understand the projects you built and prepare for follow-up questions on the technologies you used, the interview is not especially hard to answer. After passing both coding tests, the remaining question felt closer to how clearly I could explain my own experience.

Interview Takeaway

In the end, preparing for SWMaestro was not about collecting impressive technology names. It was about reaching the point where I could explain what I had actually built, including its structure, failure modes, and what I would redesign today. Once that was clear, the interview became much less intimidating.