개발자 기술 면접 준비: 알고리즘부터 시스템 설계까지
이 글의 핵심
기술 면접을 코딩 테스트·시스템 설계·CS 기초·프로젝트 경험 네 영역으로 나눠 3개월 동안 병행하는 순서를 정리합니다. URL 단축 서비스 설계를 45분 흐름으로 따라가며 301과 302 선택 같은 트레이드오프를 설명하는 법, CS 답변에서 꼬리 질문에 대비하는 법, 막혔을 때의 대응을 다룹니다.
들어가며: 면접에서 무엇을 보는가
개발자 기술 면접은 코딩 능력, 문제 해결 능력, 시스템 설계 능력, 커뮤니케이션 능력을 종합적으로 평가합니다.
이 글에서 다루는 것:
- 면접 유형별 준비 전략
- 코딩 테스트 대비
- 시스템 설계 면접
- CS 기초 질문
- 프로젝트 경험 질문
- 면접 중 대처법
이 글은 네 가지 영역(코딩 테스트, 시스템 설계, CS 기초, 프로젝트 경험)을 하나의 3개월 로드맵으로 묶어서 보여주는 데 초점을 맞춥니다. 각 영역을 깊이 파고드는 별도 글이 이미 있으므로, 여기서는 영역별 핵심만 짚고 더 자세한 내용은 해당 글로 연결합니다. 예를 들어 코딩 테스트 알고리즘 패턴을 깊게 공부하고 싶다면 코딩 테스트 대비 가이드를, 실제 대규모 시스템 설계 사례를 보고 싶다면 백엔드·게임 서버 시스템 설계를 함께 읽는 것을 추천합니다.
준비 순서를 정할 때 흔히 하는 실수는 코딩 테스트에만 시간을 쏟다가 시스템 설계와 CS 기초를 면접 직전에 몰아서 보는 것입니다. 실제 채용 프로세스에서는 1차 면접에서 알고리즘과 CS 기초를, 2차 면접에서 시스템 설계와 프로젝트 경험을 함께 평가하는 경우가 많으므로, 처음부터 네 영역을 병행해서 준비하는 편이 실전에서 더 안정적인 결과로 이어집니다.
면접 유형
기술 면접 프로세스
flowchart LR
A[서류 전형] --> B[코딩 테스트]
B --> C[1차 기술 면접]
C --> D[2차 기술 면접]
D --> E[최종 면접]
C --> C1[알고리즘 + CS 기초]
D --> D1[시스템 설계 + 프로젝트]
회사마다 단계 수와 이름은 다르지만, 대부분 “자동 채점되는 코딩 테스트 → 사람이 보는 기술 면접 → 컬처·임원 면접” 흐름을 따릅니다. 신입 채용일수록 코딩 테스트와 CS 기초의 비중이 크고, 경력 채용일수록 시스템 설계와 프로젝트 경험 질문이 면접 시간의 대부분을 차지합니다. 지원하는 포지션이 어느 쪽인지 먼저 확인하고 아래 시간 배분을 조정하세요.
영역별 준비 시간 배분 (신입 기준 예시)
| 면접 유형 | 준비 시간 비율 | 준비 기간 |
|---|---|---|
| 코딩 테스트 | 40% | 3개월 내내 |
| 시스템 설계 | 25% | 2개월차부터 |
| CS 기초 | 20% | 1개월차부터 |
| 프로젝트 경험 | 15% | 1개월차 초안, 이후 다듬기 |
이 비율은 공식 통계가 아니라 준비 시간을 나누는 출발점입니다. 코딩 테스트에 가장 많은 시간을 배정하는 이유는 가장 앞 단계에서 기계적으로 탈락이 결정되고, 실력이 오르는 데 시간이 가장 오래 걸리기 때문입니다. 반대로 프로젝트 경험은 이미 한 일을 정리하는 작업이라 시간은 적게 들지만, 면접에서 가장 오래 이야기하게 되는 주제이므로 비중이 작다고 소홀히 해서는 안 됩니다.
코딩 테스트 준비
코딩 테스트는 준비 기간의 절반 가까이를 차지하는 영역입니다. 아래 체크리스트는 무엇을, 어떤 순서로 공부할지 큰 그림을 보여주기 위한 것이며, 각 알고리즘의 개념·자주 하는 실수·언어별 구현까지 깊이 있게 다루고 싶다면 코딩 테스트 대비 가이드를 참고하세요.
필수 알고리즘 체크리스트
1단계: 기초 (1개월)
- 배열, 문자열
- 해시맵, 해시셋
- 투 포인터
- 슬라이딩 윈도우
- 이진 탐색
2단계: 중급 (1개월)
- 스택, 큐
- BFS, DFS
- 트리 순회
- 동적 프로그래밍 기초
- 그리디
3단계: 고급 (1개월)
- 동적 프로그래밍 고급
- 백트래킹
- 그래프 알고리즘 (다익스트라, 위상 정렬)
- 트라이
- Union-Find
이 순서는 난이도보다 의존 관계를 따른 것입니다. 해시맵과 투 포인터는 이후 거의 모든 문제에서 부분 도구로 쓰이고, BFS/DFS를 알아야 트리 순회와 그래프 알고리즘이 이해되며, 백트래킹은 DFS의 변형입니다. 문제 수를 채우는 것보다 한 주제를 끝낼 때 “이 패턴은 어떤 입력 조건에서 떠올려야 하는가”를 한 줄로 적어 두는 편이 실전에서 훨씬 도움이 됩니다. 예를 들어 “정렬된 배열 + 두 값의 합 → 투 포인터”, “최단 거리 + 가중치 없음 → BFS” 같은 메모입니다.
문제 풀이 전략
UMPIRE 방법론:
U - Understand (이해)
M - Match (패턴 매칭)
P - Plan (계획)
I - Implement (구현)
R - Review (검토)
E - Evaluate (평가)UMPIRE는 풀이를 여섯 단계로 나눠 구현에 들어가기 전에 말로 합의하는 시간을 강제하는 틀입니다. 라이브 코딩 면접에서 가장 흔한 실패는 문제를 다 읽자마자 코드를 쓰기 시작했다가 10분 뒤 조건을 잘못 이해했음을 깨닫는 것인데, U와 P 단계에서 입력 크기와 예외 조건을 면접관에게 확인하면 이 사고를 대부분 막을 수 있습니다.
예제: LeetCode 1. Two Sum
# U - Understand
# 입력: nums = [2, 7, 11, 15], target = 9
# 출력: [0, 1] (nums[0] + nums[1] = 2 + 7 = 9)
# 제약: 정확히 하나의 해 존재
# M - Match
# 패턴: 해시맵 (O(n) 해결 가능)
# P - Plan
# 1. 해시맵에 {값: 인덱스} 저장
# 2. 각 원소마다 complement = target - 현재값 계산
# 3. complement가 해시맵에 있으면 반환
# I - Implement
def two_sum(nums, target):
seen = {}
for i, num in enumerate(nums):
complement = target - num
if complement in seen:
return [seen[complement], i]
seen[num] = i
return None
# R - Review
# 테스트 케이스:
# [2, 7, 11, 15], 9 → [0, 1] ✅
# [3, 2, 4], 6 → [1, 2] ✅
# [3, 3], 6 → [0, 1] ✅
# E - Evaluate
# 시간복잡도: O(n)
# 공간복잡도: O(n)이 풀이에서 면접관이 눈여겨보는 부분은 seen[num] = i를 확인 뒤에 넣는 순서입니다. 먼저 넣고 확인하면 [3, 3], 6 같은 입력은 통과하지만 [3, 2, 4], 6에서 3이 자기 자신과 짝지어져 [0, 0]을 반환합니다. R 단계의 테스트 케이스가 바로 이런 순서 버그를 잡기 위한 것이며, 테스트를 말로 따라가는 모습 자체가 좋은 평가 요소가 됩니다. 추가 질문으로 “배열이 정렬되어 있다면?”이 자주 나오는데, 이때는 공간 O(1)인 투 포인터로 바꿀 수 있다고 답하면 됩니다.
언어별 코드 템플릿
Python:
# 입력 처리
n = int(input())
arr = list(map(int, input().split()))
# 또는 여러 줄
import sys
input = sys.stdin.readline
# 출력
print(result)
# 자주 쓰는 import
from collections import deque, Counter, defaultdict
from heapq import heappush, heappop
import bisectPython에서 입력이 수십만 줄인 문제를 input()으로 읽으면 시간 초과가 나는 경우가 많아 sys.stdin.readline으로 바꾸는 것이 관례입니다. 다만 readline은 줄 끝 개행 문자를 남기므로 문자열을 읽을 때는 .strip()을 붙여야 하고, 빠뜨리면 문자열 비교가 전부 실패합니다. 재귀 DFS는 기본 재귀 한도(1000)에 걸려 RecursionError: maximum recursion depth exceeded가 나기 쉬우니 sys.setrecursionlimit을 올리거나 스택으로 바꾸세요.
C++:
#include <iostream>
#include <vector>
#include <algorithm>
#include <unordered_map>
#include <queue>
#include <stack>
using namespace std;
int main() {
ios_base::sync_with_stdio(false);
cin.tie(nullptr);
int n;
cin >> n;
vector<int> arr(n);
for (int i = 0; i < n; i++) {
cin >> arr[i];
}
// 로직
cout << result << '\n';
return 0;
}sync_with_stdio(false)를 쓴 뒤에는 printf/scanf와 cin/cout을 섞으면 출력 순서가 뒤섞이므로 한쪽만 써야 합니다. 또 endl은 매번 버퍼를 비워 출력이 많은 문제에서 시간 초과의 원인이 되므로 '\n'을 쓰는 편이 안전합니다.
시스템 설계 면접
시스템 설계 면접은 정답이 하나가 아니라, 주어진 시간 안에 요구사항을 파악하고 근거 있는 트레이드오프를 설명하는 능력을 평가합니다. 아래에서는 URL 단축 서비스를 예로 들어 45분짜리 면접에서 실제로 진행되는 순서를 그대로 재현합니다. 대규모 동시 접속을 다루는 백엔드·게임 서버 아키텍처 사례를 더 깊이 보고 싶다면 백엔드·게임 서버 시스템 설계 가이드도 함께 참고하세요.
시스템 설계 프로세스
flowchart LR
A[요구사항 분석 5분] --> B[용량 추정 5분]
B --> C[API 설계 5분]
C --> D[데이터베이스 설계 10분]
D --> E[아키텍처 설계 15분]
E --> F[트레이드오프 논의 5분]
예제: URL 단축 서비스 설계
1. 요구사항 분석 (5분)
기능 요구사항:
- 긴 URL을 짧은 URL로 변환
- 짧은 URL로 접속 시 원본 URL로 리다이렉트
- URL 통계 (클릭 수)
비기능 요구사항:
- 높은 가용성
- 낮은 지연 시간
- 확장 가능2. 용량 추정 (5분)
가정:
- 일일 활성 사용자: 100만 명
- 사용자당 URL 생성: 1개/일
- 읽기:쓰기 비율 = 100:1
계산:
- 쓰기: 100만 URL/일 ≈ 12 URL/초
- 읽기: 약 1,200 URL/초
- 저장: 100만 × 365 × 5년 ≈ 18억 URL
- 저장 용량: 18억 × 500 bytes ≈ 900GB용량 추정은 정확한 숫자보다 결론을 끌어내는 데 의미가 있습니다. 위 계산에서 나오는 결론은 “쓰기는 초당 십여 건이라 DB 한 대로 충분하고, 읽기가 100배 많으니 캐시와 읽기 복제본이 핵심”이라는 것입니다. 900GB도 단일 서버에 들어가는 크기라 처음부터 샤딩을 꺼낼 필요는 없다고 말할 수 있어야 합니다. 숫자를 계산해 놓고 그 결론을 아키텍처에 반영하지 않으면 추정 단계를 한 의미가 없습니다.
3. API 설계 (5분)
POST /api/shorten
{
"url": "https://example.com/very/long/url"
}
→ { "short_url": "https://short.ly/abc123" }
GET /abc123
→ 302 Redirect to https://example.com/very/long/url
GET /api/stats/abc123
→ { "clicks": 1234, "created_at": "2026-03-31" }여기서 좋은 꼬리 질문 소재가 되는 것이 301과 302의 선택입니다. 301(Moved Permanently)은 브라우저가 결과를 캐시하므로 두 번째 방문부터는 서버를 거치지 않아 부하가 줄지만, 그만큼 클릭 수를 셀 수 없습니다. 클릭 통계가 요구사항에 있으니 302(또는 307)를 쓰고, 부하는 캐시로 해결한다고 설명하면 요구사항과 설계가 연결됩니다.
4. 데이터베이스 설계 (10분)
-- URL 테이블
CREATE TABLE urls (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
short_code VARCHAR(10) UNIQUE NOT NULL,
original_url TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
expires_at TIMESTAMP,
clicks INT DEFAULT 0
);short_code에 UNIQUE 제약을 걸면 MySQL은 자동으로 유니크 인덱스를 만들기 때문에 별도의 INDEX를 또 선언할 필요가 없습니다(같은 컬럼에 인덱스가 두 개 생겨 쓰기 비용만 늘어납니다). 또 clicks를 이 테이블에서 매번 UPDATE하면 인기 URL 하나에 행 잠금이 몰리므로, 실무에서는 클릭 이벤트를 큐로 보내 따로 집계하는 구조가 흔합니다. 아래 아키텍처에 Kafka와 분석 DB가 있는 이유가 이것입니다.
5. 아키텍처 설계 (15분)
graph TB
A[클라이언트] --> B[로드 밸런서]
B --> C[웹 서버 1]
B --> D[웹 서버 2]
B --> E[웹 서버 3]
C --> F[Redis 캐시]
D --> F
E --> F
F --> G[MySQL Primary]
G --> H[MySQL Replica 1]
G --> I[MySQL Replica 2]
C --> J[분석 서비스]
D --> J
E --> J
J --> K[Kafka]
K --> L[분석 DB]
6. 트레이드오프 논의 (5분)
질문: "짧은 코드는 어떻게 만들고, 충돌은 어떻게 처리하나요?"
답변:
- Base62 인코딩 (a-z, A-Z, 0-9) 사용
- 7자리 = 62^7 ≈ 3.5조 조합
- 방법 A: 자동 증가 ID를 Base62로 변환 → 충돌 없음, 대신 코드가 순차적이라 추측 가능
- 방법 B: 해시/랜덤 → 추측 어려움, 대신 충돌 시 재생성 필요
질문: "캐시는 어떻게 관리하나요?"
답변:
- Redis에 인기 URL 캐시 (LRU)
- TTL 1시간
- 캐시 미스 시 DB 조회 후 캐시 저장짧은 코드 생성은 이 문제의 핵심 트레이드오프입니다. ID를 Base62로 바꾸는 방식은 충돌이 원천적으로 없지만 abc123 다음이 abc124라 다른 사람의 링크를 순서대로 훑어볼 수 있고, 여러 서버가 ID를 발급하려면 ID 생성기를 따로 두어야 합니다. 랜덤 방식은 추측이 어렵지만 저장 전에 존재 여부를 확인해야 하고 URL 수가 늘수록 충돌 확률이 올라갑니다. 어느 쪽이 맞다고 단정하기보다 “공개 링크 추측이 문제가 되는 서비스라면 B”처럼 조건을 붙여 답하는 것이 좋습니다.
제가 모의 면접을 진행해 보면 가장 많이 보는 실수는 5단계 다이어그램을 먼저 그려 놓고 나머지를 거꾸로 맞추는 것입니다. Redis, Kafka, 샤딩을 전부 그려 놓았는데 “왜 Kafka가 필요하냐”는 질문에 요구사항에서 근거를 대지 못하면 오히려 감점이 됩니다. 컴포넌트는 앞 단계에서 나온 숫자나 요구사항이 요구할 때만 추가하세요.
시스템 설계 필수 주제
1. 확장성 (Scalability):
- 수평 확장 (Scale-out)
- 로드 밸런싱
- 샤딩 (Sharding)
2. 가용성 (Availability):
- 복제 (Replication)
- 장애 조치 (Failover)
- 헬스 체크
3. 성능 (Performance):
- 캐싱 (Redis, CDN)
- 데이터베이스 인덱싱
- 비동기 처리
4. 일관성 (Consistency):
- ACID vs BASE
- CAP 정리
- 최종 일관성
이 주제들은 따로 외우기보다 서로 부딪히는 지점을 이해하는 것이 중요합니다. 읽기 복제본을 추가하면 가용성과 읽기 성능이 좋아지지만, 복제 지연 때문에 “방금 만든 URL이 다른 서버에서 404”가 되는 일관성 문제가 생깁니다. 면접에서 한 선택의 장점을 말했다면 바로 그 선택이 만드는 새로운 문제까지 말하는 습관을 들이세요.
CS 기초 질문
자주 나오는 질문
운영체제:
- 프로세스 vs 스레드
- 교착 상태 (Deadlock)
- 가상 메모리
- 컨텍스트 스위칭
네트워크:
- HTTP vs HTTPS
- TCP vs UDP
- REST API
- DNS
데이터베이스:
- 정규화
- 인덱스
- 트랜잭션
- ACID
자료구조:
- 시간복잡도
- 배열 vs 연결 리스트
- 해시 테이블
- 트리 (이진 트리, BST)
모범 답변 예제
질문: “프로세스와 스레드의 차이는?”
답변:
프로세스 (Process):
- 독립적인 실행 단위
- 독립적인 메모리 공간 (Code, Data, Heap, Stack)
- 프로세스 간 통신 (IPC) 필요
- 생성/전환 비용 높음
스레드 (Thread):
- 프로세스 내 실행 단위
- 메모리 공간 공유 (Code, Data, Heap)
- Stack만 독립적
- 생성/전환 비용 낮음
예시:
- Chrome 브라우저: 탭(사이트)마다 별도 프로세스 → 한 탭이 죽어도 나머지는 유지
- 전통적인 웹 서버: 요청마다 스레드 (요즘은 스레드 풀·이벤트 루프가 일반적)CS 질문은 첫 답변보다 꼬리 질문에서 실력이 드러납니다. 위 답변 뒤에는 거의 반드시 “그럼 스레드가 메모리를 공유해서 생기는 문제는?”(경쟁 상태, 락), “컨텍스트 스위칭 비용이 왜 스레드가 더 싼가?”(주소 공간 전환과 TLB 플러시가 필요 없음) 같은 질문이 따라옵니다. 정의를 외우는 데서 멈추지 말고 “왜 그런가”를 한 단계 더 준비하세요.
질문: “HTTP와 HTTPS의 차이는?”
답변:
HTTP (HyperText Transfer Protocol):
- 평문 통신
- 기본 포트 80
- 도청·변조에 취약
HTTPS (HTTP Secure):
- TLS로 암호화한 HTTP
- 기본 포트 443
- 연결 시작 시 TLS 핸드셰이크 비용이 있음 (TLS 1.3에서는 1-RTT로 줄어듦)
- 인증서로 서버 신원 확인
차이점:
- HTTPS는 중간자 공격 (MITM) 방지
- HTTP/2는 브라우저에서 사실상 HTTPS에서만 사용됨
- 검색엔진이 HTTPS를 순위 신호로 사용“HTTPS는 느리다”는 답은 요즘 면접에서 오히려 감점 요인이 될 수 있습니다. 암호화 연산 자체는 현대 CPU에서 부담이 거의 없고, 비용은 주로 연결 수립 시 핸드셰이크에 있으며, 세션 재개와 TLS 1.3으로 그마저 줄었습니다. 꼬리 질문으로는 “TLS 핸드셰이크 과정을 설명해 보라”, “인증서는 어떻게 검증되나(인증서 체인, 루트 CA)“가 자주 나옵니다.
프로젝트 경험 질문
STAR 방법론
S - Situation (상황)
T - Task (과제)
A - Action (행동)
R - Result (결과)예제 답변
질문: “가장 어려웠던 기술적 문제는?”
답변 (STAR 방식):
S (상황):
"전자상거래 사이트에서 주문 처리 시 재고 부족 문제가 발생했습니다.
동시에 여러 사용자가 마지막 재고를 주문하면 음수 재고가 발생했습니다."
T (과제):
"동시성 제어를 통해 재고 정합성을 보장해야 했습니다."
A (행동):
"1. 문제 분석: Race Condition 확인
2. 해결 방법 조사: 낙관적 잠금 vs 비관적 잠금
3. 구현: PostgreSQL의 SELECT FOR UPDATE 사용
4. 테스트: JMeter로 동시 요청을 걸어 음수 재고가 재현되지 않는지 확인"
R (결과):
"음수 재고가 더 이상 발생하지 않았고, 잠금 대기로 늘어난 응답 시간을
측정해 허용 범위 안임을 확인했습니다." (실제 답변에서는 본인이 측정한 수치를 쓰세요)STAR 답변에서 면접관이 가장 깊게 파고드는 부분은 A(행동)입니다. 위 예시라면 “왜 낙관적 잠금 대신 비관적 잠금을 택했나?”, “SELECT FOR UPDATE로 인한 대기 시간은 어땠나?”, “재고 차감을 UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty > 0처럼 한 문장으로 처리하는 방법은 검토했나?” 같은 질문이 이어집니다. R(결과)에 숫자를 넣는 것은 좋지만, 직접 측정하지 않은 숫자를 말하면 “어떻게 측정했나”라는 질문 한 번에 무너집니다. 기억나지 않는 수치를 꾸미기보다 “정확한 수치는 기억나지 않지만 이렇게 측정했다”고 말하는 편이 안전합니다.
자주 나오는 질문
기술 선택:
- “왜 이 기술을 선택했나요?”
- “다른 대안은 고려했나요?”
- “장단점은 무엇인가요?”
문제 해결:
- “어떤 어려움이 있었나요?”
- “어떻게 해결했나요?”
- “다시 한다면 어떻게 하겠나요?”
성능:
- “성능 최적화는 어떻게 했나요?”
- “병목은 어디였나요?”
- “어느 정도 개선되었나요?”
“다시 한다면 어떻게 하겠나요?”는 준비 없이 받으면 가장 당황하는 질문입니다. 이 질문은 결함을 찾으려는 것이 아니라 회고할 줄 아는지를 보는 것이므로, “당시에는 일정 때문에 X를 택했지만 지금이라면 Y를 쓰겠다, 이유는 Z”처럼 구체적인 개선점 하나를 미리 준비해 두세요.
면접 중 대처법
코딩 테스트 대처
1. 소리 내어 생각하기
❌ 조용히 코드만 작성
✅ "이 문제는 투 포인터로 풀 수 있을 것 같습니다.
정렬된 배열이므로 O(n) 시간복잡도로 해결 가능합니다."2. 시간복잡도 먼저 말하기
"먼저 브루트포스로 O(n²) 해결이 가능하지만,
해시맵을 사용하면 O(n)으로 최적화할 수 있습니다."3. 테스트 케이스 설명
"빈 배열, 크기 1인 배열, 모두 같은 값인 경우를 테스트하겠습니다."소리 내어 생각하기는 연습하지 않으면 실전에서 되지 않습니다. 혼자 문제를 풀 때도 풀이 과정을 녹음하거나 친구에게 설명하면서 풀어 보면, 말하느라 손이 멈추는 구간이 어디인지 알 수 있습니다. 브루트포스를 먼저 말하는 것도 중요한데, 최적 해법이 끝내 떠오르지 않더라도 동작하는 답과 그 한계를 이미 제시한 상태가 되기 때문입니다.
시스템 설계 대처
1. 요구사항 명확히 하기
질문:
- "일일 활성 사용자는 몇 명인가요?"
- "읽기와 쓰기 비율은 어떻게 되나요?"
- "데이터 일관성이 중요한가요, 아니면 가용성이 중요한가요?"2. 다이어그램 그리기
화이트보드나 종이에 아키텍처 다이어그램을 그리며 설명하세요.
- 클라이언트
- 로드 밸런서
- 웹 서버
- 캐시
- 데이터베이스
- 메시지 큐3. 트레이드오프 설명
"Redis를 캐시로 사용하면 읽기 성능은 좋아지지만,
캐시 일관성 문제가 발생할 수 있습니다.
이를 위해 TTL을 짧게 설정하거나 Write-Through 캐시를 사용할 수 있습니다."면접 중 실수 대처
1. 모르는 질문
❌ "모르겠습니다" (바로 포기)
✅ "정확히는 모르지만, 제 생각에는 ... 일 것 같습니다.
이 부분은 면접 후 더 공부하겠습니다."2. 코드 에러
❌ 당황하며 수정
✅ "아, 여기서 인덱스 범위를 체크해야 합니다.
수정하겠습니다."3. 시간 부족
❌ 급하게 코드 작성
✅ "시간이 부족하니 핵심 로직만 구현하며,
엣지 케이스는 주석으로 설명드리겠습니다."모르는 질문에 추측으로 답할 때는 추측이라는 점을 분명히 밝히는 것이 핵심입니다. 확신 있는 말투로 틀린 답을 하면 면접관은 “모르는 것을 모른다고 말하지 못하는 사람”으로 기록하고, 이는 실무에서 장애를 숨기는 성향과 연결되어 해석되기 때문입니다.
정리
3개월 준비 플랜
1개월차: 알고리즘 기초
- 배열, 해시맵, 투 포인터, 슬라이딩 윈도우
- LeetCode Easy 50문제
- CS 기초 복습 (운영체제, 네트워크)
2개월차: 알고리즘 중급
- BFS/DFS, 동적 프로그래밍, 그리디
- LeetCode Medium 50문제
- 시스템 설계 기초 학습
3개월차: 고급 + 모의 면접
- 동적 프로그래밍 고급, 그래프 알고리즘
- LeetCode Medium 50문제 + Hard 20문제
- 시스템 설계 연습 10개
- 모의 면접 5회
문제 수는 목표치일 뿐입니다. 풀지 못한 문제를 해설로 이해하고 넘어가면 그 문제를 푼 것이 아니므로, 며칠 뒤 해설 없이 다시 풀어 보는 “재풀이 목록”을 따로 관리하는 편이 문제 수를 늘리는 것보다 효과적입니다.
면접 체크리스트
면접 전날:
- 알고리즘 템플릿 복습
- 프로젝트 경험 정리
- 자주 나오는 질문 답변 준비
- 충분한 수면
면접 당일:
- 노트북, 충전기 준비
- 화이트보드 마커 (오프라인)
- 30분 일찍 도착
- 편안한 복장
면접 중:
- 소리 내어 생각하기
- 질문 적극적으로 하기
- 시간 관리
- 긍정적 태도
면접 후:
- 받은 질문과 막힌 부분 기록
- 부족한 부분 복습
- 다음 면접 준비
학습 자료
코딩 테스트:
시스템 설계:
CS 기초:
다음 단계
면접 준비의 각 영역별 자세한 내용은 아래 글을 참고하세요:
- 코딩 테스트 전략
- 개발 취업 실전 팁 (이력서·포트폴리오·지원)
- 개발자 이력서·서류·면접 가이드 — 문서·말하기를 한 스토리로 맞추기
- 개발자 채용 공고 사이트 가이드 — 공고 모으기·지원 표
- 알고리즘 시리즈
- 백엔드·게임 서버 시스템 설계 (대규모 동시 접속)
관련 주제:
- 알고리즘 시간복잡도
- 데이터베이스 선택 가이드
- API 설계 가이드
- 기술 블로그 방문자·내부 링크 가이드 — 준비한 내용을 글로 남기며 검색 유입까지 보고 싶다면