
How to present a GitHub project for your resume (2016) - user5994461
https://thehftguy.com/2016/10/24/heres-how-to-make-a-good-github-project-for-your-resume/
======
__s
I definitely make this mistake. I have a handfull of maintained projects, but
nearing 100 repos, most without readmes, many are just random ideas

The last time I interviewed the technical interviewer actually had me go over
my openEtG project, & dive into the guts of the AI's eval. They also stumbled
upon
[https://github.com/serprex/brainwebfuckassembly](https://github.com/serprex/brainwebfuckassembly)
which ended up having a profanity filled interview

They started to explain the code challenge that would follow if I was invited
to a 2nd tech interview before realizing I'd already done it:
[https://github.com/serprex/backend-coding-
challenge](https://github.com/serprex/backend-coding-challenge)

I fixed their github pages page (previously wouldn't load stats & projects)
[https://github.com/coveo/coveo.github.io/pull/3](https://github.com/coveo/coveo.github.io/pull/3)
but that didn't come up

I didn't get past the first tech interview. Admittedly I'm terrible in
interviews: bring up feeling I have a weakness with mathematics, don't have a
prepared answer for "what is clean code", when asked about "code patterns" I
start rambling about how data structures are essentially a pattern

~~~
penpapersw
My difficulty with interviews is, I'm a fairly good programmer. But when asked
to put these kinds of things into words, that's just not how my mind works. I
see the patterns in abstract ways, and I know which ones to use when. And I
can write clean code pretty well. And if presented with a concrete problem to
solve, I can communicate effectively on how to solve it. But during
interviews, or any kind of abstract discussion about "code in general"
(whatever that means), I fumble and stumble and can't put my thoughts into
words no matter what.

~~~
B73kkww
I often see an inverse correlation between being able to "talk about code" and
actually producing good code.

That is not only between persons: I can get myself into a talker's mindset in
a couple of days just by reading, drawing diagrams and generally doing
anything that increases self confidence.

My actual coding abilities drop in the process because the ability to see
abstract graphical patterns decreases.

On my best coding days I'm barely able to utter a coherent sentence at the end
of the day.

~~~
cjcenizal
I think there's a correlation between being able to explain something and
fully understanding it. Being able to think clearly and communicate clearly
are interconnected -- if you're programming by instinct then you're not
thinking critically about the problems you're solving.

~~~
acidus
And how can you get better at it?

~~~
TheCowboy
Writing. When you engage in writing out your thoughts you quickly realize that
you may not have as coherent or clear explanation as it may feel to you. You
end up doing some research and thinking about how to express it. At the very
worst, you come away with a better way to express one specific thing. Even
just trying to provide quality explanations to comments on Reddit is a good
practice.

That won't always help when it comes to verbally expressing things on the fly.
If you can't practice with someone, you can try recording yourself trying to
explain a topic on the fly, and playing it back. It's best to have a partner.
Attending technical Meetups is another venue where you work this mental
muscle.

~~~
brooklyn_ashey
I agree. Writing helps. Murakami thinks so too! Have you read What I talk
about when i talk about running? It might be interesting for swes. He writes
about how writing helps him refine thought and relates this to training in
running. Great book.

------
nawitus
"Nobody cares about your code"

That's a peculiar claim about people who hire employees to create code.

"It’s not the code that counts, it’s the product"

So is everyone only hiring programmers who write code which can be sloppy and
full of technical debt and impossible maintain, as long as the product works
okay for now?

~~~
humanrebar
Yeah. Code _is_ the product.

It's like saying, "we don't sell ingredients, we sell meals".

~~~
dsacco
...which is true. Restaurants sell meals, not ingredients. Chefs don't give
you ingredients to eat, they craft the base ingredients into something worth
selling, preferably with a good experience.

I get your point, but that analogy has backfired on your point. I'd rather
cook something that tastes really good using whatever ingredients are around
and then improve the ingredients (among other things) later on.

~~~
humanrebar
The meal is made up of the ingredients. You can't make a good meal from
spoiled meat.

Restaurants sell meals. Because of that, they have to pay attention to their
ingredients. At least to make sure they won't make anyone sick. And, if they
are making a premium product, they need high quality ingredients to make a
high quality product.

You can't just replace the fresh mozzarella with Kraft singles and still sell
pizzas for a premium price.

~~~
oliv__
Fast food begs to differ: you can make some pretty tasty stuff with terrible
_terrible_ ingredients.

It's tasty alright... Just don't expect to wake up feeling great the next
morning.

~~~
quesera
That's true, _but_ fast food ingredients are not substandard ordinary
ingredients.

Fast food ingredients are highly tuned and customized products -- they're just
not optimized for traditional notions of quality or nutrition.

------
MaxLeiter
Here's my solution: [http://maxleiter.com](http://maxleiter.com)

Also have the same repos on my pinned repositories on github. On the site, for
the projects I contribute to, I mention the majority of what I actually worked
on and provide links to the PRs. Also, the "contributor" badges lead to a
Github search of my name on the project.

~~~
paradite
Fantastic profile for someone still in high school!

One unsolicited suggestion: You can fetch the number of stars of each repo to
showcase the their significance, recruiters are more attracted to quantified
numbers.

~~~
MaxLeiter
Thanks. I was thinking about that but really enjoy not requiring JavaScript,
however maybe its worth it. I'll try it out

~~~
paradite
Actually you can write a Node.js script that fetches and generates the static
html to display the repo stars, so the website itself won't load any JS. You
just need to run the script once in a while.

------
ashark
If you expect the people reviewing it to be developers:

1) Tell me how to run it locally (docker is a good idea, if relevant) and
where the code's entry point is.

2) Don't use a framework. I don't want to spend time figuring out which of the
20+ code files here have actual code you wrote and which are auto-generated or
boilerplate. I'd much rather see something simple but well-written using the
language's standard library and a couple well-selected imports than a Twitter
clone in Rails or Django or whatever. I certainly don't want a tiny little
todo app in a big-ass framework. I won't get upset over it and write you off
as a candidate or anything, but you're not gaining many points.

3) You want people to actually engage with what you wrote, spend time on it,
and want to talk about it? Don't write a todo app or any of that crap at all.
Write a simple game. Put "game" in the title so it shows up in the URL.

~~~
dpritchett
I failed a interview for a job I'd like to have gotten by trying to impress
the reviewers with more handrolled stuff and nothing bloated. I asked and the
folks who passed just used Rails. My submission was alternately perceived as
underwhelming and trying too hard.

~~~
lgas
Sounds like you dodged a bullet.

------
tschellenbach
This doesn't make any sense, as an interviewer I will definitely read your
code on Github. It's a great way to get a sense of how someone writes code
without having to ask for a time consuming assignment.

If you have a popular open source library on your github thats a huge plus. It
shows that you've mastered quite a few different skills. From documentation,
to promotion, ease of use, testing, accepting contributions, review etc.

But even if it's just a 1 star repo, it at least gives an overview of your
code quality and style.

PS. we're hiring [https://angel.co/stream/jobs](https://angel.co/stream/jobs)

------
deadsy
As an engineer hiring engineers, if a candidate gives me a guthub url then I'm
going to take a look. There are too many people coming through the door who
are marginal coders, so if I can get a sense of what they do for something
other than a white board problem then that's a good thing.

------
franciscop
I have a quite "complete" github (
[https://github.com/franciscop/](https://github.com/franciscop/) ) and still
totally agree with this article. Githubs profiles/repos are not for resumes.
They are for many other reasons, but if that's your main reason it shows.

On the other hand some employers might find you straight from your github or
some of the projects you have made. I was also contacted as one of the "top
devs" (whatever that means) of CSS and JS in my country according to
[http://git-awards.com/](http://git-awards.com/).

~~~
mhurwi
You authored Picnic CSS? I've used it and I loved it.

Not sure why someone with a similar repo, high quality with lots of stars,
would not include it in their resume.

~~~
franciscop
Yes, I am the author, thanks! If you have any public site please let me know.

What I mean is that there has been a larger (apparent) impact directly from my
project(s) than from the fact that they are in my resume (
[https://francisco.io/resume](https://francisco.io/resume) )

------
funkaster
> Conclusion: Noone cares about GitHub. Noone is gonna read it. Everyone is
> gonna ask for it nonetheless, cause it’s hype.

True. We don't ask for GitHub links because they are pointless from a
screening perspective. I'm happy to talk about them during an interview, but
if I see a github link in a CV, there's little chance I will visit it.
(Source: I'm a hiring manager at a tech company, have been in a similar
position at previous jobs for several years).

The fact is, as a hiring manager, I would have no time at all to do anything
if I start looking at all my candidates' github links. I would be more than
happy to look at a portfolio showing _products_ built by them, if they look
interesting, I can ask technical details during the interview.

~~~
ibejoeb
>I would have no time at all to do anything if I start looking at all my
candidates' github links.

How do you decide to get the candidate in the pipeline? Presumably you're
reading a CV and a letter, then having a phone call, etc. You don't think it
would add context and clarity if you took 20 minutes from those activities and
devoted them to examining a specimen?

Do you do whiteboard interviews? I've never done one less than an hour, and I
think you'd be able to glean quite a bit of the same information by looking
through the log.

Do you do homework? Who examines it? Could you not get similar perspective
from looking at contributions on GitHub?

>I would be more than happy to look at a portfolio showing products built by
them

To me, a candidate that has full-blown products out there is fast-tracked.

~~~
funkaster
> You don't think it would add context and clarity if you took 20 minutes from
> those activities and devoted them to examining a specimen?

Sure. If I had to go through only a few CVs, maybe. And some times I do that
for the ones our recruiters screen. But tbh, looking at github/source code and
figuring out something (of value) out of it will be more than 20 min. Instead,
maybe a blog post or products portfolios would be way more useful and give me
something to ask for details on an actual interview.

> Do you do whiteboard interviews? I've never done one less than an hour, and
> I think you'd be able to glean quite a bit of the same information by
> looking through the log.

We do, and let me say that `git log` will absolutely not tell you the same
info. One is the final version of a thought process (the log). On an
interview, at least for me, the result is only one part of what I'm after. How
you get there is way more interesting to me, the questions you ask, etc.

~~~
ibejoeb
>Instead, maybe a blog post or products portfolios would be way more useful

Of course. That's why the author advocates for linking to a specific repo with
a readme.

>We do, and let me say that `git log` will absolutely not tell you the same
info >How you get there is way more interesting to me

I get a lot of value from the revision history. To me, that is how you get
there. When I see something, and I say, "I wish it was more like..." and a few
commits later it is, I know we jibe. Likewise, if it's good, and it's
something really novel and clean and clever and I never would have thought of
it, that's just gold.

------
cubano
For the last two or three contract jobs I have got, including my current one,
_just the fact I had a working github repos_ was enough to impress the hiring
guys.

In all three cases, I eventually trained everyone how to use git, so there is
that as well.

~~~
mgkimsal
> just the fact I had a working github repos was enough to impress the hiring
> guys.

as opposed to a non-working repo? do you mean the code in it "worked" or just
that you had repos up?

ANECDOTE TIME: I knew of a guy who was hired because his github profile page
showed a lot of stars. It didn't dawn on them until after he was hired that
those are things that _he_ starred, not stars received for his projects. He
had "a lot of repos". Cursory inspection showed all but 2 (of the 40+) were
forked. He was a horrible hire, and left after a few months, but the dept
manager who'd hired him (against input from some of the team) got uber-
defensive about any criticism (this person was in way over their head from a
tech and management standpoint) and... multiple people (surprisingly, anyone
who'd made any criticism of the 'mr github stars' profile) ended up getting
'reduced' (laid off) a couple months later.

------
Fire-Dragon-DoL
Are you sure about not linking directly to github? There is now the PIN
functionality which you can use to highlight up to 8 projects, even those
where you contributed but not directly own

------
yellowapple
Amusingly, my most recent job interview - which ain't even for a programming
job per se - did involve one of the interviewers having gone through my GitHub
profile. We only briefly discussed the contents thereof (he seemed to be
mildly interested in my involvement in an Elixir web framework), though we did
have a bit of an awkward moment when he mentioned finding
github.com/yellowapple/heroku-sucks (especially seeing as how the company uses
Heroku for its website).

All in all, it was pleasantly surprising to see an interviewer actually do
one's homework to the same level that I typically do mine.

------
motet_a
> There is one project structure to rule them all. There MUST be separate
> directories for source, test, libraries, compiled binaries, etc…

I don’t think so. Look at the Git sources
([https://github.com/git/git](https://github.com/git/git)). Most of the C
source files are in the top directory.

Some other people like to write unit test in the same directories as the
source files, by adding a `.test` suffix to each source file name.

Some other people like to embed unit tests in source files, “à la” Rust.

There is no One True rule. Not organizing things the way you do is not
necessarily bad.

------
guessmyname
What about NDAs and in-house projects?

I have contributed to many projects in the past years that are not publicly
available, not even as a product/service because they are, for example, DevOps
tools or improvements to servers or a development/management/sale process. My
GitHub account is mostly personal projects and nothing — except for a couple
of them — are used in production. It is very difficult to show your value as
an active contributor to open-source projects if your contributions cannot be
public.

~~~
thinkingemote
I think even more people will be affected by IP clauses in their work
contracts which state that any work they do even outside on their own time is
the property of the company they work for. many cannot do any open source work
at all. Some need to get explicit and lengthy approval from HR, managers etc.

in short, most in companies cannot easily build up a personal github profile.

~~~
VLM
The marketplace is too scattered to understand, seeing as its common knowledge
that most devs can't fizzbuzz on command, and also everyone knows all
interviews are piles of buzzwords surrounded by infinite whiteboard algo
discussions.

Given that disorder in the marketplace, you might be worried they're asking
for an entire tech startup, but they might be happy with little more than a
personal fizzbuzz hello-world analogy. If your employer were jerks enough to
demand ownership of your fizzbuzz-alike, you could write another in a day or
two.

Something more like a weekly homework assignment from school, and less like a
PHD thesis.

------
misingnoglic
The first piece of advice doesn't make sense to me. You can easily tell from
going to the root of my GitHub what projects I'm most proud of:
[https://github.com/misingnoglic](https://github.com/misingnoglic)

I will say I'm inclined to agree that probably no recruiters have ever
actually looked at my GitHub for more than 10 seconds though.

~~~
humanrebar
I've looked through GitHub code before, but it's hard to weight it too much
since not everyone can even have significant open source code in the first
place.

That being said, a particularly impressive project or a history of
contribution is a huge plus to me. It's a great way to add some credibility to
your claims of technical interest. Everyone says they're in to big data or ML,
but actually showing some (even throwaway) work in that area lets me know you
are active in your interests.

------
mnutt
Often when I see candidates' github accounts they are mostly forked repos with
no changes and projects with rails scaffolding. There might be something there
but it's really hard to dig through and find. I would suggest candidates build
their own projects using documented pull requests and point the hiring manager
to the closed PR page of their project. Or even better, point them to a
substantial PR they completed on someone else's open source project.

~~~
brobinson
Are you just looking at the master branch on their forks? If you want to send
a PR to another repo, you _must_ fork that repo.

I have 43 repos, but 21 of them are forks. I've never committed anything on
master on any of the forks, but I've created my own branches in order to open
PRs on 18 of them.

The easiest thing to do is use the "Sources" option from the drop down on
their repos page (shows only _their_ repos) and use something like
[https://showmyprs.com/](https://showmyprs.com/) to see their external
contributions.

------
Walkman
The last part is definitely not true at all. I skipped the coding part of the
interview process for my current job because I had good code on GitHub. Also
got job offers out of the blue because I contributed to multiple projects. I
feel there are companies looking at only GitHub (for a good reason IMO)
nowadays for candidates.

~~~
Sekhmet
I got my current job just with GitHub. I was asked to only show my GitHub
profile. I didn't need resume at all. Some companies might not care about your
GitHub, but they are always some that do.

------
z3t4
If you apply for a job, someone _might_ actually read your code! But most
people, especially your users, don't care if the program is written in C,
"brainfuck" or Java, they just want something that works and is easy to use.

------
conqrr
What about personal websites, portfolios etc? Do recruiters simply ignore
these too?

~~~
oddlyaromatic
I've sent my portfolio to recruiters as part of an introduction and had them
call a few times. I write maybe 4 sentences about how I think I fit the job
they posted, then a portfolio link and a phone number. I'm very early in the
job search and those conversations haven't gone anywhere, but at least I know
they look at the page and it's what they talk about when they call. But I have
only a small amount of data.

------
bigtoine123
"Nobody cares about your code" piece of advice doesn't make sense to me. There
are people who cares about your code, I had projects in GitHub I'm really
proud of

~~~
abelM
In general, I would look at it like this ... Your coding style is your opinion
and how you understand a program works. Until, I am required to understand it
or until you grab my attention, I or anyone won't care. It is nutting personal
but time constraints and also, we (developers) are the only ones who care
about code quality. If product needs to be built fast then code quality is
placed in the backlog.

