software

코딩 인터뷰 중에 LeetCode 솔루션을 소리 내어 설명하는 방법

발행: (2025년 12월 8일 오후 12:15 GMT+9)
8 min read
원문: Dev.to

Source: Dev.to

TL;DR

왜 말해야 하는가 – 면접관은 과정을 평가하고, 최종 코드만 보는 것이 아닙니다.
침묵은 당신의 역량을 추측하게 만들고, 말을 하면 체계적인 사고를 보여줄 수 있습니다.

무엇을 말해야 하는가 – UMPIRE 프레임워크를 따르세요: Understand(이해), Match(매치), Plan(계획), Implement(구현), Review(검토), Evaluate(평가). 각 단계마다 구체적으로 말해야 할 포인트가 있습니다.

어떻게 연습할까 – 문제를 풀면서 스스로를 녹음하세요. 처음엔 어색하지만 반복하면 자연스러워집니다.

불확실할 때 – “X에 대해 생각하고 있어요” 혹은 “두 가지 접근법을 고려해볼게요”라고 말하고 침묵을 피하세요. 행동만이 아니라 추론 과정을 서술합니다.

흔한 실수 – “이제 반복문을 작성하고 있어요”처럼 무엇을 코딩하고 있는지 설명하는 것이 아니라, “왜 반복문이 필요한지”처럼 왜 하는지를 설명해야 합니다.

배우게 될 것 – 각 면접 단계별 구조화된 말하기 템플릿, 불확실성을 자신 있게 전달하는 방법, 그리고 체계적인 사고를 보여주는 정확한 문구들.

왜 침묵이 고군분투로 해석되는가

면접관 입장

  • 당신의 사고 과정을 볼 수 없습니다.
  • 침묵은 막힌 것, 혼란스러운 것, 진행 중인 것, 포기한 것 중 어느 것이든 될 수 있습니다.
  • 도와주고 싶지만, 어디서 어려움을 겪는지 모릅니다.

지원자 입장

  • 깊게 생각하고 있습니다.
  • 틀린 말을 하고 싶지 않습니다.
  • 침묵 = 집중 = 생산성이라고 가정합니다.

갭 – 당신에게는 생산적으로 보이는 것이 면접관에게는 우려로 비칩니다.
해결책 – 내부 독백을 외부화하세요. 면접관을 평가자가 아니라 협업자로 만들어요.

“큰소리로 생각하기(Thinking Out Loud)”가 실제 의미하는 바

이렇게 하면 안 됨 (행동만 설명)

"I'm writing a for loop... now I'm declaring a variable... now I'm checking if..."

이렇게 하면 좋음 (이유 설명)

// Example in JavaScript
// Explain why you choose each step
"I need to iterate through the array because I'm looking for pairs that meet a condition. 
I'm tracking seen values in a hash map so I can check if the complement exists in O(1) time. 
Let me code that up..."

차이점 – 두 번째는 왜 하는지를 보여주어 문제 구조를 이해하고 의도적인 선택을 했음을 증명합니다.

This connects to broader interview communication strategies.

단계별 학습 가이드

Phase 1: Understand (문제 명확히 파악)

말해야 할 내용 – 문제를 자신의 말로 다시 말하고, 명확히 해야 할 질문을 합니다.

템플릿

"So if I understand correctly, we need to [restate problem].
The input is [describe input format and constraints].
The output should be [describe expected output].
Can I assume [clarifying question about edge cases or constraints]?"

예시

"So we're finding two numbers in the array that sum to the target value.
The input is an array of integers and a target number.
We should return the indices of those two numbers, not the values themselves.
Can I assume there's always exactly one solution, or should I handle the case where no solution exists?"

왜 효과적인가

  • 엣지 케이스를 고민하고 있음을 보여줍니다.
  • 코딩 전에 이해도를 확인합니다.
  • 오해가 있으면 바로 대화로 잡을 수 있습니다.

Phase 2: Match (패턴 찾기)

말해야 할 내용 – 문제 유형을 식별하고 선택한 기법을 정당화합니다.

템플릿

"This looks like a [pattern/category] problem because [reasoning].
I'm thinking of using [data structure or algorithm] because [justification]."

예시

"This looks like a hash‑map problem because we need to find pairs that sum to a target, which means for each element we must quickly check if its complement exists. 
A hash map gives us O(1) lookup, which is better than the O(n²) brute‑force approach of checking every pair."

왜 효과적인가

  • 패턴 인식을 보여줍니다.
  • 복잡도를 고려하고 있음을 나타냅니다.
  • 코딩 전에 접근 방식을 설명합니다.

Phase 3: Plan (접근법 설계)

말해야 할 내용 – 코드를 작성하기 전에 알고리즘을 고수준으로 설명합니다.

템플릿

"Here's my approach:
1. [Step 1 in plain English]
2. [Step 2 in plain English]
3. [Step 3 in plain English]

The time complexity should be O([complexity]) because [reasoning].
Space complexity is O([complexity]) for [data structure]."

예시

"Here's my plan:
1. Create a hash map to store values we've seen and their indices.
2. Iterate through the array once.
3. For each element, calculate the complement (target minus current value).
4. Check if the complement exists in our map.
5. If yes, return those two indices; otherwise, add the current value to the map.

Time complexity is O(n) because we iterate once, and hash‑map operations are O(1).
Space complexity is O(n) in the worst case if we store every element."

왜 효과적인가

  • 면접관에게 로드맵을 제공합니다.
  • 문제를 일찍 발견할 수 있게 합니다.
  • 효율성을 고민하고 있음을 보여줍니다.

Phase 4: Implement (코드 작성 중 설명)

말해야 할 내용 – 핵심 결정과 논리를 서술하고, 모든 키 입력을 말하지는 않습니다.

템플릿

"I'm [doing X] because [reason].
This handles [edge case or special condition].
Let me add [feature] to cover [scenario]."

예시 (TypeScript/JavaScript)

// Explain while coding
"I'll initialize an empty hash map to track seen values..."
const seen = new Map();

"I now iterate through the array. For each element, I calculate the complement..."
for (let i = 0; i < nums.length; i++) {
  const complement = target - nums[i];

  "I check if the complement exists in the map. If it does, I've found my pair..."
  if (seen.has(complement)) {
    return [seen.get(complement)!, i];
  }

  "Otherwise, I store this value and move to the next element..."
  seen.set(nums[i], i);
}

내레이션 하지 말아야 할 것

  • 변수 이름을 하나씩 타이핑하는 과정.
  • 구문 세부 사항(예: “세미콜론을 입력합니다”).
  • 명백한 동작(예: “Enter 키를 누릅니다”).

내레이션 해야 할 것

  • 특정 자료구조를 선택한 이유.
  • 엣지 케이스를 어떻게 처리하는지.
  • 핵심 논리적 결정.
Back to Blog

관련 글

더 보기 »