A hackathon judging rubric organisers can copy

Walking a room through evaluation criteria
Walking a room through evaluation criteria

Originally published at https://pranjulrathour.scult.in/blog/hackathon-judging-criteria-rubric. That copy is the canonical version and gets updates first.

Most college hackathons hand judges a sheet that says "Innovation (10), Technical (10), Presentation (10)" and hope for the best. The result is scores that depend on which judge a team drew. A usable rubric has weights, descriptors and a calibration step. Here is the one I offer organisers when I am invited to judge.

The criteria and weights

  1. Problem and user (25%) — Is there a specific user with a specific pain? Did the team validate it, even by talking to five people?
  2. Working solution (30%) — Does the demo run live on real input? How much of the claimed functionality is real versus mocked?
  3. Engineering judgement (20%) — Were scope decisions deliberate? Are limitations stated honestly? Is the architecture appropriate rather than fashionable?
  4. Communication (15%) — Can the team explain the problem, the solution and the trade-offs in three minutes, and answer questions directly?
  5. Viability (10%) — Could this continue after the weekend? Is there a plausible next step?

Descriptors, so a 7 means the same thing to everyone

For each criterion write what a 2, a 5 and a 9 look like. For the demo: 2 is slides only; 5 is a demo on prepared input; 9 is a live demo on input the judge suggests. Descriptors turn opinions into observations and make feedback specific.

Presenting BrandHive
Presenting BrandHive

Calibrate the judges

  • Score the first two teams together and discuss differences before scoring the rest independently.
  • Agree what counts as "mocked" — a hard-coded response is a mock; a stubbed payment is fine.
  • Decide in advance how to treat teams that exceed time.

Publish it before the event

Teams build toward whatever they think is being scored. Publish the rubric with the problem statements and the quality of submissions rises across the board. It also removes the most common complaint after results — "we didn't know that mattered".

After the scores

Give every team two sentences of written feedback tied to a criterion. That is the part students keep. I wrote about doing it well in how judges should give feedback.

Presenting KrishGyan, farming advice in your voice and language
Presenting KrishGyan, farming advice in your voice and language

Organisers: take this rubric, adapt the weights to your theme, and if you want a judge who will use it and explain his scores to every team, write to pranjulrathour41@gmail.com.

From my carousels
Three First Prizes, One Loss
Three First Prizes, One Loss, slide 1Three First Prizes, One Loss, slide 2
Three First Prizes, One Loss, slide 3Three First Prizes, One Loss, slide 4
Full carousel on Instagram and LinkedIn.
Pranjul Rathour
Pranjul Rathour
GenAI engineer, Kanpur · 3x first-prize hackathon winner · campus mentor
I ship production RAG pipelines, fine-tune LLMs and build agentic AI products end to end. I lead engineering at SCULT INDIA for a 14-member team and have mentored 200+ students through TechVerse Enclave.
Open to: GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges.
On stage, at hackathons and on campus
Speaking at a MeetKats event
Speaking at a MeetKats event
At an Integral Startup Foundation hackathon
At an Integral Startup Foundation hackathon
In a packed college auditorium
In a packed college auditorium

Comments

Popular posts from this blog

Forming a hackathon team: roles, skills and the mistake most teams make

Hello from Kanpur: what I build, and what I'll write about here

I built 15 free tools, 1,211 prompts and a 50,000-skill library — here's what's inside tools.scult.in