Released · improving
Coding interview strategy guide · 6/6
Knowing algorithms is not enough without a plan and an understanding of the test setting. This chapter covers a preparation plan, hiring processes in Korea and abroad, habits for the test itself, common mistakes and resources. Processes vary by company and change over time, so always read the posting and any instructions you receive.
A little practice every day, grouped by pattern, beats solving a large number of random problems.
| Week | Topics | Goal |
|---|---|---|
| 1 | Complexity, arrays and strings, hash maps | Use your main language's data structure APIs fluently |
| 2 | Two pointers, sliding windows, prefix sums | Solve contiguous-range problems in O(n) |
| 3 | Stacks and queues, sorting, binary search | Master "smallest value that satisfies a condition" |
| 4 | Trees, BFS and DFS | Traverse both recursively and iteratively |
| 5 | Graphs, shortest paths, topological sort | Turn grid problems into graph problems |
| 6 | Heaps, greedy, backtracking | Top-k and enumeration problems |
| 7 | Dynamic programming | Explain states and recurrences out loud |
| 8 | Mock interviews, reviewing mistakes | Solve under a timer while talking |
Many Korean companies hold an online coding test after, or alongside, the résumé screen. Candidates typically solve several problems over a few hours, and an automatic judge scores submissions against hidden test cases. The allowed languages, whether web search is permitted, partial credit, and proctoring or screen recording all vary by company. Candidates who pass may be asked in the technical interview to explain the code they submitted, or to solve a new problem with their screen shared.
Many companies abroad start with a recruiter call, move on to an online assessment or a video technical screen, and finish with a series of back-to-back interviews, often called an onsite or a virtual loop. Each round usually lasts 45 to 60 minutes, and you may write code in a shared editor that cannot run it. System design and behavioral interviews are commonly part of the loop as well.
On online tests with large inputs, Python's built-in input() can be slow. Learn to read all of standard input at once.
import sys
def main() -> None:
data = sys.stdin.buffer.read().split()
n = int(data[0])
nums = list(map(int, data[1:1 + n]))
print(sum(nums))
main()Python's default recursion limit is usually around 1000, so a deep DFS can fail. You can raise the limit, but an iterative DFS with an explicit stack is safer.
def count_reachable(graph: dict[int, list[int]], start: int) -> int:
seen = {start}
stack = [start]
while stack:
node = stack.pop()
for nxt in graph.get(node, []):
if nxt not in seen:
seen.add(nxt)
stack.append(nxt)
return len(seen)
print(count_reachable({1: [2, 3], 2: [4], 3: [], 4: [1]}, 1)) # 4When practicing, a stress test that compares a slow but certain solution with a fast one on random inputs finds bugs faster than anything else.
import random
def brute(nums: list[int], k: int) -> int:
return sum(1 for i in range(len(nums)) for j in range(i, len(nums)) if sum(nums[i:j + 1]) == k)
def fast(nums: list[int], k: int) -> int:
seen, prefix, count = {0: 1}, 0, 0
for x in nums:
prefix += x
count += seen.get(prefix - k, 0)
seen[prefix] = seen.get(prefix, 0) + 1
return count
for _ in range(2000):
nums = [random.randint(-3, 3) for _ in range(random.randint(0, 8))]
k = random.randint(-3, 3)
assert brute(nums, k) == fast(nums, k), (nums, k)
print("ok")Plan your preparation around patterns, keep in mind that test formats differ in Korea and abroad, and use safe habits such as fast I/O and iterative DFS in the test itself. While practicing, let stress tests find your bugs, and use mock interviews to get comfortable solving problems while talking.
Counter, defaultdict, deque
0 comments
Sign in · Sign in to leave a comment.
Be the first to comment.