나는 12개의 Skills-Based Hiring Assessments를 수행했으며, 모두가 속하는 3가지 유형을 소개합니다
I’m happy to translate the article for you, but I’ll need the full text you’d like translated (the body of the post). Could you please paste the article content here? I’ll keep the source line exactly as you provided and translate the rest into Korean while preserving all formatting, markdown, and technical terms.
개요
몇 주 전, 저는 Skills‑Based Hiring Is Real Now에 대해 글을 썼었습니다. 그 이후 저는 개인적으로 9개 회사에서 12개의 평가를 직접 보았습니다 — 어느 정도는 연구적 호기심 때문에, 또 어느 정도는 실제로 관심 있던 포지션에 붙어 있었기 때문입니다.
이제 저는 “스킬 기반” 채용 평가의 90 %가 단 세 가지 유형으로 나뉜다는 확신이 섰습니다. 어떤 유형을 보게 될지 알게 되면, 20 분만에 사전 준비를 마치고 훨씬 차분한 상태로 평가에 임할 수 있습니다.
Flavor 1: 실시간 코딩 패턴 매치
What it actually is: 보통 CoderPad 또는 HackerRank에서 진행되는 35‑60분 길이의 실시간 세션으로, 1‑2개의 문제를 풀면서 생각을 큰 소리로 설명하고 인터뷰어는 대부분 음소거 상태인 형태입니다.
How to recognize it before the test
- 캘린더 초대에 “Technical Screen” 또는 “Coding Pair”라고 적혀 있음.
- 예상 소요 시간이 45‑60분 (45 = 문제 1개, 60 = 문제 2개).
- 초대에 명시된 도구가 CoderPad, HackerRank, 혹은 “shared editor”.
What they are actually scoring
- 첫 번째 실행에서 컴파일되는 코드를 작성했는지 여부 (~25 % 점수).
- 코딩하면서 말했는지 여부 (이것이 매우 중요 — 조용히 풀면 완성해도 감점됨).
- 코드를 작성하기 전에 한두 개의 명확화 질문을 했는지 여부.
- “시간 복잡도는?” 같은 후속 질문에 당황하지 않고 답했는지 여부.
What to prep
- 시험 당일 아침에 두 개의 워밍업 문제를 풀어보기 (전날 밤이 아니라 최근에 푼 것이 양보다 중요).
- “시작하기 전에 두 가지를 명확히 하고 싶습니다” 라는 오프너를 준비하기.
- 큰 소리로 생각하는 데 익숙해지기 — 혼자 산책하면서 생각 과정을 내레이션하는 연습을 해보세요.
Flavor 2: 제한된 시간 박스가 있는 테이크‑홈 프로젝트
실제 의미: 이메일로 전달되는 문제 진술서이며, 보통 작은 CRUD‑형 프로젝트입니다. 여기에는 “4시간을 초과하지 말 것” 혹은 “5일 이내에 전달할 것”이라는 명시적인 지시가 포함됩니다.
어떻게 구분할 수 있나요
- 이메일에 문제 진술서와 GitHub 저장소 템플릿이 포함되어 있음.
- “X일 이내에 전달”하지만 동시에 “Y시간을 초과하지 말 것”이라는 제한이 있음.
- 해당 역할은 중급‑시니어 수준의 개인 기여자(IC)임.
실제로 평가하는 항목 (우선순위)
- 시간 제한을 지켰는가? 기업들은 4시간 제한인데 12시간이 걸린 것처럼 보이는 제출물을 점점 더 의심합니다. 제가 물어본 세 기업 모두 과도하게 다듬어진 제출물에 감점을 준다고 했습니다. 금도금은 점수를 낮추는 요인이지, 높이는 요인이 아닙니다.
- 핵심 요구사항을 구현했는가, 아니면 인프라에만 파고들었는가?
- README가 충분히 명확한가? 클론하고 실행해서 90초 안에 검증할 수 있어야 합니다.
- 테스트 케이스가 실용적인가? 완전성을 추구하기보다 실용성을 중시합니다. 두세 개의 좋은 테스트가 30개의 사소한 테스트보다 낫습니다.
준비해야 할 것
- 회사가 사용하는 스택에 맞춘 보일러플레이트 저장소 준비:
.gitignore, README 골격, 기본 테스트 설정 등을 포함합니다. 매번 재사용하세요. - README에 넣을 “시간이 더 있다면 할 일” 섹션을 미리 작성해 두세요. 3‑5개의 솔직한 항목을 포함합니다.
- 추가할 것보다 제거할 것을 결정하는 연습을 하세요. 이 테스트가 보상하는 스킬은 바로 범위 관리(스코프 디시플린)입니다.
Flavor 3: 비동기 “실제 작업” 시뮬레이션
실제 내용: 회사 실제 제품의 작은 부분을 샌드박스 형태로 제공받습니다. 대표적인 작업—버그 수정, 작은 기능 추가, 마이그레이션 작성—을 수행하도록 요청받습니다. 경우에 따라 급여가 지급되기도 하고(~$100‑300), 안 될 수도 있습니다.
어떻게 구분할까
- 작업 설명에 “우리 실제 코드베이스” 혹은 “우리 시스템의 샌드박스 버전”이라고 언급되어 있다.
- 기간은 길지만(보통 1 주) 실제 작업 예상 시간은 짧다(3‑5 시간).
- 담당자는 리크루터가 아닌 실제 엔지니어이다.
실제로 평가하는 항목
- 익숙하지 않은 코드베이스에서도 무작위로 움직이지 않고 작업할 수 있는가?
- 동료처럼 질문을 하는가, 후보자처럼 질문을 하는가? “X를 발견했는데, 의도된 건가요, 아니면 버그의 일부로 처리해야 하나요?”가 “이걸 어떻게 실행하나요?”보다 좋다.
- PR 설명을 작성해, 당신이 방에 없더라도 다른 엔지니어가 검토할 수 있게 했는가?
- 트레이드‑오프를 정당화할 수 있는가? X 대신 Y를 하지 않은 이유를 물을 것이다. 답변을 준비하라.
준비 방법
- 전날 밤에 코드를 간단히 훑어본다. 문제를 해결하려고 하지 말 것. 테스트 위치, 빌드 명령, 프로젝트 구조 등을 파악한다.
- PR 설명을 이미 팀에 합류한 것처럼 작성한다. “고려한 트레이드‑오프” 섹션을 포함한다.
- 명확한 질문을 할 경우, 실제 PR에서 쓰는 형식대로 작성한다: 상황을 한 문장으로 제시, 구체적인 질문 하나, 답변을 못받았을 때 할 행동을 한 줄로 적는다.
마케팅이 말하는 것과 달리 이 테스트들이 전혀 평가하지 못하는 것
- 당신의 순수한 알고리즘 실력(고립된 상태).
- 이력서에 적힌 경력 연수.
- 학위.
- 당신이 얼마나 “열정적인지”.
- 성격 적합성(그것은 다른 라운드).
치트 코드: 어떤 유형인지 물어보기
이것이 가장 큰 레버리지 포인트입니다. 리크루터가 초대를 보낼 때, 한 문장으로 답하세요:
“준비를 도와줄 간단한 질문인데요 — 이 과정이 주로 라이브 코딩 세션인가요, 테이크‑홈 과제인가요, 아니면 샌드박스형 실무 과제인가요?”
지난 6개월 동안 매번 이 질문을 했습니다. 모든 리크루터가 답변했습니다. 대부분은 놀라울 정도로 구체적으로 답했어요(예: “테이크‑홈 과제입니다. 금요일 아침에 과제 설명을 드릴 것이고, 목표 시간은 4시간이며, 평가는 PR 품질과 README 명확성을 기준으로 합니다”). 이 한 질문만으로 블랙 박스를 명확한 준비 목표로 바꿀 수 있습니다.
스킬 기반 채용이 어떻게 제안을 받을 사람을 결정하는지에 대한 더 넓은 패턴은 원본 글을 참고하세요: Skills‑Based Hiring Is Real Now.
여기를 활용하는 방법에서는 기업 측 메커니즘을 자세히 설명합니다.
그리고 제가 직접 경험한 8가지 구체적인 테스트 유형에 대해 더 깊이 읽고 싶다면, The 8 Skills Tests Companies Are Actually Using in 2026에서 전체 버전을 확인하세요.