The Philosophy of AI-Native Hiring

In January 2026, Musinsa began hiring AI-native engineers and completely redesigned its existing coding test. Since AI agents can solve short algorithm problems in seconds, the company decided that the ability to judge what to build now matters more than implementation skill.

The existing responses fell into three categories. Banning AI is out of touch with reality, ignoring it has already been rendered powerless, and freezing hiring itself stops new-grad recruiting altogether. Musinsa didn't stop there, and decided to build its own evaluation standard fit for the AI era.

The core issues were fairness and designing for ambiguity. If each candidate uses their own local environment, the gap between applicants who have ChatGPT Pro, Claude Max, and IDE integration and those who don't becomes a gap in capital, not a gap in tools. So Musinsa changed the structure to provide every candidate with an equal AI environment and to actually assess their thinking ability.

The problem was that if the task is too specific, it hints to the AI, and if it's too vague, the signal disappears. The solution was to design it like open source.

• Present what to build, but leave how to build it open.
• Have candidates document build, run, and test instructions at README level on their own.
• The evaluation system reads that documentation and directly runs and verifies the project.

The actual assignment was a university course registration system. Candidates were only given conditions—student lookup, course lookup, course registration, course cancellation, timetable lookup, an 18-credit cap, time conflicts, and the requirement that if 100 people apply simultaneously for a course with only 1 slot remaining, exactly 1 person must succeed—and were left free to decide everything else. What this reveals isn't simple implementation, but the ability to interpret requirements and turn them into a system.

The hidden depth shows up especially in concurrency. Course-level locking alone can preserve the enrollment cap, but if the same student applies to two courses simultaneously, the credit limit or time-conflict rule can break. That's why both course-level locks and student-level locks are needed, and if the lock order is wrong, it can even cause a deadlock.

Data design was also part of the test. Candidates had to generate 10,000+ students, 500+ courses, and 100+ professors within 1 minute, and had to design the relationships so that timetable conflicts and seat competition would actually surface. It wasn't enough for the seeder to just run—they had to build a world worth testing.

Evaluation is split into a 3-Tier model.

• Tier 1 - Make it Work: Does it build, run, and pass health checks?
• Tier 2 - Basic Features: Do the APIs, business rules, and concurrency control actually work?
• Tier 3 - Deep Thought: This looks at prompt history, requirements-gathering documentation, data design, code quality, test coverage, and even git history, to determine whether the candidate just delegated the problem or wrote it while understanding it.

In the end, the person Musinsa is looking for isn't someone who had AI do it for them, but someone who expands their thinking together with AI. As implementation keeps getting cheaper, what now makes the difference is the power to decide what to implement and the ability to prove that decision through documentation and code.