DragonByte 2026, and what the winner thinks coding challenges are still for

We run DragonByte because we want to meet people who think well under pressure, and a resume does not show that.

This year 1,300 people signed up. The twenty who made it to the onsite final in Bratislava came from eight countries: Germany, Ukraine, Poland, the Netherlands, Switzerland, Hungary, Denmark, and Austria. Among them were some of the strongest competitive programmers in the world.

The final was 3.5 hours, no internet, one problem set. The problems were built to be hard even for people at this level. Instead of recognizing a familiar pattern, contestants had to explore, test ideas, change direction, and keep looking for a better approach. Misof, who led the team behind the problems, watched the standings come in and said:

The podium:

• 1. radewoosh, €10,000
• 2. petr, €5,000
• 3. peti1234, €2,500

radewoosh, whose real name is Mateusz Radecki, won. He has spent over a decade in competitive programming, from the Polish high school olympiads to the ICPC World Finals. After the contest, he told us the problems forced him out of his usual playbook: “The problems were kind of unusual. You had to attack them differently, think outside the box.” petr put it more plainly: “The challenge was much harder than I expected.”

Errichto, who has seen a lot of these contests, gave us a comparison we did not expect:

That comparison is the reason we build this. But it also raises the obvious question, the one every engineer is quietly asking.

If AI can win, what is the point?

We put it to Mateusz bluntly: if a complete beginner with no coding experience used the best AI tools available today, would they beat him?

He did not hedge. In the majority of competitions today, he said, AI would win, and the few problems where humans still hold an edge are exactly the ones that stay brutally hard for humans too. Coming from someone who has spent ten years at the top of the sport, that is not defeatism. It is clarity.

So why keep competing, and why do people fly across Europe to spend a weekend doing it by hand? His answer is the part worth sitting with. The people who finish at the top of a scoreboard, he said, are almost never there for the money or the bragging rights. They got good because they love the work itself. That is also why cheating is rare at the very top: someone with a real passion for hard problems has no reason to fake it. For our qualifiers we required screen recordings, which he singled out as a clean way to keep the field honest.

petr sees it the same way, and it is worth quoting him in full:

That is the thing AI does not touch. The contest was never only about producing a correct output. It was about who you become by chasing hard problems, and who you meet doing it.

Talent is real, but it is not the story

We asked Mateusz the question every ambitious engineer wants answered: is this about talent, or about practice?

He has a strong view. “Most people underestimate how good they would get if they practiced more. I’m almost certain about it.” He allows that some talent is probably involved, but he thinks it matters far less than people assume. The real bottleneck is not raw ability, it is finding the time and the passion to keep going. In his own case he is unambiguous about what carried him: a lot of practice, and genuinely loving the thing.

That is a more demanding idea than “some people are just gifted,” because it puts the result back in your hands.

What actually transfers to real work

This is the question we cared about most, because it is the bridge between a coding contest and the engineering we do every day. How much of competitive programming carries over to a real job, and how much is just sport?

Some people, Mateusz said, insist it is completely disconnected from real work. He disagrees, and his reason is precise. What competitive programming really builds is a deep, low-level understanding of what a computer can actually do, and that transfers almost everywhere.

He pointed to our own Finals as the example. The problems were unusual and hard enough that you could not just write the obvious solution, you had to attack them, generate outputs on your own machine, think about using more cores, find a way around the front door. That instinct, knowing what is possible at a low level and reaching for it under pressure, shows up in most real engineering, including his own job at a robotics startup.

That is the overlap we look for. DragonByte is not an HFT simulation, and it is not the Wincent interview. But the reflexes it rewards, breaking an unfamiliar problem down, understanding the machine underneath it, and making the right call while the clock runs, are the same ones that matter when you build trading systems where small technical decisions carry real weight.

The weekend around it

The final was one part of DragonByte. The rest of the weekend was the opposite of 3.5 silent hours: dinner together, a late night, a city hunt through Bratislava. People who normally know each other only as a handle on a leaderboard had a weekend to sit across from one another and actually talk. Competitive programming is usually solitary, hours alone with a problem, and bringing the finalists into one room gave it a different side.

Finalists rated the weekend 9.5 out of 10. For us that matters as much as the scoreboard. The problems should be hard and the competition should feel serious, but the weekend should also be somewhere people want to come back to.

Thanks to everyone who competed, and to the team who built the problems and ran the final. The full standings and the 2026 problems are in the archive, if you want to try them yourself.

See you at DragonByte 2027.