1. "기능 구현 다 했는데 왜 탈락이죠?"
기술 역량 평가를 진행하면서 가장 많이 듣는 질문입니다. "요구사항 다 구현했고, 버그도 없는데 왜 탈락인가요?"
냉정하게 말하면, 기능 구현은 기본(Baseline)입니다. 기술 과제는 "네가 이걸 만들 수 있니?"를 묻는 게 아니라, "너랑 같이 일해도 괜찮겠니?"를 묻는 과정이기 때문입니다.
오늘은 평가자 입장에서 "이 사람은 무조건 합류시키고 싶다"와 "이 사람은 좀..."이 갈리는 결정적 포인트들을 정리해 드립니다.
1.5. 흔한 실수 - 오버 엔지니어링 (Over-engineering)
주니어 개발자들이 가장 많이 하는 실수입니다. "나 이만큼 아키텍처 잘 알아!"를 뽐내고 싶어서, 투두 리스트 하나 만드는데 Clean Architecture, DDD, RxJS를 다 때려넣습니다.
평가자의 생각: "이 사람, 실제로 간단한 기능 하나 만드는 데 3일 걸리겠네."
Best Practice:
- 과제의 규모에 맞는 아키텍처를 선정하세요.
- "원래는 이렇게 해야 하지만, 과제 규모상 MVP 패턴으로 했습니다"라고 주석이나 문서에 적는 것이 백배 낫습니다.
2. 과제 전형 (Take-home Assignment) - 코드가 아니라 문서를 본다
많은 지원자가 App.js를 얼마나 예쁘게 짰는지에 목숨을 겁니다.
하지만 평가자가 가장 먼저 보는 파일은 README.md입니다.
탈락하는 유형:
- 실행 방법(npm start)조차 안 적혀 있음.
- "그냥 짜봤습니다" 식의 무미건조한 커밋 메시지 (
update code). - 환경 변수(
.env) 설정법이 누락되어 실행 불가.
합격하는 유형:
- 실행 가이드: 한 번의 복붙으로 실행되게 해둠.
- 기술적 의사결정: "왜 Redux 대신 Zustand를 썼는지", "왜 폴더 구조를 이렇게 잡았는지"를 문서화함. 단순 구현보다 설계의 근거가 훨씬 중요합니다.
- 트러블슈팅: 과제를 하다 막힌 부분과 어떻게 해결했는지(혹은 못 했는지)를 솔직하게 적음.
"코드는 혼자 짜지만, 제품은 같이 만듭니다." 문서를 못 쓰는 개발자와 일하고 싶은 사람은 없습니다.
문서화 예시 (Good README.md)
# Project Name
## 실행 방법
\`\`\`bash
cp .env.example .env
npm install
npm run dev
\`\`\`
## 기술적 의사결정
- **Zustand 사용 이유:** Redux는 보일러플레이트가 너무 많고, Context API는 렌더링 최적화가 어렵습니다. 이 프로젝트 규모에서는 Zustand가 가장 효율적이라 판단했습니다.
- **폴더 구조:** 기능(Feature) 단위로 분리하여 응집도를 높였습니다.
## 트러블슈팅
- **문제:** API Rate Limit에 걸림.
- **해결:** 로컬 캐싱을 적용하여 API 호출 횟수를 줄임.
2.5. 라이브 코딩 기술 평가의 비밀 (Live Coding)
과제 전형을 통과하면 보통 라이브 코딩을 합니다. 여기서 중요한 건 "문제를 푸는 것"보다 "사고 과정(Think Aloud)을 보여주는 것"입니다.
꿀팁:
- 입 다물고 코딩하지 마세요. "지금 배열을 순회하려고 하는데요..."라고 계속 중얼거리세요.
- 질문하세요. "입력값의 범위는 어떻게 되나요?" "엣지 케이스는 무시해도 되나요?"
- 막히면 도움을 요청하세요. 리뷰어는 당신을 탈락시키려는 저승사자가 아니라, 미래의 동료입니다. "이 부분에서 막혔는데 힌트 좀 주실 수 있나요?"는 감점 요인이 아닙니다.
3. 라이브 코딩 (Live Coding) - 침묵은 금이 아니라 독이다
라이브 코딩의 목적은 '문제를 푸는 것'이 아니라 '푸는 과정을 보여주는 것'입니다.
탈락하는 유형:
- 문제 받자마자 아무 말 없이 키보드부터 두드림. (30분 뒤에 엉뚱한 거 만들고 있음)
- 막혔을 때 힌트를 줘도 "아뇨 제가 할게요"라며 고집 피움.
합격하는 유형:
- 질문부터 함: "입력값의 범위는 뭔가요?", "엣지 케이스 처리는 필요한가요?" 하며 요구사항을 명확히 함.
- 말로 코딩함: "지금은 O(N^2)으로 먼저 짜고, 나중에 최적화하겠습니다"라고 자신의 의도를 중계함.
- 힌트를 잘 받아먹음: 리뷰어의 힌트를 "같이 문제를 해결하는 시그널"로 받아들임.
평가자는 '슈퍼 코더'를 뽑는 게 아니라 '대화가 통하는 동료'를 뽑고 있습니다.
4. 시스템 설계 (System Design) - 정답은 없다, 근거만 있을 뿐
"유튜브를 설계해 보세요." 이 질문에 정답이 있을까요? 없습니다.
탈락하는 유형:
- 특정 기술 스택 하나만 고집함. ("무조건 NoSQL 써야 해요. 요즘 힙하거든요.")
- 확장성(Scalability) 고려 없이 기능만 나열함.
합격하는 유형:
- 트레이드오프(Trade-off)를 논함: "SQL은 정합성이 좋지만 확장이 어렵고, NoSQL은 확장은 쉽지만 정합성 관리가 필요합니다. 이 시스템은 조회 위주니까 NoSQL을 선택하겠습니다."
- 가정(Assumption)을 세움: "DAU가 1,000만 명이라고 가정하고 설계하겠습니다."
모든 기술 선택에는 장단점이 있습니다. 그걸 알고 선택하는지와 모르고 유행따라 선택하는지는 천지차이입니다.
4.5. 리뷰어를 내 편으로 만드는 대화법
기술 평가는 "나 혼자 잘났음"을 뽐내는 자리가 아닙니다. 리뷰어를 "내 동료"로 만드는 과정입니다.
- 두괄식 답변: "결론부터 말씀드리면 X입니다. 왜냐하면 Y이기 때문입니다." (리뷰어의 피로를 줄여줍니다.)
- 모르면 모른다고 하기: "그 부분은 정확히 모르겠습니다. 하지만 제 추측으로는..." (솔직함이 낫습니다. 아는 척하다 걸리면 치명상입니다.)
- 역질문: "팀에서는 코드 리뷰 문화를 어떻게 유지하고 계신가요?" (관심도를 보여주는 가장 좋은 방법입니다.)
5. 마무리 - 기술 역량 평가는 시험이 아니라 협업 시뮬레이션이다
기술 평가를 '정답을 맞춰야 하는 시험'이라고 생각하면 긴장되고 굳어버립니다. 하지만 기술 평가는 "우리가 서로 기술적으로 잘 맞을까?"를 확인하는 협업 시뮬레이션에 가깝습니다.
- 과제: 내 코딩 스타일과 문서화 능력을 매력적으로 어필하세요.
- 라이브 코딩: 내가 얼마나 대화가 잘 통하는 사람인지 보여주세요.
- 시스템 설계: 내가 얼마나 깊게 고민해봤는지(Insight)를 뽐내세요.
탈락했다고 해서 당신이 실력 없는 개발자인 건 아닙니다.
그저 그 팀의 핏(Fit)과 안 맞았을 뿐입니다.
오늘도 git commit을 날리는 여러분을 응원합니다.