
Ask HN: What do you look for in an applicant's GitHub? - bmpafa
I&#x27;m a self-taught JavaScript guy &#x2F; solo-preneur &amp; have been thinking of seeking part-time &#x2F; contract work.<p>Skill-wise I consider myself (FWIW) between &#x27;mid-level&#x27; &amp; &#x27;experienced&#x27;, but having never worked professionally as a dev, I&#x27;m uncertain about hiring expectations, particularly wrt code samples. Most of my code is closed source, so I&#x27;m looking to build-out my public stuff.<p>When you review an applicant&#x27;s publicly available code, what&#x27;s important for you to see?  My assumption is that reviewing a repo is akin to reviewing a portfolio &#x2F; resume (i.e., very quick), so how have applicants &quot;wow&#x27;d&quot; you in the past? (I mean short of obvious rockstar qualifications, like &#x27;React core developer,&#x27; etc.)
======
codingdave
I don't use github content as a criteria, at all. Not everyone uses github as
a portfolio. Not everyone uses github at all. Some people just store stuff
there, not worrying about the quality it may communicate to the world. Other
people work primarily in private repositories, so their public data doesn't
tell you much. Someone could just have a bunch of forks of other people's
work, which they dabble with. And newer coders are often learning quickly, so
their code from even a few months ago is not representative of the effort they
would put in professionally if hired today.

~~~
lucb1e
I agree with your comment, just wanted to point out that:

> 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.

~~~
WorldMaker
> 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.)

------
rzimmerman
Not everyone can post their work on GitHub, so I only look at their profile if
they list it on their resume. I figure if you put it there, you want me to see
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.

~~~
0xfeba
> How they interact with maintainers and other people

> 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.

------
botskonet
I look for signs of understanding.

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.

~~~
watwut
This comment reads like argument for not putting most of random personal code
people write on github. It can harm you.

------
makecheck
For me, it would be signs of a sensible structure and use of commits. It is
_extremely_ offputting to see some obvious code dump, with like 2 commits in
total (one of which is “fixd typo lol”), no real directory structure, etc.

A 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).

~~~
sowhat99
So what? I use Github for any code that I want to share. I’m sorry my weekend
project only has two commits. I didn’t realize I was being scrutinized for
every tiny detail. Would you like every social media post as well to make sure
I’m perfect 100% of the time, even in informal situations where perfection is
not expected?

I would not want to work with/for you.

~~~
bjourne
It should be like this:

well-organized github > chaotic github >> no github

instead, when employers evaluate github profiles, they reason like this:

well-organized github > no github >> chaotic github

~~~
gruez
>It should be like this:

>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?

~~~
mwfunk
Anecdotal of course, but in my experience, when hiring professional engineers,
neither I nor anyone I know would judge someone for not having a Github page
to look at. If they have one, great, I'll take a look, but if not, no big
deal. It's not an expectation at non-startup tech companies.

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.

~~~
Sir_Substance
>It's not an expectation at non-startup tech companies.

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.

------
segmondy
As someone that has interviewed hundreds of people. Nothing unless they really
want me to look at 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.

------
cbzehner
It depends on the person and my expectations for the role. The best people
have everything, including jobs! So I make it a rule not to expect perfection,
helps prevent disappointment.

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](https://github.com/cbzehner/word-frequency)

------
victorNicollet
I want to be able to understand what the project is about, and get a high-
level understanding of how it works.

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).

------
vorpalhex
Things that set off alarms:

\+ 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

~~~
segmondy
I use github to track repos I'm interested in. I'll fork it. I've seen
projects just disappear.

I fork tutorials for the same reason or even good tutorials I want to keep for
those I mentor.

:-)

~~~
chatmasta
I set up a separate organization (“milesforks”) specifically for this purpose.
This way my main profile is not polluted with forks.

------
jrowley
Different projects have different needs certainly, but its nice to see a
readme that gives me some context to what the project is, and how to actually
run the code, install needed dependencies if it's not obvious. Also probably
worth acknowledging shortcomings or places for improvement in the readme, so
your reader is aware that you're aware of any deficiencies.

------
hnruss
I occasionally interview candidates for a small software team (less than 10
developers). When evaluating a candidate's GitHub account, I look for any non-
forked projects (projects that they created/own), then I look at the
structure, code, documentation, and commit history of those projects.

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.

------
vec
Honestly, the main thing I'm looking for is that they have a Github account
that's more than a couple of weeks old and has some sort of content in it.
That shows me that the applicant is interested in programming for its own sake
and not just checking a box to make their resume look good. Everything beyond
that is just a nice-to-have.

------
Jach
I went through a round of resume filtering and interviewing for interns
recently, but I'd use a similar process for FTEs (just less lenient probably).
I mainly used the Github profiles (for those who had them) as another seed for
questions besides the resume itself, and it could give me a feel for how well
they'd do on our simple coding challenge. For example one candidate checked
some API keys into his projects, those are generally supposed to be non-
public. I asked about the dangers of accidentally committing private keys in
general and he talked about AWS keys and relayed a story of compromise that
happened to a friend, then I asked what a main problem of checking in API keys
could be and he mentioned rate limiting denials. So he understood the
problems, I asked why he had API keys in some of his repos, turned out to be
he thought he had disabled the ones that were checked in (at least one I tried
wasn't) and they were for hackday projects anyway. With some context on it,
and other discussion, all in all I was happy with him.

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.

------
dmuth
Something that's important to me is code that is commented. Well-commented
code (documentation for each function, explanations behind complex if
statements and loops, etc.) earns bonus points. Conversely, when I see screens
and screens of code without a single comment that sets off red flags.

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).

~~~
rinchik
Interviewers like yourself are great red-flags everyone need to look for in a
company during the interview as well as during initial screening.

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.

------
xemdetia
I generally only look for the 'bigger' projects, and only really bother if it
is explicitly mentioned as a thing to look at (e.g. used this open source
project/language). Even then my criteria is the same I would approach to a
source code review:

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.

------
Sir_Cmpwn
An empty, boring, or bad GitHub account never hurts, but a good one can
definitely help. Things I'm looking for are interesting projects,
contributions to other projects (perhaps ones I know about), good discipline
in git commits, well organized code, attention to detail (as in code style),
and good interactions in tickets and code reviews. I'm not interested in
whether or not your GitHub projects use any particular languages or
technologies that are relevant to the role.

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.

------
cyberlync
I primarily look for signs of the ability and interest in self-teaching. A
front-end developer exploring the backend? Great! A backend developer playing
with probabilistic systems? Super!. A java developer branching out into
Scala/Clojure/Rust/Haskell etc? Even better!

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.

------
Raed667
I have a pretty active Github. When interviewing I talked about it and put a
link in my resume. People very rarely check it, but it gave me talking points
when the tech of some old project matched the company's stack.

------
contingencies
Multiple projects of interest (not just commercial), ideally with
significantly different languages and problem domains. The ability to write
clear documentation. Definitely not a pile of cloned repos with no contributed
changes.

------
pkamb
A well-developed README that promotes the project. Screenshots, explanations,
an FAQ, release notes, info for collaborators, links to download or test.

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.

------
bamboo_7
I try my hardest not to do any 'grading' based on someone's github, but
instead use it as a reference of what I can expect when the candidate gets to
the interview. There's always a feeling out point at the beginning of the
interview. I don't want to waste time hashing out things they clearly
understand and likewise I don't want to throw them something over their head.
Looking at their Github helps give me a starting point.

------
scardine
First, I want to see contributions to flagship opensource projects. If you are
using opensource stacks and pushing the envelope, you will eventually have to
fix bugs or implement new features. Landing patches means the applicant is
able to meet the high bar for contributions (code quality, documentation,
tests).

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.

------
ellisv
I look for many things but don't hold it against you if your
GitHub/Bitbucket/GitLab/etc doesn't reflect it.

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.

------
drxzcl
If I'm investing the time to look at her/his github, I have probably already
invited the candidate over for an interview, or am seriously considering doing
so. I'm looking for anything that gives me an insight into the way the
candidate approaches problems, than I can then use to further the interview.

Any github that contains more than just course work is fine for that.

------
marssaxman
I'm not sure I've ever bothered to look at an applicant's github account. I
wouldn't expect to learn much from it. I am amused to imagine just how strange
someone's impression of me would likely be, were they to derive it from the
random collection of experimental hacks in my personal github account.

------
andrew_wc_brown
Here in Toronto I always ask, have you looked at the source code I shared? And
the answer is no.

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.

------
iopuy
Do the people here preaching github being a useful tool for candidate
evaluation realize there are private repos? I use github everyday but none of
the outsiders looking at it are going to get a sense for my coding style
because they can't see the content of the commits.

~~~
t3h2mas
Yes. I am guessing they are taking that into account and expect you to do the
same.

Getting some code public now and then will the outside world get that 'sense'
easier than other methods.

I've ran into this where both my day job code and side project code are
proprietary. I looked at my github profile and felt underrepresented. Now I
have the goal to push something public here and there.

------
watwut
Realistically, pretty much anything sane is a plus, because most applicants
don't even have github account. AlSo realistically, have a good readme because
that is the thing most hiring managers will read (unlike codebase).

