There’s been much talk recently about the criteria we should use when hiring new people onto a technical team. Over recent years, I’ve seen that people are using Github commits (the number of times you contribute to open source software projects) and other measures to vet people as to how good, committed, involved, and generally important people are.
This week, there’ve been a few posts about the idea that by including stats about what people do in their spare time in the hiring process, we run the risk of severely weighting our teams towards people who have lots of spare time.
That could mean losing out on talented people and biasing hiring decisions towards young people, non-parents, people who don’t have to have two jobs to make ends meet, people who don’t have to travel long distances to get to their place of work because of property prices, people who don’t have elderly or disabled relatives to care for and so on.
I wouldn’t want to consider these measures in hiring decisions at Makeshift, and I’ll be continuing to push that idea next time we’re interviewing (which is pretty much all the time).
But there’s another thing that people sometimes ask in software interviews:“Have you been to any hackathons?”
It’s a question that on the surface seems sane enough, but it got me thinking…
Are hackathons for the privileged?
I spent recent years researching hacker culture and cultural hacking, and I’ve attended (and won!) my fair share of hackdays and hackathons. I love them. It’s a chance to move fast and break things, to learn by making, to explore ideas with new people and to demonstrate what technology can do in an area that is in need of some fresh thinking.
Yet it tends to be a young man’s sport in the main. Young Rewired State do a good job at balancing things gender-wise for younger hackers, but those of us with kids find it harder and harder to attend weekend events with no clear outcome and the very real costs of childcare and time away from home to consider.
It occurred to me today that if we’re giving Github commits (those units of open source contribution) a hard time as hiring criteria, we should probably apply the same thinking to the idea that attendance at 24-36hr hackathons and hackdays will make you more employable.
I’ve written at length about the idea of sustainable work in a startup. I have a rule of leaving by example — making it clear to my team they really aren’t expected to kill themselves working long hours. I was speaking to ntlk the other day, who’s one of the best software people I’ve ever worked with, and they said “If I have weeks where I work more than eight hours a day, I find those extra hours just don’t seem to help” (Or similar words to that effect).
Hacking into the small hours
Hackathons encourage the opposite, in my experience. People working long hours into the night to make something, sacrificing sleep, health and whatever they have planned the following week.
It’s the dark side of hack culture and it often seeps into the modes of Monday- Friday working too. Hackathons seem to double-down on reinforcing an already entrenched idea of “long hours = maximum potential success for your startup”, which depresses me to no end.
“Hackathons are a great way to learn, but not about working sustainably”
In one company I founded I remember a week where I’d been working, or attempting to work, every single waking hour of the week and clocked about 120 hours of productive time. No joke. Sadly it wasn’t isolated, just the peak of a wave of work.
That’s insanity. You don’t get anywhere screwing yourself and your team over by working long hours into the night — you write bad code and end up cleaning up your mess anyway. Nobody wants you to do it, and it’s only some odd idea about work heroism that makes you think that you should have this behaviour. When I see it happening on any team I’m working on I stamp on it.
Bad hacker. No.
But the “FTW” hacker culture pervades all of software. The 120-hour hacking week, to many would probably seem like some kind of holy grail of personal productivity. If you’re not making something, you’re wasting time. 8 hours a day? That’s for those corporate losers! We’re the start-uppers! We’re going to win by pulling longer hours! Oh hang on…
No. On a good team, you want smart, committed people who work hard, are diligent, work well with others, care about their work, about quality, about people and know where their limits lie. And they probably, just like ntlk, have realised that after about eight hours of looking at a screen and attempting to solve a hard problem, that they’re probably done for the day and it’s time to go and do whatever else they do in their lives.
“If hackathons are a factor in hiring we’re filtering out people who don’t have spare time”
And that’s where privilege comes in. Because if we have teams of people that realise that, not only is the long-hours hacker culture generally a bad idea for teams, there might suddenly be a lightbulb moment where people hiring for those teams might realise: hackathons are a great way to learn, but not about working sustainably. If we hire based on hackathon attendance we’re filtering out a lot of talented people who don’t have the luxury of attending. We should look for people who are skilled and committed for eight hours a day.
Then perhaps we’d open up a wider pool of potential hires. And that would have a pretty big effect, because then we’d be hiring people based on their software or technology abilities, and not on how much spare time they have.
Editor’s note: This story originally appeared here.