테크니컬 인터뷰, 진짜로 붙는 사람들은 이렇게 준비합니다
오늘은 말 그대로 **“technical interview를 통과하는 데 진짜로 필요한 것”**만 정리해 볼 거예요.
추상적인 멘탈 관리, 감성적인 동기부여 말고, 실제로 합격으로 이어지는 구체적인 액션들요.
그리고 이 글의 핵심 조언은 전부 한 사람에게서 나옵니다.
Kevin.
- ex-Google
- ex-Amazon
- 8년 이상 Big Tech에서 software engineer로 근무
- 수백 번 technical interview를 직접 진행한 interviewer
즉, “인터뷰 당해본 사람”이 아니라
**“인터뷰를 수백 번 출제하고 평가해 본 사람”**의 관점에서 정리한 내용입니다.
이 글에서는 다음을 전부 다룹니다.
- 인터뷰 전에 무엇을, 어떻게 준비해야 하는지
- 인터뷰 들어가서 정말 그대로 따라 쓰면 되는 “recipe”
- 시간 배분, 커뮤니케이션, 자주 떨어지는 포인트
- 인터뷰 끝난 뒤에 뭘 물어봐야 인상에 남는지
- 합격하는 사람들의 공통점과, 초보들이 반복하는 실수들
편하게 읽히게 풀어 쓰지만, 내용 자체는 꽤 빡셉니다.
대신, 끝까지 따라가면 “아, 이렇게만 하면 되겠구나”라는 느낌이 올 거예요.
1. 먼저, technical interview는 왜 이렇게까지 빡셀까?
솔직히 말하면, technical interview는 인생 바꿀 기회입니다.
한 번에 통과하면:
- 연봉, 보상 구조 통째로 업그레이드
- 커리어 브랜드(“ex-Google”, “ex-Meta” 같은 라벨)
- 이후 이직할 때도 계속 +α로 따라오는 네임밸류
그러다 보니 자연스럽게 난이도가 올라가고,
지원자 입장에서는 너무 큰 압박으로 다가오죠.
하지만 Kevin의 말은 오히려 담백합니다.
“비밀 레시피 같은 건 없어요.
결국엔 기본기 + 충분한 연습이에요.”
듣기엔 평범하지만, 이게 오히려 좋은 소식입니다.
천재가 아니어도, 인맥이 없어도, 정보력이 남들보다 부족해도
내가 컨트롤할 수 있는 영역을 열심히 채우면 붙을 수 있다는 얘기니까요.
2. 인터뷰 준비의 첫 단계: “내가 어디로 들어가는지부터 이해하기”
많은 사람들이 여기서부터 삐끗합니다.
“일단 LeetCode부터…” 하고 바로 문제만 풀기 시작해요.
하지만 Kevin이 딱 잘라 말합니다.
“가장 확실한 광탈 방법은,
무엇을 하게 될지 모른 채 인터뷰에 들어가는 거예요.”
2-1. Big Tech의 전형적인 프로세스 구조
회사마다 조금씩은 다르지만, Meta / Google / NVIDIA / Amazon 같은
대형 tech 회사들은 보통 아래 비슷한 흐름을 가집니다.
- Recruiter Phone Screen
- 이력서 확인, 경력/프로젝트 간단 정리
- 지원 포지션, 타임라인, 연봉 기대감 같은 것들 이야기
- Technical Phone Screen
- 보통 1시간 내외
- 온라인 editor(예: Google Docs/사내 tool)에서 coding
- 난이도 중간 정도의 LeetCode 스타일 문제
- Onsite Loop (Full Loop) – 요즘은 virtual인 경우도 많음
- 하루 동안 4~5개의 세션을 연달아 보는 구조
- coding interview, system design, behavioral 등 섞여 있음
- Meta, Google, NVIDIA 모두 이런 식의 “loop”가 있음
회사마다 디테일은 다르지만,
“phone screen → technical → onsite loop” 이 큰 뼈대는 비슷해요.
따라서 첫 번째 준비는,
“내가 지금 어느 단계에 있는지,
그리고 그 단계에서 뭘 보여줘야 하는지를 정확히 아는 것.”
3. 무엇을 공부해야 할까? (LeetCode, data structure, algorithm)
자, 이제 많은 사람들이 궁금해하는 부분.
“Meta, NVIDIA, Google technical interview…
도대체 뭘 공부해야 해요?”
Kevin의 대답은 굉장히 직관적입니다.
3-1. LeetCode 스타일 문제, 매일 풀기
- LeetCode와 같은 플랫폼에서 문제를 매일 풉니다.
- technical interview에서 자주 나오는 15개 내외 핵심 topic
(array, string, Linked List, tree, graph, dynamic programming, greedy,
hash, stack/queue, binary search, sorting, etc.)들을 전부 커버해야 합니다.
포인트는 “하루 만에 끝내는 집중학습”이 아니라,
지속적인 daily practice입니다.
3-2. 암기가 아니라 “패턴 인식”
중요한 건 단순히 해답을 외우는 게 아니라,
문제 유형별로 패턴을 몸에 익히는 것입니다.
- “아, 이런 형태면 two pointers로 풀 수 있겠네.”
- “이건 binary search를 응용하는 패턴이구나.”
- “이건 Linked List를 reverse하는 고전 패턴이네.”
이 정도 감각이 생길 때까지 반복해야 해요.
Kevin 표현대로 하면,
“충분히 많이 풀다 보면,
문제를 보면 바로 어떤 data structure / algorithm을 써야 할지
감이 오기 시작합니다.”
4. 회사 리서치: LeetCode frequency, Reddit, “due diligence”
준비 얘기하면 빠지지 않는 게 이거죠.
“회사별로 자주 나오는 문제를 찾아서 대비해야 하나요?”
Kevin의 답은 “예, 하지만 이걸 꼼수라고 생각하지는 말 것.”
4-1. LeetCode의 “frequency” 기능 활용
LeetCode에는 특정 회사 기준으로
가장 많이 출제된 문제를 정렬해 주는 기능이 있습니다.
예를 들어:
- “Meta top questions”
- “NVIDIA most frequent”
- “Google high frequency”
이걸 보는 이유는 간단해요.
- 회사에 들어가면서
그 회사에서 가장 자주 나오는 문제조차 모르는 것은
그냥 준비 부족일 뿐이니까요.
Kevin 말로는,
“Meta 인터뷰 보러 가면서
LeetCode에서 Meta top 문제 1번을 받았는데
그걸 모른다? 그건 솔직히 본인 책임이죠.”
물론, 회사들은 공식적으로
“leaked 문제를 다시 내지 말라”고 교육을 받습니다.
그래도 어떤 문제들은 비슷한 변형으로 돌아오기도 하고,
면접관이 그 문제가 leaked인지 모를 수도 있죠.
따라서:
- **“시스템을 속이겠다”**는 마음이 아니라
- **“인터뷰 전, 해야 할 기본적인 숙제(due diligence)를 한다”**는 느낌으로
회사별 자주 나오는 문제를 한 번씩은 체크해 두는 게 좋습니다.
5. 인터뷰 안에서 쓸 “Recipe” 만들기
이제 가장 중요한 부분입니다.
“문제 받고 나서, 도대체 무슨 순서로 움직여야 하죠?
그냥 바로 코드부터 쓰나요?”
Kevin이 강조하는 개념은 **“recipe”**입니다.
요리에서 새로운 케이크를 처음 만들 땐
레시피를 계속 보면서 설탕이 몇 g인지 확인하죠.
하지만 그 케이크를 100번 만들면,
레시피 없이도 손이 알아서 움직입니다.
technical interview도 똑같습니다.
“인터뷰 때 똑같은 ‘레시피’를 반복하다 보면,
어느 순간 자동적으로 몸이 움직이게 돼요.”
Kevin이 쓰는 대표적인 7단계 recipe는 이겁니다.
Step 1. 문제 읽고, 진짜로 이해하기
당연해 보이지만, 의외로 여기서부터 망가지는 경우가 많습니다.
- 문제 전체를 처음부터 끝까지 천천히 읽고
- input / output / constraint를 정확히 잡고
- 예시를 스스로 다시 설명해 봅니다.
Kevin도 예전에,
문제를 완전히 이해하지 못했는데 “알겠다고” 해 버렸다가
이상한 방향으로 풀고 망한 적이 있다고 합니다.
“이해하지 못한 문제는 절대 풀 수 없습니다.”
이건 너무 단순하지만, 진짜 자주 깨먹는 원칙이에요.
Step 2. Clarifying Questions: 모르는 걸 반드시 물어보기
실제 업무에서 요구사항은 항상 애매합니다.
- “to-do list app을 만들어 주세요.”
- “메시지를 저장하는 service를 만들어 주세요.”
라고 하면,
- user는 몇 명?
- 동시 접속 수는?
- mobile만? web도?
- offline 모드?
같은 것들을 끝없이 물어봐야 하죠.
technical interview도 일부러 정보를 다 안 주는 경우가 많습니다.
그래서 clarifying questions를 하는지 자체가 평가 항목에 포함됩니다.
예를 들어:
- input array size는 얼마나 클 수 있나요?
- 값이 음수도 포함되나요?
- 중복 값은 허용되나요?
- time complexity나 memory 사용에 제한이 있나요?
이런 걸 안 물어보고 그냥 풀기 시작하면,
나중에 “음수 포함” test case 하나에 그대로 무너질 수 있습니다.
Step 3. 여러 가지 Solution 제안하기
바로 코드로 뛰어들지 말고,
머릿속에서 최소 2~3가지 접근법을 비교해 보는 게 좋습니다.
예시:
- A안: brute-force, O(N²)
- B안: sorting 후 two pointers, O(N log N)
- C안: hash map 사용, O(N)
그리고 이렇게 말할 수 있으면 좋습니다.
“이 문제를 푸는 방법은 대략 세 가지 정도 떠오릅니다.
A는 구현은 쉬운데 time complexity가 O(N²)라 input이 커질 때 위험하고,
B는 sorting을 해서 O(N log N)까지 줄일 수 있습니다.
C는 hash map을 사용해서 average O(N)으로 가능하지만
extra space O(N)을 사용합니다.
trade-off를 고려했을 때 B가 가장 balance가 좋아 보입니다.
B로 진행해도 괜찮을까요?”
이 한 문장에 이미:
- 문제 이해 +
- 여러 솔루션 비교 +
- time/space complexity 인식 +
- 의사결정 과정 설명 +
- 인터뷰어와 협업하는 태도
가 다 들어갑니다.
Step 4. 코드 작성 (이게 사실 제일 쉬워야 한다)
Kevin 말에 따르면,
준비가 잘 된 상태라면 code 작성은 2~3분이면 끝나야 한다고 합니다.
- 이미 머릿속에서 어떤 pattern을 쓸지 정해졌고
- pseudo-code도 머릿속에 그려져 있고
- 사용하는 language의 syntax도 익숙하다면
키보드로 쳐 넣는 건 그냥 손이 하는 일일 뿐입니다.
그래서 사실:
“코딩이 인터뷰에서 제일 어려우면,
그건 준비가 덜 된 거예요.”
Step 5. Rubber Duck Debugging: 내 코드 스스로 리뷰하기
코드를 다 썼다고 끝이 아닙니다.
그 자리에서 스스로 코드 리뷰를 해야 합니다.
- “자, 이제부터 제 코드를 한 줄씩 따라가 보겠습니다.”
- “처음에 pointer를 왼쪽/오른쪽에 두고, while loop에서 …”
- 직접 test case를 만들고, input이 어떻게 변하는지 설명합니다.
목표는 하나입니다.
“interviewer가 찾기 전에, 내가 먼저 bug를 찾는 것.”
사람은 누구나 실수합니다.
bug가 있는 것 자체는 큰 문제가 아닐 수 있어요.
하지만 그걸 스스로 발견하고 고칠 줄 아느냐는
엄청 중요한 signal입니다.
Step 6. Pitfall & Optimization 이야기하기
코드가 돌아가기 시작하면, 이제 한 단계 더.
- edge case에서 깨질 수 있는 부분은 없는지
- time/space를 더 줄일 수 있는지
- trade-off를 달리 가져가는 다른 버전은 없는지
를 이야기합니다.
예를 들면:
- “지금 solution은 worst-case O(N²)인데,
sorting을 허용하면 O(N log N)까지 줄일 수 있습니다.” - “현재는 extra space O(N)을 사용 중인데,
in-place로 바꾸면 space O(1)도 가능합니다.
다만 code가 조금 복잡해집니다.”
이런 이야기를 스스로 꺼내면,
그 인터뷰는 이미 상당히 잘 풀리고 있을 확률이 높습니다.
Step 7. Runtime / Space Complexity 정리해서 마무리
마지막에는 아주 깔끔하게 정리해 줍니다.
- “time complexity는 O(N log N)입니다.
sorting이 dominant factor이고, loop는 O(N)입니다.” - “space complexity는 input 외에 extra space로
hash map 때문에 O(N)이 추가로 들어갑니다.”
Big Tech에서 돌고 있는 서비스는
수억, 수십억 단위의 data를 처리합니다.
그래서 complexity를 명확히 이해하고 있는지는
**“실제로 이 사람에게 대규모 시스템의 코드를 맡길 수 있는가”**와
직접 연결되는 부분입니다.
6. 이 “Recipe”의 진짜 힘: 막혔을 때도 할 일이 생긴다
이 recipe의 좋은 점은 하나 더 있습니다.
“내가 지금 최적의 solution을 모를 때에도
할 수 있는 일이 명확해진다”는 것.
많은 지원자들이 문제를 받고 5분 정도 고민하다가,
해결 전략이 바로 떠오르지 않으면 멘탈이 무너집니다.
- 머릿속이 하얘지고
- 침묵이 길어지고
- 결국 “아… 모르겠다…” 쪽으로 가 버리죠.
하지만 recipe를 알고 있다면 최소한:
- 문제를 다시 내 말로 정리하고
- clarifying questions를 하고
- brute-force라도 하나 제안해 보고
- time complexity 문제를 스스로 지적한 뒤
- 더 나은 방법을 interviewer와 같이 고민할 수 있습니다.
이렇게 되면,
**“완벽한 정답을 못 찾았더라도, 패스할 수 있는 인터뷰”**가 나옵니다.
반면, 아무 말도 안 하고 조용히 좌절한 인터뷰는
거의 무조건 fail입니다.
7. 시간 배분: 첫 10분 안에 코드 쓰기 시작하기
Kevin이 제시하는 하나의 기준이 있습니다.
“가능하면 10분 안에 코드 작성을 시작하는 걸 목표로 하세요.”
이 기준이 좋은 이유는:
- 문제 이해 + clarifying questions + 솔루션 설계 + 비교까지
전부 10분 안에 마무리해야 한다는 압박이 생기고 - 그 결과, 인터뷰 전체의 tempo가 좋아집니다.
또 하나의 장점:
- 회사가 기본적으로 한 문제를 기대한다 하더라도,
- 10분 안에 설계하고 2~3분 안에 코드를 짠다면,
- 남은 시간에 두 번째 문제를 시도해 볼 여유가 생깁니다.
인터뷰어 입장에서는:
- “우리가 원했던 기준을 무난히 넘었고,
심지어 여유 있게 추가 문제까지 건드렸다”
라는 인상을 받을 수 있죠.
그리고 연습할 때는 실제보다 더 빡세게 잡는 것도 좋습니다.
“실제 인터뷰가 40분이라면,
연습은 20분 타이머 걸어 놓고 푸는 식으로요.”
그렇게 준비하면, 실제 인터뷰는 상대적으로 훨씬 여유롭습니다.
8. 회사는 무엇을 보고 평가할까? (Rubric + “비교 기준”)
이제 중요한 질문.
“도대체 회사는 어떤 기준으로 우리를 평가할까요?”
8-1. 공식적인 Rubric
대부분의 대형 회사들은
**명확한 평가 기준(rubric)**을 interviewer에게 줍니다.
예를 들면:
- 문제 이해 능력
- clarifying questions를 통해 요구사항을 정리하는지
- data structure / algorithm에 대한 기술적 깊이
- 코드의 정확성 및 robustness
- communication & collaboration
- 시간 내에 문제를 해결하는 능력
특히 clarifying questions는 실제 일과 매우 유사하기 때문에
많이 강조되는 항목입니다.
- “scope를 스스로 정리하는가?”
- “in-scope / out-of-scope를 구분할 줄 아는가?”
이건 곧 **“실제 팀에 들어왔을 때 product 요구사항을 어떻게 다룰 사람인가”**와
바로 연결되거든요.
8-2. 비공식적인 “비교 기준”
그리고 한 가지 더, 사람이 하는 일이라 어쩔 수 없는 부분이 있습니다.
“같은 문제를 수백 명에게 내다 보면,
면접관 머릿속에 자연스럽게 기준선이 생깁니다.”
- 이 문제를 완벽하게 푼 사람들
- 70% 정도까지만 도달한 사람들
- 아예 헤맨 사람들
시간이 지날수록,
각 candidate는 이 “비공식적인 분포” 안에서
어느 정도 위치를 차지하게 됩니다.
회사에서는 공식적으로
“다른 지원자와 비교하지 말고, 독립적으로 평가하라”고 하지만,
사람인 이상 무의식적인 비교는 피하기 어렵습니다.
그래서 Kevin은 이렇게 말합니다.
“목표를 단순히 'bar를 겨우 넘는 것'에 두지 마세요.
아예 새로운 bar를 정하는 사람이 되려고 하세요.”
9. Communication: 말을 못하면, 실력도 제대로 안 보인다
여기서 진짜 많은 사람들이 떨어집니다.
“조용히 앉아서, 혼자 머릿속에서만 고민하는 스타일”
Kevin과 Tim(스크립트의 진행자 둘 다)은
이걸 굉장히 강하게 지적합니다.
9-1. 좋은 인터뷰는 “둘이 같이 푸는 문제 풀이”에 가깝다
많은 지원자들은 인터뷰를 이렇게 상상합니다.
- 면접관: 45분 동안 말없이 나를 감시하는 무서운 존재
- 나: 침묵 속에서 정답을 맞춰야 하는 시험 치는 사람
하지만 좋은 technical interview는 이런 모양이 아닙니다.
오히려 이렇게 돼야 합니다.
- 둘이서 화이트보드 앞에 서서,
같이 문제를 풀어가는 느낌 - 내가 생각을 말하면,
interviewer가 거기에 대해 질문도 하고,
힌트도 조금씩 던져주는 구조
이걸 위해서 가장 중요한 게 바로 communication입니다.
9-2. “Lockstep”으로 interviewer를 데려가기
Kevin이 말하는 이상적인 상태는 이겁니다.
“내가 한 단계 움직일 때마다,
interviewer가 완전히 이해한 상태로 따라오고 있는 것.”
즉,
- 지금 어떤 접근법을 시도 중인지
- 왜 이 data structure를 골랐는지
- 이 코드 블록이 무슨 역할을 하는지
를 계속 말로 풀어줘야 한다는 뜻입니다.
다만, 긴장하면 흔히 생기는 문제가 하나 있죠.
- 말을 하긴 하는데
- 핵심 없이 계속 빙빙 도는 rambling
그래서 두 가지를 동시에 신경 써야 합니다.
- 충분한 설명
- 불필요한 반복 없이, 핵심 위주로
9-3. “도와달라고 직접 말하지 않고도” 도움 받는 법
Kevin이 알려준 아주 실용적인 스킬 하나가 있습니다.
본인은 항상 이런 말을 한다고 해요.
“그럼 이런 접근으로 풀어보려고 하는데요.
How does that sound to you?”
이 한 마디가 가진 힘은 생각보다 큽니다.
- “저 이거 잘 모르겠으니까 도와주세요”라고 노골적으로 말하지 않으면서도
- 인터뷰어가 어느 정도 feedback을 줄 수밖에 없는 상황을 만들죠.
그때 나오는 반응은 보통 세 가지입니다.
- Green light
- “좋아 보이네요.”
- “네, 그 방법으로 한 번 가보시죠.”
→ 그럼 그 접근은 꽤 괜찮은 방향일 확률이 높습니다.
- Yellow light
- “음… 그 방법이 모든 test case를 커버할 수 있을까요?”
- “negative number가 들어오는 경우는 어떤가요?”
→ 정면으로 “틀렸다”고 말하진 않았지만,
뭔가 빠뜨린 부분이 있다는 신호입니다.
- Red light
- “음, 그 접근은 time limit에 걸릴 것 같아요.”
- “그렇게 하면 constraint를 만족하기 어렵지 않을까요?”
→ 이 경우에는 과감히 pivot해야 합니다.
이건 단순히 영어 표현 숙지가 아니라,
사회적 signal을 읽고 활용하는 능력에 가깝습니다.
그리고 이런 능력은 실제 업무에서도 엄청 중요합니다.
9-4. “코드는 안 써도 돼요, 여기부터는 …로 처리해 주세요”
Tim(진행자)이 실제로 경험한 일 하나.
- 인터뷰에서 꽤 복잡한 부분을 설명해야 하는 상황이 있었는데
- 본인이 그 로직을 아주 명확하게 설명하자
- interviewer가 이렇게 말했습니다.
“아, 거기는 그냥 ...로 두셔도 돼요.
무슨 코드가 나올지 충분히 이해했습니다.”
이게 communication의 위력입니다.
- 설명을 잘하면
- 꼭 모든 코드를 끝까지 다 쓰지 않아도
- interviewer가 “아, 이 사람은 이 부분도 충분히 구현할 수 있겠다”고
신뢰해 줍니다.
반대로:
- 아무 설명 없이 코드를 억지로 다 치려다가
- time over 나는 사람들도 정말 많습니다.
10. 인터뷰 마지막 5분: “좋은 질문”은 생각보다 강력하다
technical part가 끝나고 나면,
보통 interviewer가 이렇게 물어봅니다.
“혹시 저한테 궁금한 점 있나요?”
대부분의 사람들은 두 가지 중 하나를 합니다.
- “아니요, 없습니다.”
- “하루 일과가 어떻게 되세요?” 같은 뻔한 질문
둘 다 엄청난 기회 낭비입니다.
10-1. 이건 회사가 나를 보는 시간인 동시에, 내가 회사를 보는 시간이다
인터뷰는 one-way 평가가 아닙니다.
- 회사: “이 사람과 같이 일하고 싶은가?”
- 나: “이 회사 / 팀과 같이 일하고 싶은가?”
를 서로 체크하는 자리입니다.
따라서 질문을 할 때도:
- 그냥 예의상 하는 generic 질문이 아니라
- 내가 정말 궁금한 것,
- 커리어에 도움 되는 것,
- 회사 선택에 영향을 줄 만한 것을 물어야 합니다.
10-2. 기억에 남는 질문의 예
Kevin이 좋아하는 질문 중 하나는 이런 종류입니다.
“만약 Google에서 첫 날로 돌아갈 수 있다면,
‘최고의 engineer가 되기 위해 꼭 이렇게 하라’고
예전의 자신에게 해 줄 조언이 하나 있다면 뭐였을까요?”
이 질문의 좋은 점:
- interviewer가 흔히 듣는 질문이 아닙니다.
- 상대의 경험에서 우러 나온 진짜 조언을 들을 수 있습니다.
- 그 답변은, 내가 그 회사에 가든 안 가든 내 커리어에 도움이 됩니다.
예를 들어 interviewer가 이렇게 말할 수도 있죠.
- “처음 한 달 동안은
팀 내 모든 사람과 1:1로 커피 챗을 잡고
질문을 마구 했으면 좋았을 것 같아요.”
이런 얘기는 어디 책에서 잘 안 나옵니다.
실제로 그 회사에서 senior/staff engineer로 일해 본 사람만 아는 인사이트죠.
그리고 솔직히 말하면,
인터뷰어 입장에서도 이런 질문이 훨씬 기억에 남습니다.
11. 합격하는 사람들의 공통점: 결국 “기술적으로 탄탄한 사람”
Kevin에게 물었습니다.
“성공하는 candidate들에게서
특히 공통으로 느껴지는 trait이 있나요?”
대답은 아주 단순했습니다.
“결국엔 technically competent한 사람입니다.”
- 문제를 받았을 때, 당황하지 않고
- data structure / algorithm을 적절히 선택하고
- 합리적인 time/space complexity를 가진 solution을 설계하고
- 그것을 시간 안에 구현할 수 있는 사람
그게 전부입니다.
화려한 말솜씨, 특이한 background, showmanship보다
**“이 사람에게 코드를 맡겨도 되겠다는 신뢰”**가 훨씬 중요합니다.
그리고 여기서 중요한 포인트 하나.
“이 45분짜리 인터뷰는
그 날 하루 컨디션만으로 결정되는 게 아니라,
그 이전 수개월, 수년 동안의 준비가 응축된 결과입니다.”
그래서 인터뷰를 Super Bowl 한 판처럼 생각하면
오히려 부담만 더 커집니다.
반대로 생각해 보세요.
- 내가 지난 몇 달 동안
차근차근 준비해 온 것을 45분 동안 보여주는 시간 - 결과는 이미 어느 정도 준비량에 따라 정해져 있고,
인터뷰는 그걸 확인하는 자리
이렇게 보면 훨씬 덜 무섭습니다.
12. 자주 하는 실수: 긴장, 침묵, Clarifying Questions 부족
마지막으로, Kevin이 반복해서 언급한 실패 패턴들을 정리해 봅니다.
12-1. 과도한 긴장
- 손이 떨리고
- 머리가 하얘지고
- 평소에 풀던 난이도 문제도 전혀 안 풀리는 상황
이걸 완전히 없애는 마법 같은 방법은 없습니다.
다만, 하나 확실한 건 있습니다.
“인터뷰 경험이 쌓이면, 긴장은 무조건 줄어든다.”
그래서 Kevin은 이렇게 제안합니다.
- 다른 회사 인터뷰도 많이 보라.
- 이 회사만 바라보고 올인하지 말고
- 다양한 회사, 다양한 포지션 인터뷰를 보면서
- “인터뷰”라는 상황 자체에 익숙해질 것
- mock interview를 적극 활용하라.
- 친구, 동료, 커뮤니티, 코칭 프로그램 등
- 실제 timer 재고, 말로 설명하면서 연습해 볼 것
어느 순간부터는
“아, 이건 그냥 또 하나의 인터뷰일 뿐”이라는 감각이 생깁니다.
12-2. Clarifying Questions를 안 한다
이건 정말 치명적입니다.
다시 강조하지만:
“문제가 주는 정보의 30%를 놓친 채로
solution을 제안하는 건
거의 guaranteed fail입니다.”
예를 들어:
- array에 negative number가 들어올 수 있다는 조건을 확인 안 하고
- 오직 positive만 가정하고 알고리즘을 짰다면
테스트 케이스 한두 개에서 깨지는 수준이 아니라,
애초에 문제를 다르게 이해한 것이 됩니다.
그래서 Kevin은 말합니다.
“Clarifying questions를 하지 않으면
사실상 recipe의 Step 2를 건너뛴 건데,
케이크 만들면서 밀가루를 안 넣는 것과 다를 게 없습니다.”
12-3. 침묵 → 멘붕 → 포기
마지막으로 가장 안 좋은 패턴.
- 문제 듣고
- 조용히 생각하다가
- 답이 안 떠오르면
- 점점 멘붕 + 침묵 길어짐
- 결국 포기 모드
이걸 막아 주는 게 바로
지금까지 이야기한 recipe + communication입니다.
- 문제 이해 과정부터 소리 내어 설명하고
- 모르는 부분은 clarifying questions로 채우고
- brute-force라도 하나 제안한 후
- 그 한계를 스스로 비판하면서 더 나은 방법을 찾아가는 모습
이렇게 하면,
완벽한 정답까지 못 가더라도 “pass”를 받을 여지가 충분히 생깁니다.
13. 마인드셋: Senior / Staff Engineer들은 인터뷰를 이렇게 본다
Tim이 했던 말 중 인상 깊은 게 하나 있습니다.
“senior / staff engineer들은
인터뷰에 들어갈 때 긴장해서 떨면서 들어가지 않습니다.”
그들은 보통 이런 태도에 가깝습니다.
- “이 회사가 내가 일하고 싶은 곳인가?”
- “내가 가진 skill을 그냥 차분히 보여주면 된다.”
물론 지금은 junior / new grad일 수 있지만,
우리가 지향해야 하는 태도는 여기입니다.
- technical interview를
“심판받는 자리”가 아닌
“내가 쌓아 온 실력을 보여주는 자리”로 보는 것
이 마인드셋은 하루아침에 생기지 않습니다.
하지만 위에서 얘기한 것처럼 충분한 준비와 반복된 경험이 쌓이면
조금씩 그쪽으로 이동하게 됩니다.
14. 마지막 정리: 진짜로 중요한 건 전부 “내가 컨트롤할 수 있는 것들”
Kevin이 마지막으로 남긴 메시지는 아주 단순합니다.
“You can absolutely do it.”
조금 더 길게 풀면:
- 시장이 어렵고, 채용 공고 수가 줄어드는 건
우리가 컨트롤할 수 없는 영역입니다. - 하지만
- 얼마나 많은 지원을 넣을지
- 하루에 LeetCode를 몇 문제 풀지
- data structure / algorithm 기본기를 어디까지 가져갈지
- mock interview를 얼마나 자주 볼지
- communication 스킬을 얼마나 연습할지
이런 것들은 전부 내가 결정할 수 있는 변수입니다.
그리고 결국 결과는:
**“내가 컨트롤할 수 있는 변수들을
얼마나 오래, 꾸준히, 진지하게 가져갔느냐”**의 함수입니다.
15. Technical Interview 자주 묻는 질문 (FAQ)
마지막으로, 위 내용 기반으로 자주 나올 만한 질문들을 정리해 볼게요.
Q1. 하루에 LeetCode 몇 문제 정도 푸는 게 좋나요?
A. 숫자보다 중요한 건 꾸준함입니다.
완전 초보라면 하루 1~2문제라도 괜찮고,
실력이 올라갈수록 3~5문제 정도까지 늘릴 수 있습니다.
중요한 건:
- 무작정 많이 푸는 것보다
- 풀고 난 뒤 solution 정리 + 패턴 정리까지 하는 것입니다.
Q2. company별 LeetCode frequency 문제만 집중적으로 풀어도 되나요?
A. “그것만” 풀면 안 되고, “플러스 알파”로 보는 게 좋습니다.
회사별 top 문제를 보는 건 due diligence 수준이고,
기본적인 data structure / algorithm topic 전체를
일단은 한 바퀴 도는 게 우선입니다.
Q3. recipe를 외워서 그대로 말해도 괜찮나요?
A. 네, 오히려 좋습니다.
다만, mechanical하게 읽는 느낌만 안 나게 하시면 됩니다.
예를 들어:
- 문제 이해
- clarifying questions
- brute-force + better solution 비교
- 코드 작성
- 코드 walkthrough
- pitfalls & optimization
- complexity 정리
이 순서를 머릿속에 두고, 자연스럽게 풀어내면 됩니다.
Q4. 인터뷰 중에 너무 긴장하면 어떻게 해야 하나요?
A. 아주 짧게라도 생각을 말로 꺼내는 것이 중요합니다.
- “지금 brute-force부터 한 번 생각해 볼게요.”
- “이 부분에서 이 data structure를 써보면 어떨까 떠올랐는데요…”
이렇게 말하는 순간,
혼자 머릿속에서만 싸우는 모드에서 벗어날 수 있습니다.
그리고 interviewer도 훨씬 도와주기 쉬워집니다.
Q5. clarifying questions는 몇 개 정도 해야 적당한가요?
A. 개수의 문제라기보다, 질의 문제입니다.
- input size
- value range
- 중복 가능 여부
- time / memory constraint
- special case (빈 배열, null, 음수 등)
이 정도 축을 기준으로
“이 문제에서 중요한 포인트가 될 만한 것”들을 물으면 됩니다.
Q6. 코드에 bug가 나오면 바로 탈락인가요?
A. 아닙니다.
대부분의 인터뷰어는 사람이 실수할 수 있다는 걸 잘 알고 있습니다.
중요한 것은:
- 본인이 bug를 스스로 찾는지
- 찾았을 때 침착하게 고치는지
- 그 과정에서 reasoning을 잘 설명하는지
입니다.
그래서 Rubber Duck Debugging이 중요합니다.
Q7. 영어 communication이 부족한데, 이게 치명적인가요?
A. 회사와 팀에 따라 다르지만,
기본적인 communication은 어쨌든 필요합니다.
다만, 완벽한 영어를 요구하는 건 아닙니다.
- 짧고 간단한 문장으로
- 천천히
- 핵심만 말하는 연습을 하면
충분히 커버할 수 있습니다.
Q8. mock interview는 누구랑 하는 게 좋나요?
A. 최선은:
- 실제로 인터뷰를 많이 해 본 동료 / 선배 / 멘토
- 또는 전문 코칭 프로그램(예: Dev Launch처럼)을 통한 mock
하지만 그런 사람이 없다면,
- 함께 준비하는 친구들과 돌아가며 interviewer 역할을 교대로 하거나
- 온라인 mock interview 플랫폼을 활용하는 것도 방법입니다.
Q9. technical interview 준비는 어느 정도 기간을 잡아야 하나요?
A. 현재 실력에 따라 다르지만,
보통은 최소 2~3개월 정도 꾸준한 준비를 권장합니다.
- data structure / algorithm 개념 복습 2~3주
- 주요 LeetCode topic별 집중 연습 4~6주
- mock interview + 실전 감각 길러오기 2~4주
이 정도 그림으로 생각해 보시면 좋습니다.
Q10. market이 너무 안 좋은데, 지금 준비해도 의미가 있을까요?
A. 당연히 있습니다.
시장 상황은 우리가 바꿀 수 없지만,
내 실력은 언제든지 올려둘 수 있습니다.
그리고 좋은 회사들은 언제나 진짜로 실력 있는 사람은 뽑습니다.
그렇기 때문에 지금 준비해 두는 것이
시장 회복 시점에서 가장 큰 레버리지가 됩니다.
여기까지 읽으셨다면,
이미 technical interview에 대해 “막연한 공포” 대신
**“구체적인 할 일 리스트”**가 머릿속에 생겼을 거라고 믿습니다.
- 프로세스 이해하기
- LeetCode로 topic별 패턴 익히기
- 나만의 7단계 recipe 만들기
- communication & clarifying 질문 연습
- mock interview로 실전 감각 기르기
이 다섯 가지만 꾸준히 밀고 나가면,
지금은 멀게 느껴지는 그 Big Tech offer도
충분히 현실적인 목표가 될 수 있습니다.
정리하면 딱 한 줄입니다.
“결국 technical interview는
운이 아니라, 준비한 만큼 보이는 시험이다.”
이제부터는, 준비만 남았습니다.
'SW > 면접' 카테고리의 다른 글
| 2026년 프로그래밍 언어 추천: AI 시대에 살아남는 Core + Niche 선택법 (0) | 2026.02.16 |
|---|---|
| 개발자 연봉 앞자리가 바뀌는 Technical Interview 준비 핵심 전략 (0) | 2026.02.14 |
| 코딩테스트 대비 자료구조 정리: 꼭 알아야 할 핵심 개념과 활용 예시 (0) | 2026.01.08 |
| AI가 DevOps 엔지니어를 대체할까? 2026년 기준 현실적인 전망과 커리어 전략 (0) | 2026.01.07 |
| 컴공 졸업했는데 취업 막막할 때: 신입 Software Engineer 살아남는 현실 전략 (0) | 2026.01.04 |