From Competitive Programming to Research

Before I started doing research, competitive programming was the main way I trained myself to think about algorithms, systems, and implementation. My experience in NOIP, ICPC/CCPC, and Codeforces shaped how I approach technical problems today.

Competitive programming and research look very different on the surface. In programming contests, the problem is clearly stated, the input and output formats are fixed, and the judge gives immediate feedback. In research, the problem is often ambiguous, the evaluation protocol may evolve, and there may not be a single correct answer. However, I have found that the core skills transfer naturally.

Abstraction

Competitive programming trains the ability to quickly identify the structure behind a problem. A statement may involve stories, constraints, and corner cases, but the key is to discover the underlying abstraction: graph connectivity, dynamic programming states, data structures, geometry, or optimization.

Research requires a similar habit. When reading a paper or designing a method, I try to ask: what is the essential problem being solved? What assumptions are being made? Which part is algorithmic, which part is empirical, and which part is engineering? This way of thinking helps me avoid being distracted by implementation details too early.

Debugging

Contest code often fails because of small but critical issues: an off-by-one error, a missing edge case, a wrong invariant, or an inefficient data structure. Debugging under time pressure taught me to form hypotheses, test them quickly, and isolate the smallest failing component.

This is equally important in research. Experiments can fail for many reasons: data preprocessing, evaluation scripts, training instability, implementation bugs, or simply an incorrect hypothesis. A competitive programming background helps me stay systematic when results do not match expectations.

Efficiency

In contests, efficiency is not optional. A correct algorithm that is too slow is still wrong. This mindset naturally connects to my current interest in high-efficiency large language models and efficient 3D representations.

I am especially interested in methods that are not only accurate, but also computationally practical. Whether the topic is trustworthy LLMs, vision-language models, or 3D Gaussian Splatting, I care about how an idea can be implemented, scaled, and evaluated efficiently.

Persistence

Competitive programming also teaches persistence. Many problems are not solved in the first attempt. Sometimes the solution appears only after trying several failed directions, simplifying the problem, or revisiting it with a different perspective.

Research feels similar. Progress is often non-linear. Negative results, failed experiments, and rejected hypotheses are part of the process. What matters is to keep refining the question and learning from each iteration.

Looking Forward

I do not view competitive programming and research as separate experiences. Competitive programming gave me a foundation in abstraction, implementation, debugging, and efficiency. Research gives me the opportunity to apply these skills to open-ended problems with broader impact.

As I continue exploring trustworthy and high-efficiency LLMs, as well as 3D Gaussian Splatting, I hope to keep the same contest-trained mindset: understand the core problem, build simple and reliable solutions, test carefully, and iterate persistently.