# What Judges Actually Score: Notes From a Year of Hackathon Judging > Source: > Published: 2026-07-27 00:22:13+00:00 I judged three hackathons over about ten days this July: MLH x DigitalOcean "AI for Social Good" on July 11, the Sports World Cup Hackathon in San Francisco on July 17, and Aethera Hacks, an online event on Devpost, across July 19 to 21. I came in from the sports technology side, building athlete monetization tools, so I was usually the judge asking who pays for this rather than the judge asking what is your bundle size. That turned out to be a useful seat, because the questions that decide scores are mostly not technical ones. Here is the part builders rarely get told: a judge is scoring under a hard constraint. Some number of teams, a fixed window, and by the middle of the block the demos start blurring together. Judges are not evaluating your project against an ideal. They are ranking it against the six they just saw while trying to remember which one had the map. Everything below follows from that. Most events hand judges four or five categories with numbers next to them. Technical difficulty, originality, design, impact, something about use of a sponsor API. Those categories are real and I filled them in honestly. But they compress. Almost every team lands mid-range on most of them, and the spread that produces a winner comes from two or three things the rubric does not name directly. This sounds too obvious to write down. It is the single largest score differentiator I saw. A working demo, live, on the judge's screen or the team's laptop, beats a more ambitious project shown as slides almost every time. Not because judges are impressed by working software as such, but because a live demo removes doubt, and doubt is what a judge is actually managing under time pressure. The practical version: cut scope until something end-to-end runs. One complete path through the product beats four half-built paths. If your architecture diagram has six boxes and two of them work, demo the two and describe the rest in one sentence. The teams that scored well opened with a plain declarative: this is a tool that does X for Y. The teams that lost ground opened with context. Market size, a personal story, a problem statement that took forty seconds to arrive at the product. By the time the product appeared, I had spent a third of the slot without knowing what I was looking at, and I was reading the rest of the demo trying to catch up rather than trying to evaluate it. Judges are not hostile to your story. They cannot hold it in memory without an anchor. Give the anchor first, then the story fits somewhere. A team that built one narrow thing well reads as a team that made decisions. A team that built a platform in 36 hours reads as a team that did not. I scored the narrow projects higher consistently, and so did every other judge I compared notes with. Ambition is not the signal. Judgment under a constraint is the signal, because the constraint is the only thing the event actually tests. My questions were nearly always the same three, in some form. That last one is worth sitting with. Admitting a limitation raised scores in my sheets. It is counterintuitive if you think of a demo as a sales pitch. It makes sense if you think of a judge as someone trying to decide whether to trust you, which is closer to what is happening. Judges score partly on whether they can imagine explaining your project to someone else. That is the real memory test. When the panel reconvenes and someone says "which one was the scheduling one," the projects that survive that conversation are the ones with a one-line identity. Projects with three features and no center do not survive it, even when they are technically stronger than the winners. So the practical instruction is unromantic. Pick the sentence you want a judge to repeat to another judge an hour later. Build the demo that earns that sentence. Cut everything that does not. Five things, in the order I would do them. None of this is about being a better engineer. Most of the teams I judged were competent. The gap between the top table and the middle was almost entirely a gap in how the work was framed under time pressure, which is a skill the event tests whether or not it says so on the rubric. *I am the founder of Gameplan, a platform for professional athletes. I judged MLH x DigitalOcean "AI for Social Good" (July 11, 2026), the Sports World Cup Hackathon in San Francisco (July 17, 2026), and Aethera Hacks on Devpost (July 19 to 21, 2026). These are firsthand observations, not aggregate data, and no project, team or score details from any event are disclosed.*