Naver Coding Test Review

Yesterday morning, I took the Naver new hire technical position open recruitment coding test. Since it was a test I took after a long time, I once again realized my repetitive mistake patterns, which I could organize into two main categories.

1. Starting Implementation Immediately Upon Understanding the Problem

When I first encountered a problem, I immediately thought of pseudocode and went straight into implementation. However, the solution created this way was merely a partial solution that came out without fully understanding the problem to the end.

As a simple example, I’ll introduce my approach to “a problem of finding the coordinates of the remaining vertex through three vertices of a rectangle.”

Algorithm Problem - The Remaining Point | Programmers School (Korean)

Input/Output Examples

Problem Approach Process and Mistakes

1. I identified using the characteristics of connected points that “the same number appears only once.”
2. I thought in pseudocode that I could construct a hashmap to find numbers without pairs.
3. The result seemed correct right after implementation, but I soon realized the mistake of not distinguishing between x and y coordinates.
4. Only after checking the second test case did I understand that x and y axes should be handled separately.

Ultimately, it was a problem that could have been solved in half the time if I had analyzed the problem more calmly from the beginning.

2. Experiencing White-out in Test Situations

The coding test problems this time came in three categories: math/implementation/combination. Among these, I experienced the following white-outs:

• Math problem: I judged the difficulty in advance and didn’t even try to solve the problem, but when I looked later, it was actually a very simple reduced fraction problem.
• Implementation problem: I made a complex design of storing specific state transitions as an enum data type. However, upon re-examination, it was a problem that could be easily solved by calculating directly without such need.
• Combination problem: I panicked because the combination API provided by Python didn’t come to mind immediately. Although I could refer to documentation in Programmers’ test environment, I didn’t think to utilize it in a blank state.
  • Let’s remember Combinatoric iterators in Python’s itertools library.

Closing

Looking back, I had similar experiences to the mistake patterns introduced this time even in actual work. Because I thought of and implemented only partial solutions in design, situations arose where I had to go back and redesign.

Cases where redesign is possible are fortunate. Sometimes there were more situations where I missed reversibility¹ because I couldn’t change the design and had to live with the problem due to the limitations of the given business.

“Nothing is more dangerous than an idea, when you have only one idea.”
— Emile-Auguste Chartier, Propos sur la religion

I felt that I experienced this reversibility in a compressed way through the coding test where pass or fail is decided within a short time limit. To maintain my posture as a sustainable software engineer who can work steadily for a long time, I want to reduce mistakes in design going forward.