개발자 면접 20년 — 면접관으로서 본 좋은 시니어의 기준

게시일: 2025년 9월 2일 · 14분 읽기

알고리즘 잘 푸는 사람보다, '왜'를 설명할 수 있는 사람이 좋은 시니어다

20년 동안 면접을 봤다. 신입부터 임원까지, 그리고 지금은 시니어까지. 면접을 통해 배운 것이 많다.

가장 중요한 깨달음: 좋은 개발자를 뽑는 방법은 LeetCode 알고리즘이 아니라, 다른 것을 본다는 것이다.

알고리즘 질문을 빠르게 푸는 것의 의미

면접에서 알고리즘을 빠르게 푸는 사람들을 봤다. 5분 안에 두 가지 solution을 제시하는 사람도 있었다.

그런데 이 사람들 중 상당수가, 실제 업무에서는 평범했다.

왜일까? 알고리즘 솜씨와 실무 능력은 다르기 때문이다:

• 알고리즘: 이미 정의된 문제를 푸는 능력
• 실무: 모호한 요구사항을 정의하고, 그것을 푸는 능력

면접관으로서 더 중요한 질문은: "이 알고리즘을 언제 쓸까?"였다.

빨간 불 신호들

신호 1: "내가 처음 쓰는 언어라 실수했어요"

이 말은 좋은 신호다. 왜냐하면:

• 책임을 인정하고
• 배우려는 자세를 보여주고
• 실제로 해결하려고 함

신호 2: "좋은 질문이네요"

그리고 5분을 생각한 후 자신의 가정을 설명하는 경우.

이것이 진정한 시니어다. 문제를 완벽하게 풀지 못해도, 생각하는 과정이 견고하면 성장할 수 있다.

역신호 1: "이건 제 풀이방식이 있어서..."

그리고 면접관의 피드백을 무시하는 경우. 이건 위험신호다.

역신호 2: 침묵

막혔을 때 아무것도 말하지 않으면, 그 사람이 어디서 막혔는지 알 수 없다. 좋은 개발자는 생각을 말로 표현한다.

면접에서 보는 진짜 시니어의 기준

1. 문제 정의 능력

나쁜 예: "이 문제 푸세요"라고 주면 바로 푼다
좋은 예: "이 문제에서 시간 복잡도와 공간 복잡도의 트레이드오프를 보면 어떻게 될까요?"라고 되묻는다

2. 커뮤니케이션

나쁜 예: 조용히 코드를 짜고 제출한다
좋은 예: "이 부분은 O(n)이고, 저 부분은 O(log n)이라서, 전체적으로는..."이라고 설명한다

3. Trade-off를 이해

나쁜 예: "이 방법이 가장 빠르니까 이것으로"
좋은 예: "이 방법은 빠르지만 메모리를 많이 쓰고, 저 방법은 느리지만 메모리 효율적이라서, 우리 상황에서는..."

4. "I don't know"를 말할 수 있는 용기

최악의 시니어: 모르는 것을 아는 척 한다
최고의 시니어: "이 부분은 모르는데, 이렇게 학습하겠습니다"라고 한다

실제 면접 사례

경우 1: 알고리즘은 못 푼 사람

면접관: "이 문제 푸세요"
지원자: (5분 생각) "죄송합니다. 저는 이걸 모르는데..."
       "하지만 이렇게 접근하면 좋을 것 같습니다" (아이디어 제시)
       "더 공부한 후에는 풀 수 있을 것 같은데요"
결과: 합격

경우 2: 알고리즘은 잘 푼 사람

면접관: "왜 이 방법으로 풀었어요?"
지원자: (침묵) "음... 그냥 이게 더 빠르니까요"
       (다른 방법이 있는지 생각하지 않음)
결과: 불합격

경력에 따라 보는 기준

신입(신입-주니어):

• 문제를 푸는 것보다, 어떻게 접근하는지
• 실수를 했을 때, 어떻게 대응하는지
• 학습의욕

미드레벨(4-7년차):

• 시스템 설계 능력
• 실제 경험에서 배운 베스트 프랙티스
• 팀 커뮤니케이션 능력

시니어(8년차+):

• 전략적 사고
• 기술적 리더십
• 멘토링 경험
• 기술 결정의 근거

기술 토론에서 보이는 것들

나는 보통 마지막에 이런 질문을 한다:

"만약 이 시스템이 느려진다면, 어디부터 최적화할 생각입니까?"

나쁜 답변: "캐시를 추가하면 되죠"
좋은 답변: "먼저 병목이 어디인지 측정해야 해요. 보통은 데이터베이스 쿼리인데, 그 다음이 캐싱입니다. 만약 캐싱 전에 쿼리를 최적화하면..."

두 번째 답변을 하는 사람이 진정한 시니어다.

실무와의 연관성

면접에서 본 것들이 실제로 맞았을까?

25년 데이터로 보면:

• 알고리즘 능력과 실무 능력의 상관관계: 약 0.3 (약함)
• 커뮤니케이션과 성과의 상관관계: 0.7 (강함)
• 문제 정의 능력과 승진의 상관관계: 0.8 (매우 강함)

나의 인터뷰 기준 변화

처음(25년 전): "LeetCode 난이도 Medium 이상"
10년 후: "시스템 설계 질문에서 trade-off를 생각하는지"
지금: "이 사람이 팀을 성장시킬 수 있는가?"

결론

좋은 개발자를 뽑는 방법은 복잡한 알고리즘을 푸는 것이 아니다. 그것보다는:

• 생각하는 방식
• 배우는 자세
• 커뮤니케이션
• 팀 협력

이것들을 본다.

면접을 보는 사람이라면, 한 번 생각해보자: "내가 정말 필요한 것이 뭐지?"