Hackathon judge feedback: how to write a useful project comment
How hackathon judges can give clear feedback: connect observations to criteria, separate scoring reasons from advice and suggest a testable next step.
·4 min read·
“An interesting idea that needs more work” sounds friendly, but the team does not know what to do. A useful comment says what the judge saw, how it relates to a criterion and what evidence was missing. It can give the team a next step even after a disappointing presentation.
Allow time for feedback in the judging plan. If you leave it until the results announcement, comments will be short and inconsistent. Organizers should define the format, minimum content and method of sharing it with teams in advance.
Start with an observation the team can check
Describe a specific part of the demo, materials or answer. “The demo did not show how a user corrects an invalid entry” is more precise than “a poorly designed interface.” The first lets the team reproduce the problem. The second leaves them guessing what you meant.
Do not attribute intentions to the authors. A judge can see that a check is missing without knowing why the team skipped it. “The materials do not include a result for this test” is more accurate than assuming participants were lazy or careless.
If the information is incomplete, state the limits of your conclusion. For example, the scenario shown does not let you assess another data format. This does not prove that support is absent; it explains what the judges could not verify.
Connect the comment to a published criterion
The team needs to understand why the observation affects the score. If the criterion concerns whether the project works, explain which step you could not complete. If it concerns the evidence behind the problem, name the missing source or observation.
Do not add requirements after submission. A judge can suggest a commercial direction for a learning project, but should not reduce its score for having no sales if sales were not part of the criteria. The guide to hackathon judging criteria covers preparation of the scoring scale.
The MLH judging plan guide includes a judge briefing before project review. For your event, add a discussion of sample comments so judges can agree on a clear level of detail.
The scoring reason explains the decision in the current round. Advice suggests possible work after it. The two are related but serve different purposes: a useful suggestion from a judge does not become a mandatory product requirement.
Illustrative scoring reason: “The demo flow ended at the loading screen, so we could not confirm that the result was processed.” Possible next step: “Record a separate run with an input file and the final result, then check that it works again on a second run.”
If you have several suggestions, highlight the one most useful for the next test. A list of ten new features can look substantial while leading the team away from its main obstacle. The judge helps choose a direction; the authors decide whether to continue.
Describe strengths just as precisely
Praise helps when it shows what to keep. For example, the team explained where the test data came from and demonstrated an error case. This is a clear achievement they can repeat in the next project.
Do not mechanically add praise before every criticism. If the main finding is a lack of evidence, state it calmly and respectfully. An artificial sequence of praise, criticism and praise often makes the scoring reason less visible.
Comment on the work rather than participants’ personal qualities. “The connection between the challenge and the scenario is clear” helps more than “you are talented.” Feedback should not turn one short presentation into a judgment of a person.
Prepare a short feedback card
A practical template can have four fields:
Observation: what was shown or missing.
Criterion: which part of the assessment the observation relates to.
Reason: why the evidence is sufficient or insufficient for the selected score level.
Next test: what action would provide the missing evidence.
Test the card on a fictional project before the event. If judges fill the fields with the same general phrases, simplify the form and show a more specific example. A longer comment does not guarantee more useful feedback.
Share feedback without losing its context
State which project version and round the comment concerns. If the team showed an improvement in the final, a preliminary-round comment may no longer describe the current state. Do not combine those records into one unnamed list.
The organizer checks tone, clarity and the absence of confidential information while preserving the meaning of the assessment. If a comment contradicts the score, ask the judge to clarify the reason before sending it. Encourage the team to use the observations in its retrospective and when planning a pilot.
