Employers do not care what you did at the weekend

Staying sharp is supposed to mean keeping up with trends and building things in your own time. Employers mostly don’t care.

They don’t care about your side projects, or what you do at weekends, or what you taught yourself last month. A good number of them don’t especially want you learning new things during working hours either which is a separate problem and a worse one. The belief is close to everywhere in this industry and it’s worth pulling apart why it survives because none of the four reasons is evidence.

The first is that the developers you see talking about this are often not describing their own situation. A lot of visible, widely followed developers work as advocates for a company and their job is building small showy projects and then talking about them. They rarely mention that the project was work. Their audience sees somebody producing an impressive thing that couldn’t possibly have been built in office hours, concludes it must have been evenings and weekends and extrapolates that becoming that kind of developer requires giving up your Sundays. The thing being modelled is a full time job with a different title.

The second is that people involved in hiring say they look at public repositories. They do look, when there’s something to look at. Having been hiring developers for fifteen years I still interview enormous numbers of people who have nothing public at all and honestly a public profile is more likely to move me towards ruling somebody out than towards arranging a conversation. Most public repositories are quick hacks nobody returned to, starter projects that stopped on day two, or things documented so thinly it’s impossible to work out what they even do.

The third reason is that we like building things and it’s useful to have a excuse. When a partner or children or parents would rather you did something else on a Sunday evening, being able to say your career will wither without it is a really effective argument. It’s also mostly untrue and the people making it are usually the ones who’d be doing the project anyway.

The fourth is the only one with real force behind it and a side project is a route out of a bad job. If you’re working with technology you dislike, at a company that won’t let you near anything else, then building something in your own time is how you get evidence that you can do the other thing. That’s a strategy and it works. It’s also an escape plan rather than a upkeep and those get mixed up constantly.

Notice what none of those four is. None of them is an employer wanting to see it. The belief circulates because of how the industry talks about itself, not because there’s a hiring manager somewhere weighing your weekends.

What this costs is worth being clear about. If you think an unpaid second shift is the price of staying employable, then anyone without spare evenings is going to conclude they’re falling behind. People with young children, people caring for a relative, people with a long commute, people who simply want a life outside this. None of them is falling behind and the belief that they are does real damage to people who are already tired.

Do the side projects if you enjoy them. Do them because building something you chose is one of the better feelings available in this work. Just don’t do them because you think somebody is checking because they aren’t and the ones who say they are mostly haven’t looked.

The version worth keeping is much smaller than the one people repeat and stay curious about the work you’re doing, and when you hit something you don’t understand, go and understand it. That’s it. It happens during the week, it’s part of the job rather than an addition to it, and no employer worth working for will object to you spending an afternoon on it.

The test is simple enough. Ask anyone who’s told you this whether they’ve ever actually turned down a candidate for having nothing public, or promoted somebody for a weekend project. Almost nobody has a real example and the ones who do are usually describing a hire where the project was directly relevant to the role rather than evidence of general keenness.