How to present a GitHub project for your resume (2016)
thehftguy.com
thehftguy.com
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 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
I fixed their github pages page (previously wouldn't load stats & projects) 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
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.
He's very charismatic and a great speaker, and he has a successful business selling his experienced expertise and advice.
But having pair-programmed with him many many times during that time, I was surprised by his inability to discuss real-world coding problems and their potential solutions beyond more than a superficial level.
What I took from that experience is just what you said: there seems to be an inverse correlation. I could produce code that solved complex problems thoroughly and bug-free, and he could talk about them in an abstract way, but neither of us could do the other part.
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.
I could tell you when a sentence had a problem and how to fix it. What I couldn't do was tell you why something was wrong in the language of talking-about-language. Basic parts of speech, sure. Past that I was lost. It took learning a fair bit of French in a formal setting to get that stuff to stick. I think the problem was that I didn't need those words to think about my native language[1]. It just happened for me. Learning a foreign language made it easy to pick up the vocabulary, because I actually needed it to talk about what was going on.
Point being that maybe there's a way to pick up some of the lingo by finding a way to need it. Maybe learn a radically different programming language from what you're used to.
On the other hand I find that even a not-especially-deep understanding of how things actually work makes some of these named concepts and patterns look like really obvious and not-needing-their-own-words cases of some more fundamental thing, so if it's that giving you trouble then I'm not sure what to do about that or how to make you need those words enough to learn them. Some significant percentage of the time I end up re-casting "complex" ideas as an implementation/combination of some simpler or more fundamental thing(s) I already know, which turns out to be an exact match for how the thing actually works and leaves me wondering entirely WTF all the fuss is about, and usually thinking I don't actually understand it long after I in fact do because everyone writing/talking about it is using mysterious, magical language. Being able to communicate with people who prefer to... I don't know, come at problems from the other direction I guess, is a problem I continue to have.
[1] N.b. I would eventually have needed them to develop further, and I picked up some really bad habits in high school that harmed the quality of my writing but helped me make mandatory page counts so I definitely had room to improve.
[EDIT] embarrassing farther/further error. The finer points of usage remain a struggle.
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?
- Make a website that accepts some form values
- After submitted, send an email to someone
Congratulations, you now have an exciting SaaS solution built with love using modern web technologies that can be hosted on any cloud provider or on-prem infrastructure and scales extremely well for businesses and companies which can save them thousands of dollars and reduce printing and faxing overhead.
If you're having some trouble, try to get a 4 year CS degree and several internships.
And that's still not the point -- the point is that a Github profile may becoming a checkbox for the hiring filter that few scrutinizes. They are using weak hiring signals and I will absolutely punish them by bypassing it with as little effort as possible for not doing their homework while making me jump through interviewing hoops.
I've done the same, its a classic corporate warfare tactic, there exists an agreed on paper form to standardize the demarcation point between two warring internal groups (and all internal groups are at war because of stack ranked management reviews, formal or otherwise...), someone on the home team was manual data entering that paper form into "something" now you can push that labor cost onto the other side who now do the manual data entry for the home team. For bonus points toss each data entry into a database and provide some manner of weekly reporting via web or email cron job, maybe some dynamic error checking at data entry time. Classic weapon of internal politics. I've made a lot of money off this, historically.
There's a whole universe of MBA companies out there that see computers abstractly as mere fancy electric typewriters, merely a modern Linotype machine, its just a modern mimeograph nothing more, a way to format manual data entry for other humans to read and manually data enter in something else. Computers that don't compute or have flowcharts, merely manual human I/O devices. Adding the slightest bit of automation can blow the minds of business people.
Beware of the inner product effect. A simple web form that emails the ticketing system in restricted cases can eliminate enormous amounts of manual data re-entry if it happens enough, but trying to turn it into a generalized tool will merely result in a "simple web form" that becomes more complicated than the ticketing system everyone was avoiding because it was too complicated for end users. Don't write a feature complete 100% wrapper for JIRA with the expectation it'll be simpler, thats not going to turn out well. Of course in corporate warfare sometimes punishing the other internal department is more important than making things simpler and faster for all, and if it gets your team out of the data entry task and puts them on the data entry task, well, the guy on your team who signs your paychecks is going to be happy with you.
My experience says yes. The people hiring programmers usually have no ability to validate a programmer's skill. The only thing they care about is a working application that solves a business problem.
The bulk of code I come across as a consultant is "sloppy and full of technical debt". There are various reasons for it, not all of them reflect on the programmer.
The result is the only thing the customer and upper management sees. Doesn't matter if it will explode in a few months at best, right then and there it generates revenue and visibility.
It's like saying, "we don't sell ingredients, we sell meals".
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.
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.
It's tasty alright... Just don't expect to wake up feeling great the next morning.
Fast food ingredients are highly tuned and customized products -- they're just not optimized for traditional notions of quality or nutrition.
It's the abstractions that count.
It shows I have MY (as opposed to 'uni forced me') foot in the door and proves (along with a certificate) that I know English really well.
There are many people who just coast through their CS degree on medium grades but still have basic problems with git, bash, English, etc.
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.
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.
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.
I'd like to see people using the appropriate tools for the task at hand. I can imagine slapping my head and asking "Why the hell didn't they just use x". I wouldn't want to pay someone to reinvent the wheel and I'd want someone to demonstrate both their awareness of and their ability to evaluate appropriate code from the relevant ecosystem.
[EDIT] tense agreement fix. [EDIT2] misplaced apostrophe
Actually no, Docker is not a good idea for an instruction on how to run the code. First, if I don't use Docker, I have no fsckin' way to tell which magical --switches are for Docker and which are for the program. Second, if your program cannot be easily run without Docker, you have vastly overcomplicated the whole thing.
If you don't have any such dependencies (great!), your build environment's really simple, and you're confident the build's reproducible on my machine without containerizing it then don't do that, hence the "if relevant". If you can leave it running on Heroku or something instead that's fine, but documentation-wise the #1 thing I usually want to see, aside from WTF it's for, is a set of instructions (it can be "run 'make && make install'", that's fine, but tell me) for how to build & run the project that actually work if I follow them. That includes programs that run server-side, the authors of which seem to be the worst about not providing such instructions. Even if I don't try it out, seeing credible-looking well-written directions for those most basic of interactions with your project is comforting and will be among the first things I look for.
TL;DR the point is your README should prominently contain answers to the questions "how do I build this?" and "how do I run this?" and you should make the answers as painless and easy to undo as possible.
[EDIT] and yeah, my fault for not making that TL;DR the entire original statement and avoiding discussion of the not-that-important particulars entirely.
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
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/.
Not sure why someone with a similar repo, high quality with lots of stars, would not include it in their resume.
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 )
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.
It's funny I used to get interview-offers from people who'd seen some of my C++ code, despite the fact that I'm not really a developer.
Shortly after that I moved the project into a Github organization, just for neatness, and those emails stopped. It's like people searching for C++ code don't see "me" any more, just the faux organization-owner.
I'm a little amused that people are emailing random github developers with enticing offers of interviews, yet can't handle the extra layer of indirection. But anything that cuts down on random spam (No I don't want to relocate to America, thanks) is probably a good thing!
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.
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.
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.
Sounds good to me. I think we run the risk of training people not to publish, but that's why I like the author's advice to highlight one particular repo that is a showcase for how the individual works.
In my case however, I hire maybe 3-4 devs each year and would definitely spend time looking at candidates' github repos... if any of the CV I got ever actually mentioned any!
For me at least, the more filtering I can do before interviewing, the better. A GitHub repo would also be a great discussion point during interviews.
In all three cases, I eventually trained everyone how to use git, so there is that as well.
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.
You don't have to have a huge contribution history or a project with a ton of stars, just having something out there matters to some places.
> GitHub has a rich ecosystem of free tools for building, packaging, testing and much more. All these tools are mandatory for professional software development.
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.
I don’t think so. Look at the Git sources (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.
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.
in short, most in companies cannot easily build up a personal github profile.
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.
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.
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.
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/ to see their external contributions.