Hackathons
Time-boxed builds — what the constraint was, what got built inside it, and what the deadline forced me to leave out. A hackathon is worth writing up for the trade-offs it exposes, not for the placing.
Related: Open Source for the projects with no deadline attached, and Projects for the research and industry work.
Events
Event nameplacing, if any
Month Year · Location or online · Organiser
The brief: what the organisers asked for, and any constraint that shaped it.
What we built: the thing itself, in two sentences.
My part: which pieces were mine, in a team of n.
The interesting trade-off: what got cut for the deadline, and whether that was the right call.
Links: repository · demo · devpost
Why this section exists
A hackathon project is a useful thing to talk about in an interview precisely because it is compromised. There was no time to do it properly, so every decision is a visible trade-off: what got faked, what got hardcoded, what would have to be rebuilt before anyone could use it. Those are better answers than a polished project gives, because the reasoning is still on the surface.
So the write-ups here lead with the constraint and the cut, not the demo. If a project won something, that goes in the corner as a badge — it is the least interesting fact about it.