"정렬된 배열에서 값을 찾는 거잖아." 이분 탐색을 이렇게만 알고 있으면 코딩테스트에서 이분 탐색 문제를 절대 못 알아본다.
코테에서 가장 무서운 순간이 있다. 문제를 읽자마자 "아, 이거 그리디네" 하고 자신 있게 코드를 짰는데, 제출하면 40-60% 어딘가에서 WA가 뜨는 순간.
코테에서 "다음으로 큰 원소(Next Greater Element)"를 묻는 문제를 만나면 대부분 이중 for문을 먼저 떠올린다. O(n²)이 나오고, 시간 초과가 뜨고, 그제서야 "뭔가 다른 방법이 있나?
DP 문제를 풀다 보면 가끔 "방문한 노드의 조합"이나 "선택한 원소의 집합"을 상태로 들고 다녀야 하는 순간이 온다. 배열로는 표현이 안 되고, set을 넣자니 해싱이 복잡하고.
코테 스터디에서 위상 정렬을 가르치면 구현 자체는 금방 따라온다. BFS에 진입 차수 배열 하나 붙이면 끝이니까.
Union-Find 구현해본 적은 있다. parent 배열 만들고, find 재귀 돌리고, union 호출하고.
프로그래머스에서 "상위 K개 요소"류 문제를 만났을 때, 가장 먼저 떠오르는 건 정렬이다. 리스트에 값 넣고, sort() 한 번 돌리고, 뒤에서 K번째 꺼내면 끝.
"투 포인터 패턴으로 풀었습니다" — 면접에서 이렇게 말했더니 면접관이 "그거 슬라이딩 윈도우 아닌가요?"라고 되물었다는 후기를 본 적 있다.
지난 주 스터디에서 한 문제를 같이 풀었다. "배열을 K개의 구간으로 나눌 때, 구간 합의 최댓값을 최소화하라.
N-Queen 한 번 풀어보고 "아 백트래킹 알겠다" 싶었던 적 있을 거다. 근데 코테에서 조합 생성이나 조건부 탐색 문제를 만나면 손이 멈춘다.
DP 문제를 마주치면 대부분 점화식부터 세우려고 한다. 근데 dp[i]가 정확히 무엇을 저장하는지 한 문장으로 설명 못 하면, 점화식은 절대 나오지 않는다.
올해 상반기 채용 시즌에 독특한 공고가 돌기 시작했다. "코딩 인터뷰 중 AI 도구(Copilot, ChatGPT 등) 사용을 허용합니다.
"각 원소의 오른쪽에서 자기보다 큰 첫 번째 수를 구하라." 이 문제를 처음 보면 대부분 이중 for문을 떠올린다.
"최단경로" 하면 BFS부터 떠올리는 사람이 많다. 맞는 말이다 — 간선 가중치가 전부 1일 때까지는.
카카오 2026 상반기 코테에서 문자열 문제가 등장했다는 후기가 올라오고 있다. 문자열 문제를 만났을 때 가장 흔한 실수 — 접두사 매칭이 필요한 상황에서 해시맵이나 정렬+이분탐색으로 억지로 풀려다가 시간 초과를 맞는 것이다.
그래프 문제가 나왔는데 BFS도 DFS도 아닌 것 같고, 인접 리스트 만들기도 뭔가 과한 느낌이 들 때가 있다.
문제를 읽다가 "1 ≤ N ≤ 20"이 눈에 들어왔다면, 그 순간 머릿속에서 알람이 울려야 한다. 대부분의 코테 준비생은 이 조건을 보고도 완전탐색이나 백트래킹부터 떠올린다.
코테 문제를 읽고 "이거 이중 for문이면 되겠는데?" 하고 짰다가 시간초과를 맞는 경험, 한 번쯤 있을 거다.