The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly.
All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored.
If all this person is evaluating me on is my Github, they'll think that I've never advanced beyond an amateur level despite my having over a decade of experience in the industry... all because I treat my open source work as a hobby rather than as a second job.
You can do that or you could also put a readme on your GitHub that it's a place where you explore hobby projects and you are interested in "x, y, and z".
When I go to a GitHub as a hiring manager, I try to get as much signal as I can. You are scared that I'll solely judge you on the code, but I'm looking for metadata. Is this person interested in or exploring problems/technologies that are related to the problems/technologies we are using here? Oh, They are exclusively doing music based coding? INTERESTING. Let's talk about that in the interview.
Oh, They've contributed a bug report to an open source project, lemme see what that looks like. Nice, repro steps are clear.
And yes, some hiring managers are gonna say "welp, this candidate isn't an open source ninja so we don't want them." But that's not all hiring managers.
What is a big turn off for me personally is the "I'm gonna slap something on github to tick the box" group. I had someone submit a resume with a link to their website and a link to their github. The website was literally just a demo site, but they had changed all of the blog titles so it looked like real posts, but if you clicked through, it was all lorem ipsum. The GitHub was also just the code for this site.
I'll take a graveyard of personal exploration everyday over a half-baked sham site. (Note: They could have just been playing around BUT TELL ME THAT! Because it sure looked like an attempt to look the part.)
> ” And yes, some hiring managers are gonna say "welp, this candidate isn't an open source ninja so we don't want them." But that's not all hiring managers.”
So probably is good risk management to not include your GitHub ever when applying.
This depends on how many options you have. If you have many options it can be a good thing to filter out companies that would not be a good match for you.
As a general rule of thumb, if you don't want to be evaluated at least in part based on something, don't put it on your resume.
(and the inverse holds as well: if you do want to be evaluated at least in part based on something, consider putting it on your resume).
Still, I'd be pretty irritated to learn that someone decided not to even talk to me because I included a github link to some toy project that they didn't like.
Not bitter at all, not sure where you got that impression from my post. If I have something that does not present me in my best light, why should I volunteer to show it in a hiring process? I am just being practical.
I do think all hiring processes have a component of arbitrariness, so I don’t think it is necessarily a bad sign that a company quickly dismiss candidates from poorly-maintained GitHub accounts. I would gladly not show my GitHub and try to get the job showing my skills in some other way.
There are risks either way, and this is one of those processes where you just want a single good hit. So I guess the optimal course here is to maximize your risks (unless they are biased into not-hire), not to minimize them.
There are other processes where you must never fail. For those you want to minimize risks. If you want a job at X and nowhere else, this is your situation. But that's not very common.
What’s more common - hiring managers who see the inclusion of a GitHub as a small positive signal but don’t scrutinize heavily (or even more likely don’t bother to click into it), or those that dig deep and scrutinize open source contributions as a primary decision factor?
I've seen applicants with lots of Github repos, which all turn out to be forks, and all the applicant did was make a trivial change to the documentation (not fixing a technical error or expanding the comprehensiveness, but adding periods at the end of list items, capitalizing some proper noun that got missed, etc.)
It seems pretty clear that the Github link in resumes has been cargo-culted for several years now.
Yeah, honestly seeing someone add a big chunk of fresh, useful information to a project's documentation would be even better than seeing code go in, because most people hate doing docs! Unfortunately what I've seen is absolute lowest-level "get a commit into the tree" stuff.
I didn't know why people fork repos arbitrarily on their GitHub. I thought they were doing that unnecessarily before cloning or something. So this is the reason?
No. The reason is because when I and others investigate some code we like to make small refactorings as we go along. Change a variable name here, redefine a type here, and see what breaks. If you think those changes could ever be pushed upstream you save them in a github repo. That it looks "random" to hiring managers is something I've never thought of.
We are talking about different repos then. The ones I am talking about have no commits or refactoring going on, usually they are even with upstream or some commits behind. I was puzzled why they were forking these repos while a git clone will perfectly do.
Quite often people will fork so they can tinker locally. It's not odd to see forked repos without any changes, it's just someone being curious or wanting to make a contribution but not having time to go through with it.
I'm sure it's not the only reason. Maybe some people fork repos they depend on just in case the original owner decides to take theirs offline, etc.
But if someone lists their Github on a resume, and then the whole account is just full of do-nothing forks and no original work, I'm going to be a little suspicious.
I could show you, but my github account is not representative of my actual interests. That is precisely what resumes and motivation letters are for.
If recruiters start looking only at github accounts, dishonest job seekers will quickly learn to create fake github accounts, just as they present fake resumes now.
I’ve been interviewing candidates for ~5y across two companies and have yet to see a motivational letter. And most the resumes I see are either overly verbose and don’t tell me what you actually did, or are simply a soup of buzzwords.
A few of the most successful and memorable hires I was a part of have real github accounts with something more than a bunch of forks or fancy profile readme.
In my opinion, it doesn’t matter if the content isn’t representative of what you want to do at work. Seeing that you’re curious and interested in building things, trying weird experiments, and so on is a strong data point in and of it’s self.
Here’s a similar example from an unrelated field: there’s a handyman that lives down the street from me. His humble home is neatly manicured and I often see him outside in the morning, dressed for the job and working on projects. Observing the pride he takes in his craft was a signal to me that he probably does good work. And after hiring him for a small project, my hunch was correct.
Your example is excellent. I agree with you in that choosing a developer in basis to a github profile is not much different from choosing a handyman in basis to what he does in his garden on the mornings. What if there was a much cheaper and more efficient handyman living up the street, but he always works in his backyard so you have never seen him outside?
I am sure you can find valid candidates with your method, but also that you could be missing much better ones.
This was also my reaction, the way I write code when I have a 20 minutes of free time after work is really different from the way I write code for production. The author is lying to themselves if they think that most people Github projects are any more representative of the work they'll do once hired than their resume is.
I think looking at the Github of applicants is useful as a conversation starter however: "Oh I see you've built X with Y, what was interesting about that? What did you learn?"
I agree with the conversation starter part, but I think there's still something to be said for seeing how someone's code looks when they're writing it not-for-production.
Like does that just mean overly long functions? Lazy symbol naming? Linter violations? Lack of tests? Those might all be reasonable through the "not prod" lens, but there's other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used, or using obviously non-idiomatic structures like an indexed loop in Python.
None of this should be a deal breaker, but if you're seeing stuff that's obviously like "I would be annoyed to be reviewing this code" then it's worth talking about.
> other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used
One of the reasons why I enjoy programming as a hobby and avoid it as a profession is the pleasure of reinventing the wheel. For example: I learnt how to use git and am learning how to read datasheets is by taking simple Arduino programs then refining it until most of the abstractions are removed. Likewise, it can be fun to implement my own data structures and algorithms. Contrast that to simply using libraries. It's mostly an exercise of reading documentation and hoping that a tiny subset of what's learnt is transferable to other libraries.
Okay, understandable. I do feel there's a pretty big difference between doing something a bit different for the sake of preference or taste or experimentation vs doing it because you just didn't know, or you don't have the familiarity with the ecosystem to even know what's out there. And this difference is usually fairly evident in the code itself.
If nothing else, again, it's an opportunity for a conversation— the person might have a great war story about how they deep-dived on library X after finding it lacking, or tried to submit a PR that was shot down. Or even if they had no idea, it's an opportunity for them to demonstrate teachability, like "oh that looks nifty, yes I can definitely see how that would make this whole section redundant and the rest easier to read."
As an early career developer, your team wants you to write useful code with few errors and that works best when you can rely on established libraries.
But as your career progresses, your value comes from understanding how those libraries work and from being capable of writing new libraries that support and stabilize the early career developers coming up behind you.
And the only way to go from the first group to the second is from getting your hands dirty. Writing personal and hobby projects that “reinvent the wheel” is one of the best ways to do that.
One of the nice things about open source, and modern development tools, is the ability to easily go beyond the documentation to explore the library code itself. While I wouldn't consider that as a substitute for implementing your own, it is another means of figuring out how a library works and can be seen as more results oriented. Yet it is nowhere near as interesting, in my opinion.
Imagine you’re hiring a structural engineer to work as part of a highly skilled team on a skyscraper project. They previously worked on a bunch of major building projects around the world.
What you’re going to do, though, is ask them to let you have a look round the treehouse they built on weekends in their backyard.
After all, the choices of materials and techniques they use there in that ‘not for production’ context probably tell you a lot about how they approach their work, right?
Sure. But not because you're expecting the treehouse to be at the caliber of a major building project. Rather because it's an opportunity to witness:
- What their work looks like when they're solely in charge of it and it's not a massive, long-lived team effort.
- Obvious flaws that shouldn't be acceptable to anyone. Like, loose boards, nails sticking out, a fence that's not supported and may collapse if a kid leans on it wrong.
Neither of these things are the entirety of the evaluation, but IMO they're a relevant signal to use in combination with talking through past professional projects, particularly if the professional projects aren't visible or known to the interviewer.
So you're saying that, if skyscraper engineering designs were considered confidential and proprietary, preventing you from being able to directly investigate them, it would be perfectly reasonable to fall back to evaluating structural engineers for skyscraper projects on the basis of how well they put together treehouses?
I thought that the commenters who were sheepish about including their GH repo were being unreasonable until I read this comment. I could not disagree more about the purposes of side projects. In fact, if "reinventing the wheel where a well known library could have been used" is a deal breaker for people _in a side project_, I must be one of the least hire-able people on earth.
I love breaking things down to understand them. Rewriting them (sometimes better!) to get a feel for what is involved. I think it makes me a better programmer. It saddens me to hear that this is an undesirable quality in seeking engineering candidates, for some.
I like re-implementing things too! But usually there's a pretty clear difference between "I'm doing this deliberately differently from established-solution X for reasons Y and Z" vs "I'm doing an unrelated task and am using urllib because I'm blindly copying in SO solutions from ten years ago and have never heard of Requests." This kind of thing is the fizzbuzz of ecosystem-awareness.
For an example from my own code— I was learning Rust via AoC a few years ago, and I deliberately chose to do some of the challenges with natural language inputs using Pest rather than just dumb regexes [1]. The regex solution would have almost certainly been shorter and quicker for this limited task, but I would have no trouble justifying this design choice to an interviewer as having been an intentional learning experience.
The thing is, reasons Y and Z for me very often are "because I want to". I don't even really want to fluff it up and call it something nauseating like "professional growth". I just followed my curiosity. My personal projects are a safe space from stiff professional judgement (or at least were).
You're my favourite kind of employee/colleague. Someone who knows something about what they're doing because they took it apart and put it back together.
> like the person reinventing the wheel where a well known library could have been used
This is a particularly shitty signal to my mind. Half the reason to experiment with writing software outside of work is to reinvent the wheel and see what shakes out - you'll almost never have the opportunity to do that at work, and if nobody ever does that, we never discover better ways of developing software.
I think it's a difference between: "reinventing the wheel because I didn't know better", and "reinventing the wheel because I feel like trying to make it better". There's usually a distinct difference in how the code shakes out between the two.
Overly long function names and lazy symbols, fair enough. Linter violations, Im not sure sure, standardised code style is most important when working in a team, working on your own it doesnt really matter as much, but fine. Lack of tests, theres no way I'm writing tests for a fun weekend project not meant for production. I'm not even sure I'd write tests for any project not meant for production or anyone elses uses (obviously what production is in that context differs, if your writing a library for dev tooling, their dev is your production).
As for "reinventing the wheel", this overuse and overdependence on hundreds of libraries is how we as an industry keep running into the same old issues, so I'd quite happily reinvent the wheel for production. I'm not adverse to libraries, but they shouldnt be approached as a first resort.
> I'm not even sure I'd write tests for any project not meant for production or anyone else's use
See that's interesting— I'm far from a testing-absolutist, and I agree with the basic premise here that there's no point having an elaborate "testing" strategy for a one-off script, stuff that isn't very branchy, etc.
However, there's also some stuff that I basically always write a trivial unit test for, assuming the language is set up to allow me to do so cheaply. Obvious examples of this include any kind of string processing, parsing, or regex-type logic— I'm just like, this looks fragile, and I'd like to know for me that it does what I think it does and I'm not going to be tripped up later by some subtle bug that boiled down to an edge case in this particular piece of trivially-isolated and testable logic.
Yeh, that makes sense, I just doubt I'd even think to add unit tests for a quick and done project. Even if it did cross my mind, I think I'd just add exceptions and print statements. Its dirty, but its also very quick and painless.
Then again, I haven't used unit tests much at all in any language other than Python (maybe a few others, but not for some time certainly), maybe other languages make it much easier.
> there's other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used
I wouldn't call not using a well known library "reinventing the wheel". The wheel in that expression is a concept, not a implementation. A library is an implementation of a concept. Writing yourself code instead of using a library is a great way to learn about what that library does and the tradeoffs it makes.
> Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.
Your comment is a great reason for me not to share my Github profile.
I'm not going to treat my Github project defensively. The notion that most people need to worry about what they put in their README because some interviewer is going to look at it - it's just so much better not to let them see your Github profile.
The irony with this article is that it's proposing a solution to a problem - yet that solution is as problematic. A resume is a poor indicator of one's skills, as is their Github profile.
> And what if I’m not tracking that in such detail or even thinking about viewing it like that because it’s a side project?
Make it private like you are doing?
If you don't want someone to perceive something about you, then don't make it public. If you do make it public and add it to a resume then don't be surprised if the person who manages programmers is interested in possibly looking at the programming that person has done.
I proposed that you can tinker in public if you make sure your tinkering won't be confused for your magnum opus. You dismissed that because a one sentence readme isn't needed on a public side project.
I didn’t say anything about adding a link to a resume. This thread has hints of people thinking “I’ll just look up their GitHub if they don’t include it” and other threads make that explicit.
> You dismissed that because a one sentence readme isn't needed on a public side project.
I don’t think that’s what I said. I was saying that tracking all the things one might be judged for is unreasonable, not that having a readme is unreasonable.
Why should I have to defend the imperfections of what I do for fun? I wasn't getting paid to make it good.
It's a personal project. I do it for fun. I didn't write tests because it wasn't fun. I cut corners to get to the fun part faster. I made breaking changes because the one single user accepted them.
I don't even code professionally any more, but when I gin up some code to solve a problem for myself in 20 minutes, I'll definitely try to clean it up before I throw it up on GitHub. I don't get any competitive advantage or economic benefit from my code, so maybe it's different for me, but if somebody finds my stuff and wants to use it, I feel like it's basic courtesy to not hand them something I vomited onto the internet.
If you just want an offsite backup for your noodling around, make it a private repo; the contributor limit won't be a problem. If you're putting it out for the world to see, take the time to comment it, put a little polish on it, a decent README, and a license. If nothing else you'll be starting from a place of sanity if you ever have to revisit the code.
I don't view GitHub as a place to show off your code, or a place to find new code, or whatever. It's where my code is stored. I trust what's on GitHub more than I trust what's on any server, or any laptop, or running on my dev environment right now. As such, the idea of "cleaning it up" before putting it on GitHub seems backward. Code gets committed as soon as it's written, and if it gets cleaned up that history gets saved too. If somebody wants to pull my shitcode down that doesn't even have a readme, that's on them.
On a personal project there is no accountability. The developer didn’t have to understand what someone else wanted and try to figure out how to make it real. They set their own goalposts and had freedom to move them at will. You have no idea what their ambition was.
Adam Savage had some interesting insights relevant to this in the context of evaluating model makers and artists for special FX work. While portfolio pieces showing their own concepts or creations might show off heir basic craft skills, it doesn’t show that they can create something to fulfill someone else’s vision - and that is the job. So what you want are portfolio pieces where they have drawn or built something recognizable - a replica or a scale model or portrait or something. Because that shows they can direct their skill to a particular goal. You know what they were trying to go for, and you can tell whether or not they nailed it.
Mostly I’m hiring for developers to work in a large team, within a large organization. What they can accomplish when left to their own devices is scarcely relevant to what they will be able to do in that work environment.
> They are, that's the moment you see how the person code when she/he is responsible
There is no responsibility in small side projects. I write better code during my day job because I know other people will eventually have to interact with it.
If you don't have much to show on your GitHub profile, simply do not provide the URL. It's just one data points among others, but it's true that it's useful to see the candidate's coding skills in advance and the easiest for that is open source code (since anything else probably can't be shared).
+1. Additionally, in general, I personally prefer to keep work and leisure separate. Things that I bring to the awareness of potential / future employers are selected and curated, and distinct from places where I keep the half-baked stuff I do for fun for my own consumption.
It's certainly possible to get from my real name to my leisure activities and vice versa with a concerted effort, but the first page or two of a casual Google search won't do it.
That's what pinned repositories are for. It's your opportunity to highlight the projects you're actually proud of. Any half-reasonable prospective employer will look at those first, and probably only those.
And again, if you have nothing worth pinning, there's always the option to leave it off your resume.
> All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored.
This is my Github too; part of me thinks I should finally arse myself, remove unused repos, and build a portfolio with some example projects of how I build software (hopefully allowing me to skip a technical interview assignment), and maybe build some libraries for various purposes. Doesn't have to be anything unique.
I mean my CV is impressive (according to recruiters / employers), but it's a high level overview of projects I've been involved in, it doesn't really boil down to my individual achievements because projects are generally team efforts.
I do believe this is the danger of judging someone by CV alone though; just because they were a part of a project, doesn't mean they were big contributors to it. I've seen plenty of people who do one small commit per week and call it a day. There's always the one team member who gets carried by the rest of the team, just like in school. (childish as it might be, I do believe managers should review individual team members' contributions and to let people go if they're only along for the ride.)
This is a very common problem and I solved it in a very simple way: one account for playing, experimenting, testing and enjoying, and another for showing off. This is not fundamentally different to how people treat HN accounts.
Why should some specific people (employers, recruiters in this case) should have a relevant authority as to pretense what a GitHub is supposed to be for.
If someone's GitHub profile is a mess, mixing experiments, serious work, goofy stuff, etc. as a result of their multiple uses of it (it's a _tool_ per se), that's up to them and it's up to no one to say "well, that doesn't look very professional to me, does it? your worth doesn't look great here".
If you put the link on the CV, sure, you just assume that it may be relevant to your profile.
But that's not necessarily a portfolio per se (something _really_ curated for that purpose, which is something specific). If it says so on the GitHub profile page "Portfolio", so be it.
And the recruiter is perfectly fine looking at it, but only for what it is.
What I'm rather aware of, is the pressure/mandate for everyone in the industry to showcase themselves, while that's not a relevant proxy for their fit to this or any job posting.
Sure there are people in the industry making themselves visible through github, twitter and whatnot, and some of these are also excellent. But that's only a tiny piece of the crowd that's available for hire.
As an employer that does the same thing as the person who wrote the article; I do, of course, look at the seriousness of whatever is on that Github profile.
I am usually easily able to tell if it is a half-baked project for some hobby-thing or active participation in e.g. a well known piece of open source software.
Someone who does this, is likely also skilled enough to separate those things. I don't only look at the user's own repos but also at contributions/comments etc. to others.
And just as the author, I too experience more often than not that people have NO idea how to set the level for own experience.
Could you list some things that are red/green flags when perusing someone's public code/projects?
I'm preparing to publicly release a project with the intent of building it up to demonstrate my own experience level.
I'm asking as someone with next to no prior public code despite developping back-end almost full time since I dropped out 10ish years ago.
I guess I'm asking for external criteria for whether I'm impostor-syndroming!
Just a few things I usually notice when going through a potential hire's GitHub:
1) All projects have a bad commit history. Just one commit and that's it. Usually it's something for school with really basic stuff inside. Most might be IDE provided "generate code" boilerplate.
Even a single commit beyond the GitHub provided initial commit example is enough. Multiple ones in a sane cycle is even better. Even if you just update some comments.
2) Does the project run? If I check out the project, is there a clear way to run it or does it rely on the compile & run commands being on the submitter's bash history?
Add a make/magefile or run.sh or anything.
3) README. Does it exist? GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.
4) Bonus task: does the repo have integrations or GH Actions enabled? If the project automatically runs some tests or builds on commit, it's a big green flag for me. If I'm going to be paying you over 100€/hour, I don't want you spending your time doing stuff manually if it can be automated with 15 minutes of boilerplate work.
> GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.
This is a strange one, I am not sure why the priorities of a third party hosting platform should take priority. Many people use it is more of a cloud repo backup than a social sharing site.
So why knock people for using it differently? It does not measure their understanding of how Github works.
That's a good point, but it does raise the question of how best to transmit notes or information with anyone who stumbles on the repo.
I understand these platform-specific features to be a way to show you do your homework and can integrate third party tooling or workflows into your own things.
Adding a README.md isn't just GitHub specific, it's a good idea to add it to any project you do.
My memory sucks, that's why I write down what I'm planning to do with a project into the readme. It doesn't need to be super fancy with images and status badges and all that jazz.
This is perfectly enough:
projectname
===========
This fizzes
TODO
----
Add buzzing later
Check if bazzing library is ready for production
However, I strongly associate Readme.md, designed for a web based intro view with Github.
It would be interesting to get the real history, because it could be a fluke of timing.
I’d bet if we look back at old source forge projects created pre-github there would be a strong correlation with the markdown version added and the rise of github.
(Of course this could be a timing fluke)
> README. Does it exist? GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works.
Yes GitHub pushes you really hard to add one. But I disagree that not having one on a personal project means you don't understand how GitHub works. I don't need (or really even want) a README for a personal project. It detracts from writing code. If I neglect the personal project for months or years and come back to it then I'm not going to give a flying crap about the README anyway: I will have come back to it specifically to look at the code. Whether that's because I had a new/better idea or wanted to reminisce or maybe to copy/paste some idea from it.
Your points make sense and they're on The Checklist, thanks! I probably won't sweat CI/CD integration for the demo yet but ship (as the other commenter mentionned, also thanks!) something readable, mostly testable and usable (but limited) on day 0 and go from there.
I do wonder what a recruiter looks for in a good README though. Technical chops or perspective on potential applications/intended project direction or ... ?
You don't have to go whole-hog on CI or anything, but GitHub Actions is pretty easy to just knock together a thing that runs `make test` or equivalent.
I've ended up building boilerplate workflows for various languages, environments, etc. to just drop in and tweak per-project.
Honest question: If someone uses, for example, sr.ht, will you scrutinize it as much as a Github project? Would you check out the project and look for its equivalent of GH actions?
It is the point though. My public github projects are either empty (i pushed nothing cause everything was bad) or are half-baked projects. They would still pass those bars, which i can feel gratefull for.
As a programmer (with a busy professional and personal life), I don't really care for the fact that it's like this but I acknowledge that it is and I also understand that it can be a strong signal in the right hands.
I use my pinned repositories to showcase side projects that I've worked on that are either complicated/challenging problems or that solve a specific problem in a complete way. These 6 repositories are "the most serious" work that is available in my public GitHub profile.
Some time ago, when I put my mind to doing this, I made sure to put extra effort and attention to detail into about a dozen different projects that were in my public profile, so that I had options across languages, project types, etc., for what I'd pin. I put each project through its paces, made sure it ran on multiple platforms (or, that there were notes in the README about how to get there otherwise), cleaned up Makefiles, test suites, etc.
At least one of these projects is incomplete and/or a work in progress, but I've indicated as much in the README, but it's also obvious to see exactly where (and why) that project stalled, if you read through the code.
I can't say that it's helped get me a job (I haven't changed employers) but I do feel a little better about the other 100 or so projects in my public profile now that are in varying states of completeness.
In the Soul of a New Machine Tracy Kidder relates how toward the end of the development of the Nova that Data General started rejecting applicants who had anything computer related as a hobby or spare time interest. If memory serves, they believed on the basis of experience that people with a broader range of interests were better team players and more resilient to burn out.
While this may be technically accurate, the rest of the descriptions on how they interviewed & hired was brutally narrow-minded and biased. You're missing the part where they basically didn't hire anyone with a life outside of computing because you were being hired for an all-consuming death march.
So don't put your github URL in your resume? If you don't want a potential employer to look at something and judge your ability based on it, it doesn't belong in your resume.
Please don't delete your GitHub account because of this one person's article. I have interviewed over a hundred of developers over the years, and I have actually adopted the habit of _not_ looking at their GitHub profile because I find them to be very non-representative of the person's skills and abilities 9 times out of 10. The article isn't bad, by the way, and OP is making very true points, most prominently that resumes are mostly bullshit and shouldn't be relied upon by themselves, but that's what the interview process is for.
If all a person has to evaluate me on is public Github contributions, it'll seem like I only work one day every 3 years or so. With all the other things I do with my life (sport, art, socialising), I very rarely have any time (or motivation) to program in my free-time. Having all of these "extra-curricular" activities is probably good for my mental health and makes me a better engineer than I would otherwise be if I spent all my time both at work and in my own time working on software.
Agree. I do have a GitHub account, but I do not link it in my CV (nor I link my personal website).
I like to write "toy" software that more often than not does not leave my laptop. In the rare occasions I believe the software I write could be of help to others, I do publish it. But man, I code in my free time for fun! I couldn't care less about following guidelines or the latest patterns or using docker, or whatever.
> I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored.
In this case there's no need to publish this type of code; Github offers private repositories for free. If one is convinced that there is value for other people from half-baked experiments, it's definitely worth publishing them in the open (it's possible that they're valuable), but if there isn't, why doing it?
I also notice that many people display private commits in their profile stats; this way, one can signal the amount of activity, if they want (within the limits of what's possible, as certainly commits don't necessarily correlate with intense activity).
I think this is forcing me to choose between two evils - do I want to look like I can only write half baked weekend projects, or do I want to look like I don’t write any code in my free time at all?
Fair point, for me its the latter. I cant put on my CV brief descriptions of side projects I'm working on, during an interview I can give more details on those, etc... Still not ideal because they'd probably want to see the code, but its the lesser of two evils for me
I'm never going to work for a company whose hiring managers require me to post hobby projects on Github.
Won't even entertain interviewing with them.
I shouldn't have to spend thousands of hours a year working on shit outside of work to prove that I can do my job. If it's not obvious from the interview and whatever test I'm given, then we have nothing further to discuss. One of the reasons I don't suffer from burnout is that once I'm finished with my full time job and my consulting side-gig, I leave it alone.
I might dabble in some new technology from time to time, but there's no reason to announce that to the world.
That is one person so I would not read too much into it.
When I read CV and I see github link it is "nice to have" so I check it after I consider that person has enough work experience.
I have only seen "meh" code on GH. If someone would have contributions to some real OSS project he would probably jump queue to front, but it is not like I would throw away application because person is trying just stuff out on GH.
That said - I don't see value in putting my own trash projects on public GH profile. I can have it in local repository or in private repo if I want to synch it between computers or deploy to VPS.
Whenever an employer wants to look at my GitHub I tell them, "Look, this is all going to be half finished tutorials... as soon as I'm halfway decent with a technology I go out and build something proprietary"
Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for? That stuff normally does not need to leave your local harddisk. Maybe exceptionally, if you want to explicitly share it with someone you have been discussing it with.
Maybe I'm getting old and no longer "with it", but to me, this is just like teenagers entering way too much personal info on social media just because there are empty text boxes available.
I have a "code" dir with dozens of subdirectories where I keep all that stuff. Some of those are local git repos because I'm starting to do something actually non-trivial there, and yes, some of those eventually get the "git remote add ..." treatment, and get published on a public code forge somewhere.
I publish as much as I can, and deliberately so. Not so much for internet points but because:
1. It forces me to write a README. No matter how small the project, I afford it an introductory paragraph, installation instructions, usage instructions, and a license. Doing that all the time helps build good habits. If it hurts, I’m not doing it often enough. Doing it often enough helps overcome resistance one day when it actually counts.
2. I contribute something back. It’s not exactly curl, but who am I to judge whether my project will be too trivial to be useful for others? I prefer to leave that decision up to the visitor.
3. Future me is going to get a README for free a couple of years down the road, when the details are long forgotten.
Example: this repository [1] is for a 50-line Bash script [2].
> Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for? That stuff normally does not need to leave your local harddisk. Maybe exceptionally, if you want to explicitly share it with someone you have been discussing it with.
Github is a code repository and not a social network account, so yes many people use it for "half finished tutorials" and little exploratory non-projects up on the Internet?"
Thanks for the answers, everybody. I guess I am the weird one, as I still think it's mostly just adding useless noise to an already noisy public web, and therefore kind of rude.
That's a strange thing to do, in my opinion. That makes me want to put my Github (which is half half-baked nonsense, including this stupid `hello.S` from when I was barely learning amd64) on the resume. I do anyway, but it is now a reason to double down.
After all, if my hiring manager can't correctly evaluate which code is toy and which code is real (I have both on my Github), I don't trust his competence and I want to not talk to him so it is important that he filter me out. This way, my time is not wasted with incompetents.
> If all this person is evaluating me on is my Github, they'll think that I've never advanced beyond an amateur level despite my having over a decade of experience in the industry... all because I treat my open source work as a hobby rather than as a second job.
Thanks you for bringing that up. That is one of the reason I don't use GH. Other being the acquisition by MS.
He's talking about the case where the applicant explicitly provides a github link in their resume or profile. In that case, they could have been expected to pin their favorite projects or remove the ones they don't want seen. Plus they are merely suggesting it be used as a jumping off point for conversation with the candidate.
A good employer will not judge you based on your half-completed personal work. The point isn't to see perfectly executed programs, it's to get a sense for the kind of interests this person has. Seeing a couple half-finished Go projects is better than seeing nothing at all.
Also, my public repos are all code I've done before I started working. My code has improved a lot since I've been coding every day for my job but it's all private.
unless they changed it githubs terms of service do not allow multiple accounts. you'd have to split them over multiple hosting services, which, depending on the project, may not always be practical or possible
> All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored.
I don't understand your complaint. We have free code hosting platforms which support private projects, such as GitLab. You only showcase the projects you want to show, as a public profile is also your portfolio. It makes no sense to showcase half-assed projects you care nothing or feel ashamed to show, as no one forces you to make a git repo public.
It's perfectly fine if you do not curate your portfolio, but you also get the same problem if you don't curate your CV.
Personally, I received job offers based on my GitHub profile alone, as I happened to have a pet project which uses a particular tech stack used by a company. I know people who were automatically excluded from job applications as they claimed expertise on tech stacks they showcased in their GitHub profiles, and their pet projects included blatant eggregious problems which can only result from incompetence.
Companies hire based on the skillset they can evaluate, and if you make it your point to showcase shoddy work then that's a problem you create for yourself.
Has GitHub introduced some “showcase” feature, because this is the first time I’ve heard that a normal public repository should be a treated as a showcase.
Historically, public repos were just where you put code that didn’t need to be private, like hobby code and experiments, just as much as showcase work or supported open source projects.
Has the culture changed so much that this way of using GitHub isn’t familiar to you? How do others here see it?
All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored.
If all this person is evaluating me on is my Github, they'll think that I've never advanced beyond an amateur level despite my having over a decade of experience in the industry... all because I treat my open source work as a hobby rather than as a second job.