Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to present a GitHub project for your resume (2016)

thehftguy.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: How to present a GitHub project for your resume (2016)

#81

Post by mhurwi »

franciscop wrote: post #7

I have a quite "complete" github ( 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…

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.

Re: How to present a GitHub project for your resume (2016)

#82

Post by oddlyaromatic »

conqrr wrote: post #68

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

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.

Re: How to present a GitHub project for your resume (2016)

#83

Post by ashark »

dozzie wrote: post #79
ashark wrote: post #9

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 li…

> 1) Tell me how to run it locally (docker is a good idea, if relevant) [...] 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.

It's a hell of a lot better than telling me to install and configure any service dependencies you have (databases, say) outside a container. 'Cuz I'm definitely not going to crap up my system doing that. I'm also not likely to install an entire development environment I don't otherwise need just to run your thing. Just make it a "docker-compose up" for me to install all that junk, or something similarly clean and easy, or it won't happen. Bonus: much higher likelihood that it won't break due to some local environment issue you didn't account for, so lower chance of having your beautiful program fall on its face right out of the gate. Use Vagrant I guess (is that still a thing?) if you're worried about the reviewers not having/wanting Docker or similar, though it's a bigger PITA to configure than Docker and usually takes longer to start up. The point is the concept (keeping your build/run env from crapping up my system in any way that requires me to run more than one or two really easy to discover commands to entirely undo, and ensuring your build/program can run in as many plausible environments as possible without stumbling) not the specific tech.

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.

Re: How to present a GitHub project for your resume (2016)

#84

Post by ashark »

andybak wrote: post #76
ashark wrote: post #9

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 li…

> Don't use a framework. 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.

It's easy to address that in a readme. "This is a showcase of my craft, for which reason I avoid using frameworks or anything else that would obscure my work with boilerplate or autogenerated code, or anything that's not really mine, though I do rely on others' libraries when it makes sense as those complement and clarify rather than obscure my code. If you just want to see a TODO app I wrote in Rails with a bunch of 3rd party auth via Devise and a Firebase backend and like 100 lines of code that I actually wrote myself, click HERE"

[EDIT] tense agreement fix. [EDIT2] misplaced apostrophe

Re: How to present a GitHub project for your resume (2016)

#85

Post by lgas »

dpritchett wrote: post #72
ashark wrote: post #9

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 li…

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.

Sounds like you dodged a bullet.

Re: How to present a GitHub project for your resume (2016)

#86

Post by quesera »

oliv__ wrote: post #78
humanrebar wrote: post #74

Earlier quoted context omitted.

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 pizza…

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.

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.

Re: How to present a GitHub project for your resume (2016)

#87

Post by franciscop »

mhurwi wrote: post #81
franciscop wrote: post #7

I have a quite "complete" github ( 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…

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.

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 )

Re: How to present a GitHub project for your resume (2016)

#88

Post by ibejoeb »

funkaster wrote: post #67
ibejoeb wrote: post #55

Earlier quoted context omitted.

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

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

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

Re: How to present a GitHub project for your resume (2016)

#89

Post by ibejoeb »

concede_pluto wrote: post #71
ibejoeb wrote: post #55

Earlier quoted context omitted.

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

If your published code is bad I can quickly learn whether I'm wasting my time, but if it's good I still need to see you code in person. Neither GitHub nor homework proves you did the work.

>If your published code is bad I can quickly learn whether I'm wasting my time

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.

Post reply on HN