How to present a GitHub project for your resume (2016)(thehftguy.com)
thehftguy.com
How to present a GitHub project for your resume (2016)
https://thehftguy.com/2016/10/24/heres-how-to-make-a-good-github-project-for-your-resume/
88 comments
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.
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.
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.
Your anecdote coincides with my experience working directly with a certain semi-famous programmer for the past 5 years.
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.
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.
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.
And how can you get better at it?
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.
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 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.
I'm a little like that with programming. I used to have a similar, but more pronounced, problem with my native language (English). I could read and write way above my grade level, pretty much from as soon as I could read and write. I've seen college students who write worse than I did in 5th grade.
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.
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.
Obligatory Feynman https://www.youtube.com/watch?v=lr8sVailoLw&t=47
Sounds like you should have gotten to the 2nd round at least
Steve McConnell's Code Complete can help with the clean code part. Read it and jot down some notes.
I think I would ask a few questions about what exactly the questioner means, because "clean code" is a very vague term. If they're borrowing from Uncle Bob's book, then I'd have a pretty good idea.
"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?
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?
Here's a really simple project for this kind of stuff if anyone is stuck on ideas:
- 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.
- 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.
You jest, but it's clear you've not tried to make that product, as it is much harder than it sounds if you count "make it past their spam filter" as delivering email.
I've made that product. I've had 10 customers ask me for that product with a straight face. The spam filter isn't a concern if it's an intranet product -- at worst, it's a support call which leads to some instructions on the page. It still saves them from buying some amount of printer toner and using fax lines. Everything else there is true to some degree, which captures the spirit of writing resumes. (IMO the biggest concern is security but frameworks handle a lot of that out of the box)
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.
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.
"It still saves them"
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.
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.
That's why email service platforms are a thing. SendGrid, MailGun, and the like.
> 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?
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.
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.
> 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?
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.
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.
Yes. That's why data structures and algorithms are front-and-center at these interviews. They don't actually care about engineering ability. It's all about ego, trivia, and who can fart out product faster.
They care about the money the code/product generate. If it doesn't generate money nobody cares how good it is, when it generates money them you can care about good code and improving things.
People care about the problems you solve. So if your GitHub seems to represent a well executed solution to a real problem then probably people often aren't going to read into your code. I've seen plenty of repo's that I actually use that scare me to death when I dive into them. But so many people actually use it that still most bugs have been ironed out. Often it's more about being the first to solve a problem that many people have, the perseverance to really finish it, polish the README, respond to people with questions and suggestions and the ability to get those people to know about it.
Yeah. Code is the product.
It's like saying, "we don't sell ingredients, we sell meals".
It's like saying, "we don't sell ingredients, we sell meals".
...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.
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.
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.
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.
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.
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.
Fast food ingredients are highly tuned and customized products -- they're just not optimized for traditional notions of quality or nutrition.
Code is not the product. Code is part of the assembly line that becomes the product. An innefficient/bad quality assembly process will result in a sub-par product.
Developers don't build the product, they build the assembly line.
So not really, right? Code is just symbols on a screen.
It's the abstractions that count.
It's the abstractions that count.
Code is how we realize abstractions. They complement each other. The point is that the code is a key part of the product, so saying it's an afterthought is to misunderstand the product.
I think the context matters here. The underlying point is not to be taken so literally. It means don't prematurely optimize your code until you have a functional, enjoyable piece of software. Then sure, work on maintainability and improved performance.
I can't be absolutely sure but I think my code and online participation (totally unrelated, not even same programming language, domain, etc.) helped me in the end.
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.
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.
Here's my solution: 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.
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.
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.
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.
Thanks. I was thinking about that but really enjoy not requiring JavaScript, however maybe its worth it. I'll try it out
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.
I've just been using this: https://shields.io/
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.
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 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.
> 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.
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
[EDIT] tense agreement fix. [EDIT2] misplaced apostrophe
> 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.
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.
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.
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
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
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.
[deleted]
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 JS in my country according to http://git-awards.com/.
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/.
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.
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 )
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 )
> 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.
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.
>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.
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.
> 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.
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.
>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.
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.
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.
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.
I can see how it wouldn't be relevant if you do a lot of hiring.
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 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.
> Noone cares about GitHub.
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!
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!
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.
In all three cases, I eventually trained everyone how to use git, so there is that as well.
> 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.
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.
Yeah, here in the slums of higher-ed dev/IT just having a github repos of any original code makes an applicant novel. We never really discussed an applicant's github code with them, but we absolutely read through and took it as a very positive hiring signal.
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.
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.
I'd guess you also got a good smirk out of this part of TFA:
> GitHub has a rich ecosystem of free tools for building, packaging, testing and much more. All these tools are mandatory for professional software development.
> GitHub has a rich ecosystem of free tools for building, packaging, testing and much more. All these tools are mandatory for professional software development.
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
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.
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.
> 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). 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 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.
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.
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.
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.
in short, most in companies cannot easily build up a personal github profile.
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.
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.
Not to be rude, but why do you think that contributions to in-house/closed-source projects should count as contributions to open source? By definition, if you contribute to an open source project, you should be able to point to the public code you wrote. What you're describing is basically previous work experience (which is already on your resume).
I am talking about contributions to open-source projects under the name of the employer. I have signed NDAs with clauses that state that as an employer I am responsible for the maintenance of the internal systems including the bug fixes to whatever project the system depends on, but later there are clauses that prevent me from identifying myself as an individual contributor to these open-source projects, I have to use a company-provided account.
Was a justification given for this? The company doesn't seem to be gaining from keeping the identity of the contributors secret (if they wanted to mask the fact that they were using a particular piece of OSS I could kind-of understand that -- but doesn't seem to be the case here). Is it really as spiteful as "we don't want you to gain personal credit for work we're paying for"?
I can only speculate about the justification for these clauses. The contract was written by a group of 3rd-party lawyers who had little to none knowledge about the open-source community. My only guess is that they wanted the contributions to be tied to the company's name to increase their visibility, as in — "We [the company] contribute to X project(s); love us!" — putting myself in the shows of these lawyers, if an employee leaves, their contributions will stop being tied to the company and they will lose some visibility, that is the only reason I can think of right now. Your guess about "we pay you; credit is for us" also makes sense, they are the company's lawyers after all, they are not working to protect my rights but the company, so I didn't think too much about it when I signed, later I regretted my decision and quit.
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
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.
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.
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.
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.
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.
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/ to see their external contributions.
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.
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.
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.
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.
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.
"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
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.
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