In my capacity as a senior employee at Alert Labs (it’s easy to be senior when the company is only three years old), I do a lot of hiring. Since I started, I’ve been involved in interviews for four full time hires and five interns. Throughout all of this, I’ve learned a lot about what to look for in a resume.
I’ve also gotten in the occasional disagreement about what we should look for in in people we’re (potentially) hiring.
When looking through resumes for software engineers, it’s accepted practice to look for independent programming projects. These are things that people do in their spare time, normally to learn new languages or make things that they find cool. I’ve done a few myself. If you look at my projects, you’ll see one where I create a tool for my favourite pen and paper roll playing game, one where I work through math problems, and one where I’m trying to better understand the concept of randomness.
There’s a curious double vision in the profession about programming projects. We all tell ourselves people do them only for fun. Yet we also look for them on resumes.
The second fact means that the first cannot always be true. My projects partially exist for my resume. I’ve enjoyed working on them. But if there wasn’t a strong financial motive to have worked on them, I probably wouldn’t have. Or I’d have done them differently.
As a someone who hires, I can’t claim that programming projects aren’t useful. They give, perhaps better than anything else (e.g. the much-derided whiteboard interview), an idea of what sort of code someone would write as an employee. I’ve called people – especially people without any formal education in CS – in for interviews largely on the strengths of their personal projects. Seeing that someone can use the languages that they say they can, that they can write unit tests and documentation, and that they can lay out a large project makes me have more faith that they can do the job.
When programming projects are used as a complement to employment and educational history, I think they help the field.
But I’ve also argued stringently against treating personal projects as a key part of any hiring process. While I like using them as a supplement, I think there are four good reasons not to rely on them as any sort of primary criteria.
First, not everyone has time for projects. Using them as a screen sifts out people with caregiving responsibilities, with families, or with strong commitments in their personal life. When you’re only hiring from people without other commitments, it becomes easier for a team to slip into a workaholic lifestyle. This is bad, because despite what many people think, studies consistently show no productivity benefits from working more than 40 hours per week for prolonged periods. All long hours do is deprive people of personal time.
(In a world where people with caregiving responsibilities are more likely to be female, overreliance on personal projects can also become a subtle form of hiring discrimination.)
I’m incredibly grateful that I work at a company founded by people with both management experience and children. Their management experience means they know better than to let their employees burn out from overwork, while their children mean that the company has always had a culture of taking time for other commitments. This doesn’t mean that I’m never in for sixty hours in a week, or that I never have to deal with a server failure at midnight. Work-life balance doesn’t mean that I don’t take my work seriously; it just means I don’t conflate being in the office for 12 hours at a time with that seriousness.
Second, requiring people to have programming hobbies sifts out a lot of interesting people. I understand that there exist people that only want to live code, only want to talk about code, and want to be surrounded by people who are also in that mode, but that isn’t me. I joined Alert Labs because I wanted to solve real-life problems, not make tools for people just like me. Having a well-rounded team means that people spontaneously generate ideas for new projects. It means they take ownership for features (like ensuring everything on our website follows accessibility guidelines) that would never percolate to the top of my mind. It makes our team stronger and more effective.
Outside of a few other oddball professions (lawyers, I’m looking at you), no one else is expected to treat their work as their hobby. People can make their hobbies into their work (look at webcomic artists or bloggers who make it big) and this was one of the initial purposes of personal programming projects. It’s not at all unusual to find something you like enough that you’d make a full-time job of it if you could. But then you normally get new hobbies.
People who fall in love with programming are lucky in that they often can turn it into a full-time job. Writers… are somewhat less lucky. I haven’t monetized my blog because I’d find the near-impossibility of making money off of discursive posts about political economy disheartening. Keeping my blog as a vanity project keeps it fun.
But we programmers shouldn’t let our economic fortune turn what has always been the path that a minority of people take into our field into a bona fide requirement.
Third, I dislike what an overemphasis on programming projects can do to resumes. I frequently see interesting hobbies shunted aside to make room for less-than-inspired programming projects. I’ve seen people who got the memo that they needed a profile full of projects, but not the memo that it had to be their projects. This leads to GitHub pages full of forks of well-known projects. I don’t know who this is supposed to fool, but it sure doesn’t work on me.
When students send in resumes, they all put the same four class projects on them, in the somewhat futile hope that we won’t notice and we’ll consider them adequately dedicated. I wish the fact that they were paying $8500 per term to learn about CS could be taken as proof enough of their dedication and I wouldn’t have to read about pong sixty times a semester, but that is apparently not the world I live in.
My final beef with an overemphasis on programming hobbies is that many important skills can’t be learned in front of a computer. Not all hobbies teach you how to work together with a disparate team, respectfully navigate disagreements with other people, and effectively address co-worker concerns, but those that do are worth their weight in gold. Software is becoming ever more complex and is having ever more capital thrown at it. We’ve exhausted what we can do with single brilliant loners, which means that we now need to turn to functional teams.
This isn’t meant to conjure up negative and insulting stereotypes about people who spend all their spare time programming. Many of these people are incredibly kind and very devoted to mentoring new members of our community.
I don’t want people who program in their spare time and love it with all their hearts to be tarred with negative stereotypes. But I also don’t want people with other interests to be considered uncommitted dilettantes. And I hope we can build a profession that believes neither myth.