A 3-Month Plan for Coding Tests
From non-CS background to passing big tech coding tests -- the strategy that actually worked over three months.
I Couldn't Even Solve Silver-Level Problems
Three years ago, I hit a wall preparing for coding tests while trying to land a job at a major tech company. Non-CS major, never took a data structures class. Couldn't solve even Silver-level problems on Baekjoon (Korea's LeetCode equivalent). Programmers Level 2 problems often left me unable to even understand the question.
I gave myself three months of systematic prep and passed the coding tests at three of Korea's top tech companies. Failed one. It wasn't genius-level ability -- it was repetition and pattern recognition.
Month 1: Just the Basics
Arrays, strings, hash maps, stacks, queues. Master just these five and you can solve about 40% of coding test problems. I solved 2 Programmers Level 1 problems per day. At first, each took 2 hours.
Read the problem, stare blankly, check hints, still don't get it, look at the solution, spiral into self-doubt -- rinse and repeat. But after a month, I could finish them in 30 minutes.
(At one point I failed two days in a row and thought "I just don't have the talent." Took a week off. That week stings.)
The key: if you can't solve it, struggle for 30 minutes max and then look at the solution. Anything past an hour tanks efficiency. Read the solution, understand it, then try solving it again from scratch the next day. Much more effective.
Month 2: Memorize the Patterns
BFS/DFS, binary search, two pointers, greedy, DP. These five cover 80% of coding tests. I picked 5 representative problems per category -- 25 problems total. Went through them twice, so 50. First pass with solutions for reference, second pass without looking.
After solving 5 problems of the same type, the 6th triggers "ah, this is BFS" instinctively. Coding tests aren't about mathematical genius -- they're about pattern recognition. And pattern recognition is trainable through repetition. Good news for non-CS backgrounds.
DP was the hardest. Honestly, still is. But most DP on coding tests is variations of the basics. Learn the variations of Fibonacci, knapsack, and LCS, and you can handle most of them.
Month 3: Timed Practice
I solved Programmers Level 2-3 problems with a 60-minute limit. Whether I solved them or not, I checked the solution after 60 minutes. Weekends: 3-hour mock exams with past problems.
The most important thing here is time management. Given 3 problems, solve the easy ones fast and save time for the hard ones. I made the mistake of diving into hard problems first and burning through my time -- three separate times.
Use the Language You Already Know
I tested in JavaScript. Python is supposedly better for coding tests, but using the language you work with daily means fewer mistakes. Learning a new language while studying algorithms doubles the burden.
If you go with JS, master Map, Set, and array methods completely. [1, 2, 10].sort() returning [1, 10, 2] was a genuine shock. You'll get burned by that Unicode string sort default at least once.
Check Time Complexity First
From Programmers Level 2 onward, brute force will time out. Build the habit of checking input size immediately. If n is 100,000+, O(n^2) won't cut it. If n is 1,000,000+, you need O(n log n) at most.
Edge cases matter too. Empty arrays, single elements, all identical values. These basic cases cause runtime errors that land you at 73 points more often than you'd think.
Three Months Is Long
Solving algorithm problems every day for three months is grueling. I wanted to quit twice. Each time, I told myself: "This is a three-month project. Not a permanent lifestyle change." The day you feel perfectly prepared never comes. Taking the test at 60% readiness and filling in the gaps afterward is the realistic approach.
Whether coding tests are the right way to evaluate developers -- honestly, I'm not sure. But as long as most companies require them, there's no reason not to prepare. One hour a day, 90 days.