/Ask HN: What do recruiters look for in a GitHub profile?

Ask HN: What do recruiters look for in a GitHub profile?

As a hiring manager, I glance at it and take a brief look at anything interesting. It’s good for talking points at the interview, perhaps to ask the candidate to expand upon and explain the work.

If the profile is empty, I close the tab and find something else to talk about. I will never, ever penalise a candidate for an empty GitHub profile. So many people just do not have time for open source and that’s totally fine.

GitHub activity helps lubricate conversation at interviews, but it should never be taken as anything other than a superficial representation of the candidate’s ability or experience.

+1 for this. I used to be a recruiter, and knew hiring managers looked at GitHub profiles. When I started, I used to to stress out over pushing crappy code to my GitHub account. At some point I realized that anyone judging me for stuff I put into GitHub was simply not someone I would ever want to please. My GitHub is mostly a graveyard for experiments, learning, and goofing off, and that is exactly what I want it to be 🙂

If you have something really notable in your GitHub account, maybe it should probably be on your CV/resume, too!

I look for things to chat about. That’s it. If there aren’t any then I’ll find other things to chat about.

It’s almost like a dating profile. You use the items as jump-off points to start a conversation and get to know the other person better.

I am not a recruiter but help with software/firmware interviews where I work. When interviewing someone, any and all signals are very useful. For someone fresh out of university, they can show me their student projects. But an experienced engineer, their contributions are usually property of their previous employer and can’t be shown.

To me, being able to see an interviewee’s code is like being able to see an artist’s portfolio. Alternatively, if an interviewee can point to mailing lists, code repos, etc, for open source contributions, that also is very valuable.

Some other folks in the comments are saying they use Github, etc, as a dumping ground for projects. Still valuable. In my opinion, that means you’re interested enough in the project to at least save the code. Plus, even quick and dirty code can have valuable information. Does this person understand, for example, the common idioms in C, C++, Python, etc? (Specific example, using malloc/free/printf correctly, new[]/delete[], not using for i in range(len(foo)). Simple stuff like that.)

Note a repo containing “this is code where I’m learning this language, this library, etc” won’t have the best use of the language, obviously, but will be a good sign this person is learning something new. It’s another signal.

Just my opinion.

Noob question: Why is it bad to use for i in range(len(foo))? Because you can just use for bar in foo?

It’s mostly a bikeshed and a signaling thing. Only a “noob” wouldn’t know about enumerate(), right? The program could be brilliant in much higher level ways, but mid/senior only-knows-Python hot shot will jump on your anti-idiom like a dog on a dropped hamburger. Including such anti-idioms in your public code can filter out people like that.

Yes. Iterating over a range of integers equal to the length of an iterable is really clunky compared to iterating directly over the iterable. Plus, if you actually want to use one of the elements of the list, for instance, in the body of the loop, you would have to do foo[i] instead of referring to it as bar.

As a recruiter I can answer this! I do not speak for all recruiters. As a recruiter who is also a programmer, my approach may be nonstandard.

* I want to see thoughtful README files. If the README is whatever was generated default by the framework and not edited at all, that’s a huge groan and turn off and you lose tons of strength (credibility) as a candidate.

* I want to see your code looking pretty. Consistent indentation, run through a linter, good comments, and so forth. Would I be able to contribute to and maintain this code?

That’s pretty much it. The most important thing that companies want to see is employment history, either at brand name companies or somewhere where you’ve already been doing the job they’re hiring for.

I really don’t see why these things are relevant at all.

It’s a personal Github profile. Why would anyone add thoughtful readme’s or a clean coding style if they’re the only contributor?

I mean, those things are great of course, but not sure if I’d expect it on Github.

My GitHub/GitLab profiles are full of hacky, ugly games written at game jams in 48 hours, often just by me or me plus some artist, with just one end-goal: to be able to present it at the end of the event. A README file is the last thing needed there 😛

I 100% disagree. Even just saying that it was hacked together gives some context for

1) Why the code looks so unconventional

2) What you do in your spare time.

Context for whom? My target audience for my personal projects is myself. Any company that assumes their recruiting org is the target audience for my personal projects is setting themselves up for disappointment.

I write verbose readme files with examples of how to use my libraries because it’s what I expect of other engineers. I do the same for private repos.

Some use GitHub as a portfolio, it seems. Mine is/was mostly a dumping ground of half finished ideas in my college days.

If you use your GitHub profile as part of your personal brand / marketing then these things absolutely are relevant.

As a developer in a professional context you’ll hardly ever work alone or be the sole contributor.

Even if you use a GitHub profile just as your personal code repository code still is communication, even if it’s just with your future self.

Therefore communication skills are crucial. A well-thought-out README file and consistent, readable code help others to understand your work. These aspects often are more important than what the code accomplishes.

Working, even efficient, but unmaintainable code is a risk. Ultimately, code is a precise specification of what the software at hand is supposed to do. If that specification is hard to understand it’ll be much less useful.

The assumption is that if you have a personal github project then you’re doing it because it interests you, you’re passionate about it, and you’re not doing it just for money.

If a developer writes sloppy code when they’re doing it for passion, then that doesn’t show them at their best. Of course we all have repositories, tools, or code, that was just thrown together to solve an immediate project but in general I’d expect something that is a labour of love – not a project for work – to be something that they’d put more effort into.

Ostensibly, you put your code on Github for others to read, use, and maybe even contribute to. If you have a project that you didn’t care enough to write cleanly, or even document in the most bare minimum of ways (a helpful README to contextualize the code) then why are you even putting it online? It’s just going to reflect poorly upon you. If all your Github repos are as described above, people are going to (rightly) assume that’s how you treat all of your projects, even those you are paid for.

That’s quite an assumption to make about intentions. Repository hosting is also a way to back up your code or make sure it’s available on multiple devices. Until very recently, you couldn’t do that and keep your code private on github without paying. So (unless they want to also maintain a bitbucket account) people dump stuff there for reasons other than explicitly wanting to share it with the world or show it off.

> Until very recently, you couldn’t do that and keep your code private on github without paying.

Ok, but now you can.

> people dump stuff there for reasons other than explicitly wanting to share it with the world or show it off.

Maybe, but that doesn’t change the fact you are sharing it with the world and you are showing it off, and if you put a bunch of sloppy inscrutable code on your GitHub, people are going to assume you tend to write sloppy inscrutable code, especially if you don’t contextualize it with a Readme. That’s just the reality of it. The real big assumption here is thinking people aren’t going to judge you by how you present your work online.

>that’s a huge groan and turn off and you lose tons of strength (credibility) as a candidate.

Toxic and off putting. You put too much weight on relatively minor things. It’s preventing you from fairly considering the rest of the candidate. You could be the one to teach them to do READMEs well.

Wow. This comment is deep. People who call themselves managers, read that last sentence 20x. This is what we need to do, can you?

So choose between:

1. A developer who doesn’t respect himself first and foremost to write a README/maintainable code so that his future self and others can have an easier time.

2. A developer who cares about communicating his work to himself/others and making the environment easier for everyone to work for the future.

Right.

False dichotomy, and if you actually witness this first hand and only have two options in your candidate pool, you might need to spread your net a bit further. Also the original post was about READMEs only, so if they have unmaintainable code, the README really doesn’t matter that much, does it?

Developers are at various stages in their expertise when they go looking for jobs. READMEs are nice but try not to let yourself get tied up with emphasis on a few signals that document the whole human. README quality is a pretty weak signal.

If you bring up the README in an interview, and the dev cannot find any motivation or acknowledge that it could be better, then maybe you might have to pass on them. My problem with your methods is that you get to this point without even opening a discussion.

READMEs are a relatively teach-able skill and in pretty quick fashion. Maintainable code, much less so obviously.

> README quality is a pretty weak signal.

It’s a fantastic signal of what the quality of the code will be. Lack of a README indicates many things, including unmaintainable code either via lack of experience or rushed work.

But hey talk is cheap and you seem to know a lot – so how about you link an open source project you’ve published 😉

>But hey talk is cheap and you seem to know a lot – so how about you link an open source project you’ve published 😉

I wrote tech docs explaining the jungle of IT systems that we were relying on at a hospital I worked at, and sometimes that included diving into old code. These were usually much longer than READMEs.

Having a README wouldn’t have saved this code from needing to be refactored. Nor would it have really changed my opinion of the code. It hasn’t been a reliable signal.

The hard part about documentation is keeping it up-to-date and accurate and not filling it with extraneous details and going off on tangents. A lot of the READMEs are written for quick bootstrapping and that isn’t going to reflect much on your code quality. I care more about good documentation and that’s harder to write than a README and a much better signal.

I don’t have time to work on open source but it’s clear my experience has been vastly different than yours and I doubt either one of us are going to come up with a peer reviewed reason for either side.

Turn this around and say “this repo has a README! surely it’s really good and so is the code” and it makes no sense to give that much credit for something that really isn’t impactful beyond the first few days of using something.

You’re choosing between a person who didn’t write a readme and a person who did.

Anything beyond that is unfounded bias IMHO.

(I have a lot of personal projects and I’ve conducted interviews)

Everything you say makes sense on the surface. But it scares me a little bit.

Do you ignore all my half-done prototypes and junky hacks and experiments?

Or your proprietary work you don’t own IP to. Ironically, some look to GitHub to somehow correlate with employment history. Many employed are too busy sinking development time in source that’s never releasable. Some companies may contribute to certain OSS projects publically but a lot of their core business code base is protected.

I would hazard a guess that most pure recruiters aren’t looking at your GitHub profile other than ensuring that you’ve provided one. The hiring manager or interview team, however, might be interested in it.

Here are some things that I check for in a GitHub profile, as a hiring manager and as a recruiter (hooray startup roles!):

1. Repos that aren’t just forks. I’ve seen plenty of profiles where the majority or entirety of repos are forks. Unless there’s some annotation that talks about contribution to those projects, I assume that those forks don’t contain any actual development.

2. Code past the boilerplate. A lot of projects start with enormous boilerplate, checked-in node_modules, and large-app scaffolding. The README should have a pointer that says “actual code is in src/app/site” or something, otherwise I click around for where the commit message is something other than “initial commit”.

3. A real README.md. Bonus points for README.md in the subdirectories.

4. A “real” photo of you. LinkedIn profile pictures tend to be very professional and buttoned-up (sometimes literally). Most GH profile photos in my experience are a closer of the real person though. You’re more likely to see a casual photo, a hobby, someone’s dog, a photo of their art, etc. When that person is working with you, they’re going to act more like their GitHub profile photo than their LinkedIn profile photo. Conversely, when I don’t see a profile photo, that’s concerning.

5. Nothing too boring, or too creative, in the name. The era of screen-name judging is not over, and you will get judged based on your GitHub handle. John35082192 makes me think that John reluctantly created a GitHub account and loathes using it. XxCodeMurdererGoatSlayerJohnnyXx makes me think that John is a bit of a weirdo, and his code reviews may be… uncomfortable.

6. Stars. If your real repos have real stars (or even forks), that means that not only have you creating something cool, but you’ve created something useful, and marketed it at least somewhat well. NB: repo stars are not expected for professional-profile style repos, only if you’re creating something for an actual OSS community.

7. A real github.io page/repo. Maybe this is the basis of your professional profile, maybe there’s a link to a personal website in your profile, but I am interested in seeing how you present yourself beyond which repos you show first.

Same here; I’m woman, and over 50. I use a landscape snapshot from an enjoyable daytrip for my profile photo. Is this, like removing graduation dates from a resume, an undesired tell?

That’s a fair criticism. Having any kind of profile image I think is preferable to the default, because then it distinguishes you from someone who signed up a day ago. So it doesn’t have to be a photo of you, it could be a photo of your city, pet, some hobby etc.

Just something to humanize the profile, even if it doesn’t gender the profile.

It feels kind of weird that large parts of the world have stopped to do profile photos on CVs for fairness reasons, but then you expect people to have photos in the links they put on said CV?

EDIT: and re forks: surely regular PRs against other projects would also tell you something?

I definitely would expect real photos of the person on LinkedIn, and everyone I know who hires will look on LinkedIn as a confirmation of the resume. Not sure if this is a vector to enable bias or not, but it’s a reality of hiring for many.

As someone doing interviews, most of the github profiles I’ve seen have a bunch of forked repos with little to no added code. I don’t understand why people include a link to that.

A couple of times I’ve seen real code and it certainly didn’t hurt.

I’m not convinced that the Github profile is for recruiters alone. As someone doing hiring at the company, I want to see it myself.

So what am I looking for? Clean code that’s more than just boilerplate. Comments, good logic, some sense of purpose. There can be garbage repos in there, too, but I expect there to be some that show off who you are.

In short, they want to see who you are. If your Github isn’t showing who you are, you’re not helping yourself by providing it to the recruiter.

I’ve been writing code for over 20 years yet I don’t have anything that I can share in a public repo. My employer would sue me immediately. I don’t imagine I will be looking for a job via the “normal process” with recruiters and all, but if I did, would I need to put out stuff to github? Would I need to spend 6 months just writing random but nice-looking code so I’m not rejected due to not having github profile?

I think there’s a lot of people like that. Making github a mandatory requirement is strange.

When interviewing devs, I always check GH profile. If its empty it’s usually a read flag (meaning that I will have to do more work during the interview). Coding samples, contributions graph, personal projects can push a candidate forward very fast.

Worth to note: GitHub itself does NOT matter, the contents your profile and you contributions do. Prefer GitLab? awesome! Just don’t forget to put it in your resume.

I’ve never met a recruiter who discussed my GitHub beyond asking for the link. As for interviewers, my GitHub has only been brought up a handful of times.

Related question: how many recruiters actually look at GitHub pages? Does this number change if one is linked in the resume they’re looking at?

Yes, please put your GitHub, GitLab, etc, profile on your resume. When interviewing, being able to see someone’s code quality is golden.

But do you actually look at them? I have my GitHub profile in my resume, but I’ve never once been asked about anything on there, nor has a recruiter let on that they had looked at it.

Since most people’s work is going to be in private repos, Ive always thought the most consistently valuable signal is the contribution graph.

But that’s just my opinion.

For sure, I’m not saying it’s a universally valuable signal, just the most valuable one relative to other signals on a github profile.

I want to know what other people will see when they look at my employees GitHub Account. If I see nothing that concerns me, I move on. All of our companies code is private so an empty GitHub is not concerning.

Daily stars in the seize_the_means_by_any_means repository is going to get your resume tossed.