7 ms·

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

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.

TheaomBen 4y ago
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!
- theshrike79 4y ago
  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.
  - jstx1 4y ago
    These are some very low bars for a project to pass.
    - orwin 4y ago
      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.
  - TheaomBen 4y ago
    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 ... ?
    - eropple 4y ago
      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.
  - rileymat2 4y ago
    > 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.
    - TheaomBen 4y ago
      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.
- jenscow 4y ago
  For me, there are no "red" flags when looking at someone's public code. I consider them as conversation items. I don't think anyone is expecting to see multiple completed products with 1k+ stars. The worst case is, you waste time agonising over the quality of your code and either: don't publish, or no one even looks at it (highly likely) You're not about to get code-reviewed. At most, if anything, it would be: "explain this class/function": I'd expect you to vaguely know the answer after reading it or, "why did you do <something> this way?": answers like "I got it from SO", "I don't know of a better way" are perfectly fine.
scruple 4y ago
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.

TheaomBen 4y ago

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!

theshrike79 4y ago
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.
- jstx1 4y ago
  These are some very low bars for a project to pass.
  - orwin 4y ago
    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.
- TheaomBen 4y ago
  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 ... ?
  - eropple 4y ago
    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.
- rileymat2 4y ago
  > 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.
  - TheaomBen 4y ago
    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.
jenscow 4y ago
For me, there are no "red" flags when looking at someone's public code. I consider them as conversation items. I don't think anyone is expecting to see multiple completed products with 1k+ stars. The worst case is, you waste time agonising over the quality of your code and either: don't publish, or no one even looks at it (highly likely) You're not about to get code-reviewed. At most, if anything, it would be: "explain this class/function": I'd expect you to vaguely know the answer after reading it or, "why did you do <something> this way?": answers like "I got it from SO", "I don't know of a better way" are perfectly fine.

scruple 4y ago

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.