Do they have work/life balance? Investigating potential employers with GitHub
Tags: career
Published: 2019-02-05 14:09:15

---
title: Do they have work/life balance? Investigating potential employers with GitHub
published: true
tags: career
canonical_url: https://codewithoutrules.com/2019/01/31/does-company-have-worklife-balance/
---

When you're searching for a new programming job you want to avoid companies with long work hours. You can ask about work/life balance during the interview (and unless you're desperate, you always should ask), but that means wasting time applying and interviewing at companies where you don't want to work.

**What you really want is to only apply to companies that actually allow—or even better, encourage—good work/life balance.**

Close reading of the job posting and company hiring pages can sometimes help you do that, but some good companies don't talk about it, and some bad companies will just lie.

**So in this article I'll explain how you can use GitHub to *empirically* filter out at least some companies with bad work-life balance.**

<!-- TEASER_END -->

## Let's look at GitHub profiles

If you go to the profile for a GitHub user ([here's mine](https://github.com/itamarst)) you will see a chart showing contributions over time. The columns are weeks, and each row is a day of the week.

Each square shows contribution on a particular day: the darker the color, the more contributions.

![](https://codewithoutrules.com/assets/github-profile/itamarst.png)

**What's most interesting here are the first and last rows, which are Sundays and Saturdays respectively.** As you can see in the image above, this GitHub user doesn't tend to code much on the weekends: the weekend boxes are mostly blank.

You can also use this UI to see if the company uses GitHub at all. Given this many boxes, the user's employer probably does use GitHub, but you can also click on a particular box and see the specific contributions. In this case, you would see that on one particular weekday the user contributed to "private repositories", presumably those for their employer:

![](https://codewithoutrules.com/assets/github-profile/itamarst-clicked.png)

On the other hand, if you were to click on the weekend boxes you would see that all the weekend contributions are to open source projects. In short, this user doesn't code much on the weekend, and when they do it's on personal open source projects, not work projects.

**Generalizing this process will allow you to filter out companies that don't have work/life balance for developers.**

## Investigating work/life balance using GitHub

There are two assumptions here:

* This is a relatively small company; large companies tend to vary more across groups, so you'll need to adjust the process somewhat to focus on programmers in the group you're applying to.
* The company uses GitHub for most of their source code.

Company size you can figure out from the company page or LinkedIn, usage of GitHub will be something we can figure out along the way.

This is not a perfect process, since users can disable showing private repository contributions, or it's possible the developer has personal private repositories. This is why you want to check as many profiles as possible.

Here's what you should do:

1. **Find a number of programmers who work for the company.**
   You can do this via the company's website, and by the company's page on LinkedIn, which will list employees who have LinkedIn profiles.
   You can also check for members of the company's GitHub organization, if they have a public list, but don't rely on this exclusively since it will likely omit many employees.
2. **For each programmer, use your favorite search engine and search for "$NAME github" to find their GitHub profile.**
   Try to do some sanity checks to make sure it's the right person, especially if they have a common name: location, organization membership, technologies used, etc..
3. **For each programmer, check if they contribute to private repositories during the week.**
   You do can this by visually seeing if there are lots of green boxes, and by clicking on the Monday-Friday boxes in the timeline and reading the results below.
   If they mostly don't, the company might not use GitHub.
4. **If they do use GitHub at work, for each programmer, check if they code on the weekend.**
   You can visually see if they have lots of green boxes on Sundays and Saturdays.
5. **If they do code on the weekend, check if those are work contributions.**
    You can do this by clicking on the weekend boxes and seeing if those are contributions to private repositories.

Additional tips:

* If the company mostly writes open source code, you can check if the programmers contribute to the relevant open source repositories during the weekend.
* Look for correlated weekend work dates across different people: if 5 people are working on private repos on the same 4 weekends, that's probably a sign of crunch time.

**By the end of the process you will often have a decent sense if most of the programmers are coding on the weekend.** Note that this method can only tell you if they **don't** have work/life balance—you still can't know if they **do** have work/life balance.

So even if you decide to apply to a company that passed this filter, you will still need to [ask questions about work/life balance](https://codewithoutrules.com/2016/10/14/job-you-dont-hate/) and listen closely during the interview process.

## Always do your research

Before you apply for a job you should always do your research: read their website, reads all their job postings, talk to a friend there if you have one... and as I explained in this article, their GitHub profiles as well. You'll still need to look for warning signs during interviews, but research is still worth it.

The more you research, the more you'll know whether you want to work there. And if you do want to work there, the more you know there better your interview will go.

* * *

### We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

### Every painful failure taught me a lesson—but only after it was too late.

### You can do better! Join 3600 other programmers, and every week you’ll learn how to [avoid another of my mistakes](https://codewithoutrules.com/softwareclown/?ref=dev.to).