개발자 면접 질문 100개와 탈락하는 답변 vs 합격하는 답변
들어가며: 답은 정해져 있지 않다, 접근법이 중요하다
5년간 200명이 넘는 개발자를 면접했습니다.
같은 질문을 해도, 어떤 사람은 합격하고 어떤 사람은 탈락합니다. 능력이 비슷해도, 답변 방식에 따라 결과가 달라집니다.
이 글은 실제 면접에서 나온 100가지 질문과, 각 질문에 대한 탈락/합격 답변 비교입니다.
면접관이 무엇을 보는지, 어떤 답변이 좋은 인상을 주는지 알려드립니다.
면접관이 보는 5가지
면접에서 평가하는 것:
- 기술 역량 - 실제로 코드를 작성할 수 있는가?
- 문제 해결 능력 - 모르는 것을 어떻게 해결하는가?
- 커뮤니케이션 - 설명을 명확하게 하는가?
- 성장 가능성 - 배우고 발전하는가?
- 팀 핏 - 함께 일하고 싶은 사람인가?
정답을 외우는 게 아니라, 생각하는 과정을 보여주는 것이 중요합니다.
PART 1: 기술 기초 질문 (1-25)
JavaScript/TypeScript (1-10)
질문 #1: var, let, const의 차이를 설명해주세요.
❌ 탈락 답변:
"var는 옛날 거고, let이랑 const는 최신 거예요. const는 상수고 let은 변수예요."
문제점:
- 피상적인 설명
- 핵심 차이를 모름
- 실제 이해 없이 외운 느낌
✅ 합격 답변:
"세 가지 주요 차이가 있습니다.
첫째, 스코프입니다. var는 함수 스코프고, let과 const는 블록 스코프입니다.
예를 들어:
if (true) {
var x = 1
let y = 2
}
console.log(x) // 1 (접근 가능)
console.log(y) // ReferenceError (접근 불가)
둘째, 호이스팅 동작이 다릅니다. var는 선언이 끌어올려지고 undefined로
초기화되지만, let과 const는 TDZ(Temporal Dead Zone)에 있어서
선언 전 접근 시 에러가 발생합니다.
셋째, const는 재할당이 불가능합니다. 다만 객체나 배열의 경우
내부 속성은 변경 가능합니다.
실무에서는 기본적으로 const를 사용하고, 재할당이 필요한 경우만
let을 사용합니다. var는 레거시 코드에서만 볼 수 있습니다."
왜 합격:
- 구체적인 예시 제공
- 실무 관점 언급
- 깊은 이해 (TDZ 같은 개념)
질문 #2: 클로저(Closure)가 무엇인가요?
❌ 탈락 답변:
"함수 안에 함수가 있는 거요."
✅ 합격 답변:
"클로저는 함수가 선언될 때의 렉시컬 환경을 기억하는 것입니다.
예를 들어:
function createCounter() {
let count = 0
return function() {
return ++count
}
}
const counter = createCounter()
console.log(counter()) // 1
console.log(counter()) // 2
여기서 내부 함수는 외부 함수의 count 변수에 접근할 수 있습니다.
createCounter가 실행을 마쳐도 count는 메모리에 남아있죠.
실무에서는 데이터 은닉, 모듈 패턴, 이벤트 핸들러 등에서 자주 사용합니다.
다만 클로저를 과도하게 사용하면 메모리 누수가 발생할 수 있어서
주의가 필요합니다."
질문 #3: Promise와 async/await의 차이는?
❌ 탈락 답변:
"async/await가 최신이고 더 좋아요."
✅ 합격 답변:
"둘 다 비동기 처리를 위한 방법이고, async/await는 Promise 위에
만들어진 syntactic sugar입니다.
Promise:
fetchUser()
.then(user => fetchPosts(user.id))
.then(posts => console.log(posts))
.catch(error => console.error(error))
async/await:
try {
const user = await fetchUser()
const posts = await fetchPosts(user.id)
console.log(posts)
} catch (error) {
console.error(error)
}
async/await의 장점은:
1. 동기 코드처럼 읽힘
2. try-catch로 에러 처리 가능
3. 디버깅이 쉬움
하지만 병렬 처리가 필요한 경우는 Promise.all이 더 적합합니다:
const [users, posts] = await Promise.all([
fetchUsers(),
fetchPosts()
])
상황에 따라 적절히 선택해서 사용합니다."
질문 #4-10: 빠른 기술 질문들
| 질문 | 탈락 답변 | 합격 답변 |
|---|---|---|
| #4: == vs === | "=== 쓰면 돼요" | "==는 타입 변환 후 비교, ===는 타입까지 비교. '0' == 0은 true지만 '0' === 0은 false" |
| #5: event bubbling | "잘 모르겠어요" | "이벤트가 자식에서 부모로 전파되는 것. stopPropagation()으로 중단 가능" |
| #6: this 키워드 | "현재 객체요" | "실행 컨텍스트에 따라 달라짐. 일반 함수는 전역, 메서드는 객체, 화살표 함수는 상위 스코프" |
| #7: 호이스팅 | "위로 올라가는 거요" | "변수/함수 선언이 스코프 최상단으로 이동하는 것. 함수 선언식은 전체가, 변수는 선언만" |
| #8: prototype | "상속 관련이에요" | "객체 간 속성/메서드를 공유하는 메커니즘. __proto__로 체인 형성" |
| #9: map vs forEach | "비슷해요" | "map은 새 배열 반환, forEach는 undefined 반환. map은 함수형, forEach는 절차형" |
| #10: shallow copy vs deep copy | "복사 방식이 달라요" | "shallow는 1단계만, deep은 중첩된 객체까지 복사. JSON 방법, lodash cloneDeep 등 사용" |
React/Frontend (11-20)
질문 #11: useState와 useEffect를 설명해주세요.
❌ 탈락 답변:
"useState는 상태 관리하고, useEffect는 부수효과 처리해요."
✅ 합격 답변:
"useState는 컴포넌트의 상태를 관리하는 훅입니다:
const [count, setCount] = useState(0)
상태가 변경되면 컴포넌트가 리렌더링됩니다. 함수형 업데이트를
사용하면 이전 상태를 기반으로 안전하게 업데이트할 수 있습니다:
setCount(prev => prev + 1)
useEffect는 사이드 이펙트를 처리합니다:
useEffect(() => {
// 실행할 코드
return () => {
// 클린업 함수
}
}, [dependencies])
의존성 배열이 비어있으면 마운트 시 1회, 없으면 매 렌더링마다,
특정 값이 있으면 그 값 변경 시 실행됩니다.
클린업 함수는 이벤트 리스너 제거, 타이머 정리 등에 사용합니다.
이를 통해 메모리 누수를 방지할 수 있습니다."
질문 #12: Virtual DOM이 무엇이고 왜 빠른가요?
❌ 탈락 답변:
"가상의 DOM이에요. 그래서 빨라요."
✅ 합격 답변:
"Virtual DOM은 실제 DOM의 경량 복사본입니다.
React는 상태 변경 시:
1. 새로운 Virtual DOM 생성
2. 이전 Virtual DOM과 비교 (diffing)
3. 변경된 부분만 실제 DOM에 반영 (reconciliation)
이게 빠른 이유는:
1. DOM 조작은 비용이 큼 (reflow, repaint)
2. Virtual DOM은 JavaScript 객체라 비교가 빠름
3. 배치 업데이트로 DOM 조작 최소화
다만 항상 빠른 건 아닙니다. 단순한 앱이나 정적 콘텐츠는
vanilla JS가 더 빠를 수 있습니다. Virtual DOM의 진짜 장점은
선언적 프로그래밍과 상태 관리의 단순화입니다."
질문 #13-20: React 핵심 개념
| 질문 | 핵심 포인트 |
|---|---|
| #13: key prop의 역할 | "리스트 렌더링 시 각 항목 식별. 재정렬 시 효율적인 업데이트 가능. index를 key로 쓰면 안 되는 이유 설명" |
| #14: controlled vs uncontrolled component | "controlled는 React 상태로 관리, uncontrolled는 DOM 직접 접근. form 예시로 설명" |
| #15: React.memo | "props 비교로 불필요한 리렌더링 방지. 하지만 비교 비용도 있어서 성능 측정 후 사용" |
| #16: useCallback vs useMemo | "useCallback은 함수 메모이제이션, useMemo는 값 메모이제이션. 의존성 배열 중요" |
| #17: Context API | "props drilling 해결. 하지만 과도한 사용은 성능 이슈. 적절한 분리 필요" |
| #18: CSR vs SSR | "CSR은 초기 로딩 느림, SEO 불리. SSR은 초기 빠름, SEO 유리. Next.js로 하이브리드 가능" |
| #19: useReducer | "복잡한 상태 로직에 적합. Redux와 비슷한 패턴. 여러 상태를 하나로 관리" |
| #20: 리렌더링 최적화 | "memo, useCallback, useMemo, key 최적화, 컴포넌트 분리, 상태 끌어올리기 최소화" |
Backend/Database (21-25)
질문 #21: RESTful API란 무엇인가요?
❌ 탈락 답변:
"HTTP로 API 만드는 거요."
✅ 합격 답변:
"REST는 Representational State Transfer의 약자로,
자원을 URI로 표현하고 HTTP 메서드로 조작하는 아키텍처 스타일입니다.
핵심 원칙:
1. 자원 식별: /users/123
2. HTTP 메서드: GET(조회), POST(생성), PUT(전체 수정),
PATCH(부분 수정), DELETE(삭제)
3. 무상태성: 각 요청은 독립적
4. 캐시 가능: HTTP 캐싱 활용
5. 계층화: 클라이언트는 서버 구조 몰라도 됨
실제 예시:
GET /api/users # 목록 조회
GET /api/users/123 # 상세 조회
POST /api/users # 생성
PUT /api/users/123 # 수정
DELETE /api/users/123 # 삭제
다만 완벽한 RESTful API는 구현이 어렵고, 실무에서는
pragmatic하게 접근합니다. GraphQL 같은 대안도 있습니다."
질문 #22: SQL Injection을 어떻게 방지하나요?
✅ 합격 답변:
"SQL Injection은 악의적인 SQL 코드를 주입하는 공격입니다.
위험한 코드:
const query = `SELECT * FROM users WHERE id = ${userId}`
방지 방법:
1. Prepared Statement (가장 중요):
const query = 'SELECT * FROM users WHERE id = ?'
db.query(query, [userId])
2. ORM 사용:
User.findById(userId)
3. 입력 검증:
if (!/^\d+$/.test(userId)) throw new Error()
4. 최소 권한 원칙:
DB 계정에 필요한 권한만 부여
5. 에러 메시지 숨김:
프로덕션에서는 상세 에러 노출 금지
실무에서는 ORM을 기본으로 사용하되, raw query가 필요한 경우
반드시 파라미터 바인딩을 사용합니다."
질문 #23-25: Backend 기초
| 질문 | 합격 답변 핵심 |
|---|---|
| #23: 트랜잭션 | "ACID 속성 설명. BEGIN-COMMIT-ROLLBACK. 동시성 제어. 격리 수준" |
| #24: 인덱스 | "검색 속도 향상. B-Tree 구조. 쓰기 성능 trade-off. WHERE, JOIN 컬럼에 생성" |
| #25: N+1 문제 | "반복 쿼리 문제. JOIN이나 eager loading으로 해결. 실제 쿼리 수 비교 예시" |
PART 2: 알고리즘/자료구조 (26-40)
질문 #26: 배열과 연결 리스트의 차이는?
❌ 탈락 답변:
"배열은 인덱스로 접근하고, 리스트는 순차적으로 접근해요."
✅ 합격 답변:
"메모리 구조와 성능 특성이 다릅니다.
배열:
- 연속된 메모리 공간
- 인덱스 접근: O(1)
- 삽입/삭제: O(n) (중간에 넣으면 밀어야 함)
- 크기 고정 (동적 배열은 재할당 필요)
연결 리스트:
- 분산된 메모리 (노드 + 포인터)
- 인덱스 접근: O(n) (순차 탐색)
- 삽입/삭제: O(1) (포인터만 변경)
- 크기 동적
실무에서는:
- 읽기가 많으면 → 배열
- 삽입/삭제가 많으면 → 연결 리스트
- JavaScript 배열은 실제로는 동적 배열 (해시맵)
예: LRU 캐시는 연결 리스트 + 해시맵 조합이 적합합니다."
질문 #27: 시간복잡도 O(n)과 O(n²)의 실제 차이는?
✅ 합격 답변:
"Big O는 입력 크기에 따른 성능 변화를 나타냅니다.
구체적 예시:
n = 1,000일 때
- O(1): 1번
- O(log n): 10번
- O(n): 1,000번
- O(n log n): 10,000번
- O(n²): 1,000,000번
실무 영향:
// O(n) - 괜찮음
users.forEach(user => sendEmail(user))
// O(n²) - 위험
users.forEach(user => {
users.forEach(otherUser => {
compareUsers(user, otherUser)
})
})
n이 작으면 (< 100) 큰 차이 없지만,
n이 크면 (> 10,000) 체감 차이가 엄청납니다.
그래서 코드 작성 시 중첩 루프를 주의하고,
해시맵 같은 자료구조로 O(n²)을 O(n)으로 개선합니다."
질문 #28-40: 알고리즘 핵심 개념
| 질문 | 설명 포인트 |
|---|---|
| #28: 이진 탐색 | "정렬 배열에서 O(log n). 중간값 비교로 범위 반씩 줄임" |
| #29: 정렬 알고리즘 비교 | "버블 O(n²), 퀵 O(n log n), 병합 O(n log n). 안정성, 공간 복잡도 차이" |
| #30: 스택 vs 큐 | "LIFO vs FIFO. 스택: 함수 호출, 괄호 검사. 큐: BFS, 작업 큐" |
| #31: 해시 테이블 | "key-value 저장. O(1) 접근. 충돌 해결: chaining, open addressing" |
| #32: 트리 순회 | "전위, 중위, 후위. DFS vs BFS. 재귀 vs 반복" |
| #33: 이진 탐색 트리 | "왼쪽 < 부모 < 오른쪽. 탐색 O(log n). 불균형 시 O(n)" |
| #34: 그래프 표현 | "인접 행렬 vs 인접 리스트. 공간/시간 trade-off" |
| #35: DFS vs BFS | "DFS는 스택/재귀, BFS는 큐. 최단 경로는 BFS" |
| #36: 동적 프로그래밍 | "중복 계산 제거. 메모이제이션. 피보나치 예시" |
| #37: 그리디 알고리즘 | "매 순간 최선 선택. 항상 최적해는 아님. 동전 거스름돈 예시" |
| #38: 재귀 | "자기 자신 호출. base case 필수. 스택 오버플로우 주의" |
| #39: Two Pointers | "배열 양 끝에서 접근. O(n²)을 O(n)으로 개선" |
| #40: Sliding Window | "부분 배열 문제. 윈도우 이동하며 계산. 중복 제거" |
PART 3: 시스템 디자인 (41-55)
질문 #41: 확장 가능한 시스템을 어떻게 설계하나요?
❌ 탈락 답변:
"서버를 여러 대 두면 돼요."
✅ 합격 답변:
"확장성은 수평 확장(scale-out)과 수직 확장(scale-up)으로 나뉩니다.
수평 확장 전략:
1. 로드 밸런서: 트래픽 분산
2. 무상태 서버: 세션을 Redis 같은 외부 저장소에
3. 데이터베이스 샤딩: 데이터를 여러 DB에 분산
4. 캐싱: Redis, CDN으로 읽기 부하 감소
5. 메시지 큐: 비동기 처리로 피크 대응
구체적 예시:
- 사용자 1만 → 단일 서버
- 사용자 10만 → 서버 3대 + 로드 밸런서 + Redis
- 사용자 100만 → 서버 10대 + DB 리플리카 + CDN
- 사용자 1000만 → 마이크로서비스 + 샤딩 + 캐싱 레이어
병목 지점을 찾아서 그 부분만 확장하는 게 효율적입니다.
모니터링과 메트릭이 중요합니다."
질문 #42: 데이터베이스 복제(Replication)를 설명해주세요.
✅ 합격 답변:
"Master-Slave 구조로 데이터를 복제합니다.
Master (Primary):
- 쓰기 작업 처리
- 변경사항을 Slave에 전파
Slave (Replica):
- 읽기 작업 처리
- Master 데이터 복사본 유지
장점:
1. 읽기 성능 향상 (여러 Slave에 분산)
2. 고가용성 (Master 다운 시 Slave 승격)
3. 백업 용이
주의사항:
1. 복제 지연 (Replication Lag)
- Slave는 약간 오래된 데이터
- 최신 데이터 필요 시 Master에서 읽기
2. Master 장애 시 처리
- 자동 failover 설정 필요
- Split-brain 문제 고려
실무에서는:
- 읽기 80%, 쓰기 20% → Slave 3대 운영
- 중요 데이터는 Master에서 조회
- 리포트나 통계는 Slave에서 처리"
질문 #43-55: 시스템 디자인 핵심
| 질문 | 답변 포인트 |
|---|---|
| #43: 캐싱 전략 | "Cache-Aside, Write-Through, Write-Behind. TTL 설정. 캐시 무효화 전략" |
| #44: CDN | "정적 콘텐츠를 엣지 서버에 분산. 지연시간 감소. CloudFront, Cloudflare 예시" |
| #45: 로드 밸런서 | "Round-robin, Least connections, IP hash. L4 vs L7. Health check" |
| #46: 마이크로서비스 vs 모놀리스 | "장단점 비교. 마이크로서비스는 복잡도 증가. 팀 크기, 서비스 성격 고려" |
| #47: API Gateway | "인증, 라우팅, rate limiting. 단일 진입점. BFF 패턴" |
| #48: 메시지 큐 | "비동기 처리. RabbitMQ, Kafka. 이벤트 기반 아키텍처. 순서 보장, 재시도" |
| #49: DB 샤딩 | "데이터 분산 저장. Horizontal partitioning. 샤드 키 선택 중요. 재샤딩 어려움" |
| #50: CAP 이론 | "Consistency, Availability, Partition tolerance. 3개 중 2개만 선택 가능" |
| #51: Rate Limiting | "API 과용 방지. Token bucket, Leaky bucket 알고리즘. Redis로 구현" |
| #52: 인증 vs 인가 | "Authentication vs Authorization. JWT, OAuth 2.0. 세션 vs 토큰" |
| #53: CORS | "Cross-Origin 요청 제한. Preflight. Access-Control-* 헤더 설정" |
| #54: WebSocket vs HTTP | "양방향 vs 단방향. 실시간 통신. Polling, Long polling, SSE 비교" |
| #55: 모니터링 | "메트릭, 로그, 트레이싱. Prometheus, Grafana, ELK. SLO, SLA, SLI" |
PART 4: 실무/경험 질문 (56-75)
질문 #56: 가장 어려웠던 기술적 문제와 해결 과정은?
❌ 탈락 답변:
"음... 별로 어려운 게 없었어요. 다 잘 풀렸습니다."
문제점: 성장 기회를 못 봄, 겸손하지 않음
❌ 탈락 답변 2:
"엄청 어려웠는데... 결국 못 풀었어요."
문제점: 문제 해결 능력 의심
✅ 합격 답변:
"프로젝트에서 페이지 로딩이 15초 걸리는 성능 이슈가 있었습니다.
문제 분석:
1. Chrome DevTools로 Network 탭 확인
→ API 응답이 12초 소요
2. 백엔드 로그 확인
→ DB 쿼리가 10초 이상
3. 쿼리 분석
→ N+1 문제 발견 (1 + 1000번 쿼리)
해결 과정:
1. JOIN으로 쿼리 최적화 (1000번 → 1번)
→ 10초 → 0.5초
2. 자주 조회되는 데이터 Redis 캐싱
→ 0.5초 → 0.1초
3. 프론트엔드에서 페이지네이션 추가
→ 불필요한 데이터 로드 제거
결과:
- 로딩 시간: 15초 → 1초
- 서버 부하: 70% 감소
- 사용자 이탈률: 40% → 10%
배운 점:
- 성능 이슈는 측정부터
- 병목 지점 찾기가 중요
- 프론트-백엔드 협업의 중요성"
왜 합격:
- 구체적인 숫자
- 체계적인 접근
- 결과와 학습 언급
질문 #57: 팀원과 의견 충돌이 있었던 경험은?
❌ 탈락 답변:
"제가 맞았는데 팀원이 틀렸어요. 결국 제 방법대로 했습니다."
✅ 합격 답변:
"API 설계에서 RESTful vs GraphQL 선택으로 의견이 갈렸습니다.
저의 의견: RESTful
- 팀이 익숙함
- 단순한 CRUD
- 학습 비용 없음
팀원 의견: GraphQL
- 클라이언트 요구사항 유연하게 대응
- Over-fetching 문제 해결
- 최신 트렌드
해결 과정:
1. 각자 장단점 문서화
2. POC 진행 (각각 1주)
3. 팀 투표 및 토론
결정:
- Phase 1은 RESTful (빠른 출시)
- Phase 2에서 GraphQL 도입 검토
배운 점:
- 정답은 없고 trade-off만 있음
- 데이터 기반 의사결정
- 타협과 단계적 접근"
질문 #58-70: 행동/경험 질문
| 질문 | 답변 구조 | 핵심 포인트 |
|---|---|---|
| #58: 마감 압박 경험 | STAR (상황-과제-행동-결과) | "우선순위 결정, 커뮤니케이션, MVP 접근" |
| #59: 실수한 경험 | 실수-영향-대응-학습 | "솔직함, 책임감, 재발 방지 대책" |
| #60: 새로운 기술 학습 | 동기-방법-적용-결과 | "자기주도 학습, 실전 적용 능력" |
| #61: 리더십 발휘 | 상황-역할-기여-결과 | "주도성, 팀워크, 문제 해결" |
| #62: 코드 리뷰 경험 | 받은 것/한 것 모두 | "피드백 수용, 건설적 제안 능력" |
| #63: 레거시 코드 다루기 | 이해-점진적 개선-테스트 | "인내심, 리팩토링 전략" |
| #64: 급한 버그 수정 | 우선순위-빠른 해결-근본 원인 | "위기 대응, 임기응변" |
| #65: 기술 부채 관리 | 인식-설득-해결-예방 | "장기적 관점, 기술-비즈니스 균형" |
| #66: 멀티태스킹 | 우선순위-시간 관리-커뮤니케이션 | "효율성, 조직력" |
| #67: 실패한 프로젝트 | 원인 분석-책임-교훈 | "성찰 능력, 성장 마인드" |
| #68: 사용자 피드백 대응 | 경청-분석-개선-확인 | "사용자 중심 사고" |
| #69: 성능 최적화 | 측정-분석-개선-검증 | "데이터 기반 접근" |
| #70: 문서화 경험 | 종류-방법-유지보수 | "커뮤니케이션, 조직화" |
질문 #71-75: 업무 스타일
| 질문 | 탈락 답변 | 합격 답변 |
|---|---|---|
| #71: 선호 업무 환경 | "자유롭게 일하고 싶어요" | "자율성 있되 협업 가능한 환경. 정기 싱크업과 비동기 소통 균형" |
| #72: 코드 품질 기준 | "돌아가면 됩니다" | "가독성, 테스트, 유지보수성. 코드 리뷰와 정적 분석 도구 활용" |
| #73: 기술 선택 기준 | "최신 기술 쓰고 싶어요" | "문제 적합성, 팀 역량, 생태계, 유지보수성 고려. 검증된 기술 우선" |
| #74: 일정 산정 | "시키는 대로 해요" | "작업 분석 후 버퍼 포함 추정. 리스크 공유. 협상 가능" |
| #75: 배포 철학 | "완벽해질 때까지 기다려요" | "작은 단위로 자주. feature flag 활용. 롤백 계획 필수" |
PART 5: 회사/역량 맞춤 질문 (76-100)
질문 #76: 왜 우리 회사에 지원했나요?
❌ 탈락 답변:
"좋은 회사라고 들었어요."
"집이 가까워서요."
"연봉이 좋아서요."
✅ 합격 답변:
"세 가지 이유가 있습니다.
첫째, 기술 스택입니다. React와 TypeScript를 주력으로 쓰시는데,
제가 지난 2년간 집중해온 기술이고 더 깊이 있게 다루고 싶습니다.
특히 테크 블로그에서 본 MSA 전환 사례가 인상적이었습니다.
둘째, 도메인에 관심이 있습니다. 이커머스 분야에서 대규모
트래픽을 다루는 경험을 쌓고 싶습니다. 특히 실시간 재고 관리나
결제 시스템 같은 도전적인 문제를 해결하고 싶습니다.
셋째, 성장 문화입니다. 채용 공고에서 본 '기술 세미나'와
'오픈소스 기여 장려' 같은 부분이 제 커리어 목표와 맞습니다.
배우면서 기여하는 개발자가 되고 싶습니다.
실제로 Github에서 회사의 오픈소스 프로젝트를 봤는데,
[구체적 프로젝트명]의 코드가 깔끔해서 인상적이었습니다."
왜 합격:
- 구체적인 조사
- 회사와 본인의 fit
- 진정성 있는 이유
질문 #77: 5년 후 커리어 목표는?
❌ 탈락 답변:
"CTO가 되고 싶어요."
✅ 합격 답변:
"단계별로 계획하고 있습니다.
1-2년차 (기술 깊이):
- 풀스택 역량 강화
- 대규모 시스템 경험
- 테스트/배포 자동화 마스터
3-4년차 (기술 넓이 + 리더십):
- 아키텍처 설계 역량
- 주니어 멘토링
- 기술 의사결정 참여
5년차 (Tech Lead):
- 팀 기술 방향 제시
- 복잡한 문제 해결 능력
- 비즈니스와 기술 연결
다만 이건 계획이고, 실제로는 배우면서 조정할 것 같습니다.
지금은 눈앞의 일을 잘하는 게 먼저라고 생각합니다."
질문 #78-90: 직무 역량 질문
| 질문 | 답변 포인트 |
|---|---|
| #78: 본인의 강점 | "구체적 사례 + 수치. '빠른 학습': 새 프레임워크 2주 만에 프로덕션 투입" |
| #79: 본인의 약점 | "인식 + 개선 노력. '발표 긴장' → 사내 세미나 자원해서 연습 중" |
| #80: 원격 근무 경험 | "자기 관리, 비동기 소통, 문서화. 생산성 유지 방법 구체적 설명" |
| #81: 애자일 경험 | "스프린트, 스탠드업, 회고. 실제 프로세스와 느낀 점" |
| #82: CI/CD 구축 경험 | "도구 선택, 파이프라인 구성, 테스트 자동화. 배포 시간 단축 수치" |
| #83: 테스트 전략 | "단위-통합-E2E 테스트 비율. TDD 경험. 커버리지 목표" |
| #84: 보안 인식 | "OWASP Top 10. 실제 적용 사례. 보안 체크리스트" |
| #85: 성능 최적화 경험 | "측정 도구, 병목 지점 찾기, 개선 전후 비교" |
| #86: 코드 리뷰 철학 | "건설적 피드백, 배움의 기회, 팀 코드 품질 향상" |
| #87: 기술 부채 해결 | "우선순위 결정, 비즈니스 설득, 점진적 개선" |
| #88: 장애 대응 경험 | "신속한 파악, 임시 조치, 근본 원인 해결, 재발 방지" |
| #89: 크로스 기능 협업 | "디자이너, PM과 협업. 기술 용어 쉽게 설명. 공동 목표" |
| #90: 오픈소스 기여 | "참여 프로젝트, 기여 내용, PR 과정. 없어도 관심 표현" |
질문 #91-100: 마무리 질문
| 질문 | 탈락 답변 | 합격 답변 |
|---|---|---|
| #91: 연봉 협상 | "아무거나 주세요" | "시장 조사 + 본인 경력 근거. 유연하지만 기준 있음" |
| #92: 입사 가능 시기 | "내일이라도요!" | "현 회사 인수인계 고려. 구체적 날짜" |
| #93: 다른 회사 진행 중? | "여기만 봤어요" | "솔직하게. 하지만 여기가 우선순위 높은 이유 설명" |
| #94: 야근 가능? | "당연하죠!" | "필요 시 가능. 하지만 일상적 야근은 비효율 문제 제기" |
| #95: 주말 출근 가능? | "괜찮아요" | "긴급 상황은 이해. 하지만 지속가능성 고려 필요" |
| #96: 회사에 바라는 점 | "없어요" | "성장 기회, 기술 환경, 워라밸. 구체적이되 겸손하게" |
| #97: 실패 두려움? | "실패 안 해요" | "실패는 학습 기회. 빠르게 실패하고 배우기" |
| #98: 스트레스 관리 | "스트레스 없어요" | "운동, 취미, 휴식. 건강한 대처 방법" |
| #99: 궁금한 점? | "없어요" | "팀 구조, 온보딩, 기술 스택, 첫 프로젝트. 최소 2-3개" |
| #100: 마지막 한마디 | "잘 부탁드립니다" | "기회 주시면 빠르게 기여하겠습니다. 함께 성장하고 싶습니다" |
면접 전략 핵심 정리
DO ✅
-
STAR 기법 사용
- Situation (상황)
- Task (과제)
- Action (행동)
- Result (결과)
-
구체적인 수치
- "많이" → "50% 증가"
- "빠르게" → "3초 → 0.5초"
- "여러 번" → "15회"
-
배운 점 언급
- 모든 경험에서 성장
- 실패도 학습 기회
- 다음에 어떻게 할지
-
질문하기
- 궁금한 것 물어보기
- 회사에 관심 보이기
- 대화로 만들기
-
솔직함
- 모르면 모른다고
- 하지만 배울 의지 보이기
- 과장하지 않기
DON'T ❌
-
단답형 대답
- "네" / "아니요"
- "잘 모르겠어요"
- "별로 없어요"
-
부정적 표현
- 전 회사/팀 욕
- "못 해요" / "싫어요"
- 변명하기
-
과도한 자신감
- "다 알아요"
- "쉬워요"
- "혼자 다 했어요"
-
준비 안 된 모습
- 회사 정보 모름
- 프로젝트 설명 못함
- 이력서 내용 기억 못함
-
시간 독점
- 너무 긴 답변 (3분 이상)
- 관계없는 이야기
- 면접관 질문 끊기
면접 준비 체크리스트
기술 준비
- 이력서에 쓴 기술 스택 전부 설명 가능
- 프로젝트별 기술적 도전과 해결 정리
- 최근 학습한 기술/개념 정리
- 알고리즘 문제 풀이 연습 (10-20문제)
- 시스템 디자인 기본 패턴 숙지
경험 정리
- STAR 기법으로 5-10개 경험 정리
- 성공/실패 사례 각 2-3개
- 숫자로 표현 가능한 성과 정리
- 협업 경험 구체화
- 기술적 의사결정 사례
회사 조사
- 회사 서비스 사용해보기
- 기술 블로그 읽기
- 기술 스택 확인
- 최근 뉴스/공고 확인
- 면접관 LinkedIn 확인 (가능하면)
실전 준비
- 모의 면접 2-3회
- 답변 녹음해서 들어보기
- 시간 재며 답변 연습
- 예상 질문 20개 준비
- 역질문 5개 준비
당일 준비
- 30분 전 도착 (또는 5분 전 접속)
- 이력서, 포트폴리오 출력/준비
- 필기구, 노트북 챙기기
- 옷차림 점검
- 마음 가다듬기
면접 후 Follow-up
감사 이메일 (24시간 내)
제목: [이름] 면접 감사 인사
안녕하세요, 오늘 [시간]에 [직무] 면접을 본 [이름]입니다.
바쁘신 와중에 시간 내어주셔서 감사합니다.
[구체적으로 인상깊었던 점]이 특히 기억에 남습니다.
[회사/팀]에서 [기여하고 싶은 점]하고 싶습니다.
좋은 소식 기다리겠습니다.
감사합니다.
[이름]
결과 대기
- 보통 1-2주 소요
- 1주 후에도 연락 없으면 정중히 문의
- 다른 기회도 병행 탐색
탈락 시
- 피드백 요청 (정중하게)
- 부족한 부분 개선
- 다음 기회를 위한 연락처 유지
마치며: 면접은 양방향 평가
면접은 회사가 당신을 평가하는 자리이지만, 당신도 회사를 평가하는 자리입니다.
좋은 면접은:
- 서로 배우는 대화
- 핏(fit)을 확인하는 과정
- 앞으로의 관계 시작
완벽한 답을 하려 하지 말고, 진정성 있게 당신을 보여주세요.
100개의 답을 외우는 것보다, 1개의 경험을 깊이 이해하는 것이 낫습니다.
준비한 만큼 자신감이 생깁니다. 하지만 준비했어도 떨어질 수 있고, 그건 당신의 가치와 무관합니다.
Right job for you, right candidate for them.
합격하기를 응원합니다! 💪
P.S. 면접 보고 나서 이 글을 다시 읽어보세요. 무엇을 개선할 수 있을지 보일 겁니다.