Ask HN: What do you look for in an applicant's GitHub?
I'm a self-taught JavaScript guy / solo-preneur & have been thinking of seeking part-time / contract work.
Skill-wise I consider myself (FWIW) between 'mid-level' & 'experienced', but having never worked professionally as a dev, I'm uncertain about hiring expectations, particularly wrt code samples. Most of my code is closed source, so I'm looking to build-out my public stuff.
When you review an applicant's publicly available code, what's important for you to see? My assumption is that reviewing a repo is akin to reviewing a portfolio / resume (i.e., very quick), so how have applicants "wow'd" you in the past? (I mean short of obvious rockstar qualifications, like 'React core developer,' etc.)
58 comments
[ 0.61 ms ] story [ 106 ms ] threadA repository is an opportunity to show off how good you are at organizing a project, breaking down your commits, etc. Only after any of that looks promising, will I bother to read any code (after all, it takes time to understand something and the harder it is to grok the less likely I’ll spend the time).
I would not want to work with/for you.
No one is a perfect coder, but it is discouraging to look at a candidates GitHub and see that the majority of it is a mess since they included the url on their application, which generally indicates it's something that they want to show off. Not every repository or commit has to be perfect, but if you submit a public GitHub profile, expect it to be scrutinized in detail.
Github is a social media platform. Last time I applied for a job, I gave the company an account and URL to access my self-hosted kallithea instance instead.
There are a world of benefits to this. I only gave them view access to the projects I considered to be portfolio pieces, and locked them away from the scratch projects.
It also allowed me to see how many times they logged in, which is how I know that they never actually looked at any of my hobby code before offering me the job.
Lets be real here, companies want your github profile for the same reason they look you up on facebook: everyones at least a little bit into voyeurism. Give 'em something that they know will be logged and scrutinized back, and you'll see what a chilling effect looks like.
well-organized github > chaotic github >> no github
instead, when employers evaluate github profiles, they reason like this:
well-organized github > no github >> chaotic github
>well-organized github > chaotic github >> no github
I don't like to share my random projects on github, just like I don't like to share my life on facebook, fuck me right?
I've heard some people here on HN occasionally say that if an applicant doesn't have a Github page to look at, they will think less of them and maybe not even give them an interview. I always imagine the people who say this as being guys in their early-to-mid-20s who are fresh out of school, never worked anywhere outside their comfort zone, are still within a comfy bubble of friends and family, and went directly to the startup path where they are learning about stuff like recruiting and management in real time (if not outright making it up as they go along). I don't know if that's a fair characterization- it probably is unfair and inaccurate. But that's the stereotypical person my subconscious imagines those posts come from.
The silver lining is, if someone doesn't give you an interview because you lack a Github page, you probably don't want to work for them anyway.
Not true in the slightest. Before you get to talk to the engineers like this, you must first pass the HR filter.
HR are not engineers, but they think they see a parallel to their own work.
In HR, all HR applicants are expected to have a linkedin page, because linkedin makes HR's life a lot easier. I have Strong Opinions about this state of affairs, but none the less, there is a hovering perception in most HR offices of "if you don't have a linkedin page, how good at your job can you really be?".
So then HR hears the engineers talking about github and profiles and sharing code and they dig a bit, and they often decide that github is basically linkedin for engineers. Lets be real, they're kinda right in some ways.
But they're dead wrong in others. Lets not get sidetracked, but just say there are valid reasons some people don't use it. Engineers have the full picture and know this. Like you say, most professional engineers won't judge you for not having github.
However, HR lacks the context to understand this, and so they increasingly throw out engineering CV's that don't include a github link. It's a growing problem.
This is like being a graphic designer and saying, "I disable the undo feature in Photoshop for all my personal projects."
It makes no sense to people for whom source control is second nature, and I'd be reluctant to hire someone for whom source control is not second nature.
If instead it's just a casual place where you mostly just plop random stuff to share with friends, that's fine too, but don't show it to a potential employer, any more than you would send them links to all those social media posts that you don't want them to judge you by. It's pretty simple.
If you're going through some company's hiring process and slip in a, "hey, by the way, check me out on Github", they will naturally interpret its contents as an example of you at your best, because otherwise why would you want them to check it out? Job seekers don't go out of their way to publicize their Github output on their resume if it's just a place for brain dumps and code snippets. Nothing wrong with using it that way of course, but it's not a useful thing to show to hiring managers, in the same way that I wouldn't go out of my way to show them my class notes or old tests from college. It's not relevant, and may even give them the wrong impressions.
I don't even know if I could do it another way because at the early stages of a project I tend to leave a lot of junk in the commits that I wouldn't want to be public :/
And I don't feel bad about it at all :P
I want to see an understanding of git - they have repos with appropriate commits, good commit messages, awareness of licensing, decent READMEs or info for collaborators
I want to feel like they understand how open source works - they've filed or participated in issues/discussions, they've starred/forked repos, they've opened PRs, they've managed issues/PRs on their own repos.
I want to see how they manage their projects/repos. Do they use a package manager? Do they have linting or build tools? Do they use CI? Have they kept the repo clean and ready for others? Do they use automated testing?
I don't expect to see all of this - but if someone has none of it, it's clear they have a lot to learn and aren't ready for the job.
Our hiring process starts with a phone interview and there's a quick technical discussion (mostly there to avoid wasting time if the candidate's skills obviously do not match what we need). A live coding exercise is hard to set up and takes a while to perform, if only because the candidate needs some time to understand the question and gather some elementary insights. So, instead, I ask the candidate to explain some code that they have written, and I expect them to be articulate and knowledgeable about it.
So I want to be able to find a commit or file that can serve as a basis for an in-depth discussion relevant to the kind of work that the position involves. If I'm hiring for web front-end, then client-side JavaScript will have to be involved. If I'm hiring for Big Data, then high-performance code, low-level code, or distributed/parallel code will be good. If I'm hiring for Compiler Design, then a toy (or non-toy) compiler is nice.
I will tell the candidate ahead of time about the commit/file that I find interesting (or even ask them for pointers to help me pick one). That way, if they join me on the phone interview and have no idea what their code is doing, that's the end of the line.
I don't really care about code quality. Obviously, if the code is so bad that it's impossible to understand, that's bad news, but most of the time the code is readable, it's just missing comments, or has variables like `item2`, or functions that are too long, or other stuff that you would expect in an open source project. That's fine, because it leads into two very powerful questions in this type of interview: "Are you happy with the quality of this code?" (the correct answer is "no") and "If you had a few weeks just to improve this project, what would you do ?" (I expect insights about refactoring, or improving test coverage or even improving testing/validation strategy, or adding comments).
> Someone could just have a bunch of forks of other people's work, which they dabble with
is quite easy to spot: those repositories will have "Forked from user/repo" below the repository name (on top of the page, and also in the list of repos of a user). If they committed their dabbling, that is almost certainly on top if you go to the commits screen.
If they committed their dabbling right, and the default branch is still master, it will be in another branch, possibly with a PR attached. It's certainly possible to use a fork master directly, but I think it's a quickly learned lesson to only use a fork master for upstream tracking. (How far behind a tracking branch like that is can be informative, sometimes.)
I never provide or look at anyone else's code before getting to know them for these and many other reasons, but mainly because a repository is in such a vacuum, without context or correlation to what the person really can do.
To paraphrase an old mentor: "Someone with a perfect repository is either faking it or has never taken enough chances."
She said that it was an opportunity to ask a core developer of a lot of open source projects some questions. After looking at his GitHub profile a few minutes before he arrived, it turns out that she believed that all the forks on his account meant that he was an active contributor, when in reality this guy was using forks to save repos he found interesting.
In all fairness to my boss, this guy tried to lead us down that road, since he had contributed a typo fix to a README file a few months ago, and used this as a way to say he was an open-source contributor. Strictly speaking, he is, but there's a big difference in what he's done and what my boss thought he had done.
Given that many developers don't really deal with GitHub all that much, outside of as a link to documentation for hosted code, it wouldn't surprise me if some hiring managers had hired people based on what they've forked, rather than actually checking to see if they've written any code on the account, or whether it's any good.
Then I want to see side projects using the same stack that will be used internally by the applicant. You can tell a lot about someone by his code style.
+ Lots of unmodified forks or tutorials. A few is fine but too many is suspicious.
+ Tons of empty repos
Things I like:
+ Lots of messing with different projects even unsuccessful work
+ Side projects, even incomplete ones
+ A mix of languages/designs/idioms
Super awesome things:
+ OSS contributions
+ Working well with others
+ Good branching
I fork tutorials for the same reason or even good tutorials I want to keep for those I mentor.
:-)
When I'm evaluating candidates from a resume, if they have a link to a Github or personal website I'll visit it about a fifth of the time. I'll open up a couple repos and make note of what they look like.
Are they school projects? That's fine but not necessarily indicative of anything since most academic code is write-once, run-once for an assignment.
Does it look like a personal project? Great! This is what I'm most interested in.
Is it easy to understand what the project is before reading the source code? README files and a clear directory structure/file names can go a long way here.
If I look at the source code, how is the readability? Do they have good variable names (i.e. not a, b, c,..,z) and use the idioms of their programming language?
Bonus points for good comments. Triple word score if I can understand the code without comments.
I'll go through a couple repos this way and use whichever one is best to inform my initial bias. I think it's always a good idea to assume best intent when interviewing someone. I've had some people I wasn't that excited about in an interview become my favorite coworkers over time.
PS - Here's a project of mine I'd consider a "good" example. Mostly the number of unfinished {- TODO -} comments in src/Lib.hs would hurt me here, were I evaluating myself. https://github.com/cbzehner/word-frequency
Basically, the github repo as a homepage for a product rather than just a dump of text files.
This shows that your thing is a finished project or under ongoing development rather than just a dump of some source code that you once wrote. It's the equivalent of having an app on the app store vs. having a half-baked Xcode project on a computer.
I have lots of source code open to private to share, and its just because I'm a workaholic, though I find having source code doesn't matter, at least not here since they don't put much value in it.
As someone that still loves to code even tho I'm in management, I've found out that writing beautiful code get's in the way of getting shit done!
When I code for myself, it's either to explore or practice. Beautiful code is not the goal. If I'm exploring a new idea, then one thing I like to do is to make it happen as fast as possible by any means necessary. I don't care about comment, duplication, abstraction, tests, optimization.
That's what you will find in my github, I don't do resume driven development where I write code hoping to get hired because of it.
For early-career people (with limited work experience in the field) I look to see what tutorials they've done. I don't expect high code quality, but active engagement instead of copy-paste is nice to see.
If they've contributed to any OSS projects I look at things like:
- How they interact with maintainers and other people
- The quality of their PRs if any
- How well they communicate issues and file bugs. Attitude
matters a lot (offering helpful ways to reproduce it and suggestions rather than attacking the project for faults)
If they have any of their own projects I look at code quality. I deal mostly with Python and it's pretty easy to tell from a glance how experienced the person is. Things like following lint/style and style guides but also readability in general. You can smell out a C/JS programmer who just learned Python pretty easily (lots of for loops with indexes, for example).
If they collaborate on projects with others that's a huge plus. I look for signs of active collaboration, like PRs with good code review.
Basically I want to make sure:
- They're not exaggerating their experience (though GitHub profiles can be out of date)
- They work well with others
Again, just because a GitHub profile is sparse or missing some of these things isn't a signal. Not everyone does their work on GitHub. But if you list it in your resume, expect me to read it.
> The quality of their PRs if any
> How well they communicate issues and file bugs. Attitude
That information is extremely valuable when available. When looking at profiles, if I see a person can't parse information provided by other maintainers, or put in a due diligence into narrowing down or solving a problem when filing bugs I will reject them without even a first phone screen (exceptions when the PR/comments are old, etc.).
But it's rare to come across this information.
There's this idea that no one should be expected to spend their spare time working on open source, which is fair. However, that are many candidates that do, and it helps a lot with the screening process. We might waste more of your time and ours if we have to coax out the kind of insight that I can get from a GitHub profile over the course of several phone screens and IRL interviews.
Due to the nature of my current role, writing documentation is necessary so that other team members can pick up where you left off if something happens to you (or you just go on vacation).
If a company relies on (outdated, in most cases) comments and not the code itself its an immediate signal for an interviewee to re-evaluate this company and decide whether or not its the place he or she actually wants to be a part of.
Very important to mention that it goes both ways: if I need to read your comment in order to understand your code, there is something wrong with your code.
Only "overview" comment blocks for entire files, which describe the overall purpose of the class or module, are useful to me and my team.[1]
1. https://softwareengineering.stackexchange.com/questions/2857...
Any github that contains more than just course work is fine for that.
For those that won't look at Github because not everyone has an account. That doesn't make sense. Whether or not the candidate has a Github account is not a litmus test, its just additional useful information. If they have an account that may tell you something useful about the candidate. If they don't have an account, then you have to rely on other approaches to get that information.
Your profile can give me some evidence that you know how to code, use version control, write documentation, etc. -- but just because your projects don't have CI/CD (or whatever) doesn't mean you don't know how to use it just that I don't have evidence that you know how to use it.
At that point, the quality of the project can either help or hurt the candidate:
- The most important thing is that whatever project content they have, it is understandable. The ability to write sensible code that follows conventions and is well-documented (in code and commit history) is highly desirable.
- Ideally, they'd have an open source project with recent releases, issues, milestones, contributors, PRs, etc. (basically all the signs of a healthy open-source project). If they had this, then they'd be way ahead of most candidates.
- It's easier to evaluate docs and commit messages than it is to evaluate code quality, but I do try to pick out a few files and have a look to see if they make sense.
1. Is the code well formatted? If you haven't been someplace where it is bad, you might not understand how bad can be. I'm not going to give someone on a pass on something even the worst editor can do great.
2. Does it look awful to build? I have seen projects presented to me that have no Makefile or appropriate mechanism to build the code successfully but 50+ source files. The exception here is obviously templates or ~1-2 file projects to solve a real problem. I don't want to hire someone who can't build software, or make their software nice to build.
If those first two criteria aren't covered I'll skip to my last criteria:
3. Lack of input validation/error handling/logging errors.
4. Knowing common language constructs. Even in learner projects I want to see that you know how code should feel in that language. Python is one of the ones where this is most obvious, Java is one of the ones where it is least obvious so this is a subjective piece.
5. Does it feel like original work or tutorial spam? Where's the artistic flair or the completely engineered and mechanical thing that made this more than a 2 hour project, and worth your time?
The main thing is that your resume should strongly reflect that you want to change careers as a dev and you want to demonstrate your skills via GitHub. I would not go fishing unless you ask. I'm going to look at your technical experience and general work history and ask you just as many questions about those kinds of things.
I try not to let presence or absence of Github matter (and in general I try to differentiate on common information rather than lucking out to see a very negative / very positive trait in 1/10 candidates that I wasn't explicitly looking for), but I have to admit I like to see a link and like to see at least one project on it of any size and not just a sea of forks with no clear individual contributions. Resumes seem to correlate with coding performance terribly, at least if there's public evidence you can code (I'm not too picky on code quality, that's what reviews are for and drive-by open source reviews are non-existent) I don't have to spend as much effort verifying such in an interview.
I'm not looking for rockstars. Using the classic trade ranking system, there are apprentices, journeymen, and masters. Journeymen are essentially interchangeable for most normal tasks starting from scratch, that's what I want to hire and work with most of the time. I can live with a sharp apprentice, especially if the apprentice is pretty skilled in the usual domain we already work in. Since I'm not a master myself, and I can think of no more hostile and futile way of attracting them than standard software interview practices I'm forced to somewhat conform to, I don't try to get them.