The organisers have asked you to sit on the judging panel. You are flattered for about a minute. Then you look at the list of teams and see two principal engineers, a team lead, and a group from another department whose work you barely understand. Who are you to score them?
You are someone they chose for a reason. Maybe they wanted a view from a different part of the company, or someone closer to the users. Judging does not require you to be better than the people presenting. It requires you to look carefully and explain your reasoning.
Start by asking what the criteria are. Most hackathons judge on a few things, such as usefulness, how well it works, originality and the quality of the demo. If nobody has written them down, ask the organisers to before the day. Criteria protect you. When you score a principal engineer lower than a graduate, you are scoring against the same written questions, not against your feelings about either of them.
Read the list of entries in advance if you can, so the strange ones do not surprise you. Decide with the other judges how you will handle conflicts. If your own team or a close friend is presenting, say so and step back from that score.
During the demos, write down one specific thing per team as you go. After twelve presentations in an afternoon, memory blurs badly, and your notes will be the only fair record you have.
Ask one good question of each team. Not a trick question, but something that shows you listened. What would you need to make this real? Who would use it first? A thoughtful question from a judge is a gift to the presenters.
When the judges disagree, which you will, say what you saw and why it mattered to you. Then listen. You may change your mind, and that is fine. Holding your view when you have a reason is also fine.
Finally, give feedback to the teams that did not win. A sentence or two each on what stood out. That is often the most useful thing a judge does, and almost nobody does it.
– Asael Shinder
Top comments (0)