Let's be honest here. What are you getting out of GitHub? My experience has found exactly two cases:
1) It's a toy. There are like two files and and ~100 lines in total. In which case, the repo is meaningless.
2) There's a fuckton of code. In which case, you are absolutely not reading it. You can't. You have no context, nor do you have the time. Reading code is Hard. You absolutely are not going to spend several hours inspecting some rando's code. So what's the point?
You can get the same amount of information from reading the resume and a 30 minute phone screen.
> 1) It's a toy. There are like two files and and ~100 lines in total. In which case, the repo is meaningless.
I don't see it that way at all. Short programs can be very meaningful. For example, I wrote a python program that generates Verilog code for a rational rate resampler that is under 100 lines. That would be very useful to discuss in an interview.
> 2) There's a fuckton of code. In which case, you are absolutely not reading it. You can't. You have no context, nor do you have the time. Reading code is Hard. You absolutely are not going to spend several hours inspecting some rando's code. So what's the point?
I absolutely read the code. I'm not digesting every line, but I take a look at the general structure and try to get a feel for it. If I can clone it and get it to run easily, even better. I can do this because I'm an expert in my field, and we only interview people with relevant experience and skills.
> You can get the same amount of information from reading the resume and a 30 minute phone screen.
Not for me. I've had people BS their resume and the phone screen and then fail miserably in the in-person interview. I've yet to have someone who had a strong github resume not ace the in-person interview too.
You do the same thing as when checking out any tool/library/whatever: Skim the README, then if still interested jump into a file or two and look at what the code is like. It’s pretty likely - if this person works in the same domain, usually the case - you (as an experienced dev) will be able to guess what files are worth looking at and quickly get at least some minimal understanding of what is being done.
And remember, this is just to decide whether to invite someone for an interview. Looking at the repo is just to get some extra signal.
So at best zero signal compared to a coding screen, but even less if it’s in a language youre unfamiliar with. So you can’t judge quality at all. Just, “Yup! There’s code!”
Also, there’s no point to look at the code in a library you’re using, because you’re not maintaining it. When was the last time you popped open some random file in Kafka? I bet never.
Do you not find that 95% of the time it's just a blank GitHub though? The only people I've seen without that are either in academia or work on OSS in their day job in some way.
My area is tightly coupled to a few OSS projects, so we tend to attract people that are active contributors. I've never been let down in the in-person interview by someone with a strong github resume.
Same thing with GitHub activity grid. I don’t even know what it’s supposed to tell. Even if I’m writing code everyday, that doesn’t mean I’m checking it in, and even if I was, I’m not doing it on a public repo or even on a GitHub hosted repo.
I look at those but they don’t tell me much as people are often working on a template and have had help, so I can’t disentangle what is someone’s work as easily
1) It's a toy. There are like two files and and ~100 lines in total. In which case, the repo is meaningless.
2) There's a fuckton of code. In which case, you are absolutely not reading it. You can't. You have no context, nor do you have the time. Reading code is Hard. You absolutely are not going to spend several hours inspecting some rando's code. So what's the point?
You can get the same amount of information from reading the resume and a 30 minute phone screen.