[HN Gopher] Resumes are dangerous?
       ___________________________________________________________________
        
       Resumes are dangerous?
        
       Author : allenleein
       Score  : 133 points
       Date   : 2022-04-25 07:50 UTC (15 hours ago)
        
 (HTM) web link (blog.alexmaccaw.com)
 (TXT) w3m dump (blog.alexmaccaw.com)
        
       | irjustin wrote:
       | Resumes are dangerous, agreed - but only if you give them enough
       | power to be dangerous.
       | 
       | The point is, resumes should only open the door to live
       | interviews and be very rough notes about what a person can do.
       | You always need a way to test what the candidate claims.
       | 
       | I'm not sure if this is obvious, but I work in the loan
       | underwriting space now and any piece of data that the clients
       | have the ability to control, we take but we must verify with
       | other pieces of data that the client doesn't have access to
       | manipulate. i.e. Accounting software like Xero needs to be back
       | with bank transfer data.
       | 
       | Seems like a prudent route with resumes.
        
       | gitgud wrote:
       | People that lie on their Resume's, may also lie on their Github
       | profiles... but that's admittedly a bit harder to fake
        
         | jeroenhd wrote:
         | It's pretty easy to grab some open source project from Gitlab,
         | alter the commit history to pretend it's all you who wrote it
         | and uploading it to Github. You can also grab some
         | inconsequential JS library, change the name, and publish it to
         | NPM.
         | 
         | If you're putting in the effort to take your resume, you might
         | as well fill out a fake Github. After all, the "hiring experts"
         | only seem to care about the code you've pretended to write.
        
       | skeeter2020 wrote:
       | Finally the tables turn! Engineers cry "hiring is broken!" not
       | undestanding the game is not optimized for the candidate. The OP:
       | "Resumes are dangerous!" not understanding they're a gate-keeping
       | mechanism that's gamed to get an interview. They were never
       | intended to provide the interviewer with a complete
       | representation & background material. That paper rockstar got an
       | interview; would you have given them one otherwise?
        
       | 0xbadcafebee wrote:
       | I think the best alternative to the Resume is Q&A. I think job
       | applications should include a long list of questions to get
       | specific information from the candidate, which would (for
       | example) show how much they know about coding, about working with
       | peers, about what kind of company values they care about (if
       | any).
       | 
       | Of course, filling out the same hundred questions for every job
       | would be terrible. So there should be a website that collects all
       | the questions and lets you resend them to each employer, and lets
       | the employer pick which questions they require and which they
       | don't.
       | 
       | The employer could also fill out questions from candidates,
       | because the candidate _should_ have a lot of questions for the
       | employer. Candidate should be able to select the questions they
       | want answers to.
       | 
       | If both candidate and employer answer questions, an algorithm
       | should automatically sort for which candidate and employer had
       | the same questions, and (assuming multiple choice and
       | weight/priority) which answers were the same or closest. In this
       | way you could simply fill out questions and immediately find the
       | job that matches you best, and the employers could find the
       | candidates that match them best.
        
         | Isthatablackgsd wrote:
         | > Of course, filling out the same hundred questions for every
         | job would be terrible. So there should be a website that
         | collects all the questions and lets you resend them to each
         | employer, and lets the employer pick which questions they
         | require and which they don't.
         | 
         | This is what I did with Obsidian.md, any questions for the
         | applications will be copied and pasted to Obsidian with my
         | answers. If I come across a different applications that have
         | similar question, I look up in Obsidian and use my answer from
         | there with small modification of my answer to fit their culture
         | or mission statement.
         | 
         | It helps a lot because often the company I applied for usually
         | asked for Cover Letter. Obsidian.md have my cover letters for
         | various companies I applied for and it is easy to look back to
         | those and find the one that fits best or create a new entry
         | with a copy of the previous letter and modify it from there.
        
         | nharada wrote:
         | Would this just create a market for answers to the most common
         | questions found at the large companies?
        
           | 0xbadcafebee wrote:
           | I don't think so. There are so many roles at a company, and
           | each one could have potentially hundreds of questions, and
           | each team might be looking for different answers. Select
           | between 4 answers, add a 6-degree weight, plus additional
           | comments for each answer. For 100 questions, that's hundreds
           | of millions of possible combinations. And many of the
           | questions should be subjective or based on personal
           | experience, so that you can find the person who matches what
           | the team cares about. If you see two people with the same
           | answers, it would be almost impossible for them not to have
           | been copied.
           | 
           | I guess the challenge would be to get companies to create
           | good questions. A giant pool of community-curated questions
           | for companies to start with would be good, and they should
           | add questions from the team looking to hire.
        
       | cosmiccatnap wrote:
       | This explains a lot about the state of the industry and why so
       | many good developers have a hard time finding a job. This article
       | does everything except consider the possibility that maybe,
       | management uses the wrong metrics to determine the usefulness of
       | a candidate and that resumes are flawed to the extent that you
       | can't describe a humans experience on one side of one sheet of
       | paper.
        
       | gopaz wrote:
       | I also look for github links, especially for sysadmins, it can
       | give an insight of how they solve things. Bonus points for pull
       | requests.
       | 
       | However, if the person doesn't have a profile, or an inactive
       | one, I don't put any weight on it, it's more an alternative way
       | instead of asking interview questions for me.
        
       | jimmydeans wrote:
        
       | quanticle wrote:
       | _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.
        
         | arinlen wrote:
         | > 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.
        
           | dottedmag wrote:
           | GitHub is not a portfolio website. It's a code sharing
           | platform.
        
           | swatcoder wrote:
           | 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?
        
             | autarch wrote:
             | > Has GitHub introduced some "showcase" feature, ...
             | 
             | Yes, you can pin repos to your profile. But you can also
             | create a profile repo. See
             | https://docs.github.com/en/account-and-profile/setting-up-
             | an...
             | 
             | I wrote a blog post about this and the profile generator I
             | made for myself - https://blog.urth.org/2022/03/28/yet-
             | another-github-profile-...
        
         | 0xbadcafebee wrote:
         | 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.
        
         | kwhitefoot wrote:
         | 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.
        
           | skeeter2020 wrote:
           | 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.
        
             | kwhitefoot wrote:
             | No, I didn't miss that point. That was the reason they
             | finally changed their opinion.
        
         | ekianjo wrote:
         | Why include your Github URL then if you think its only awful
         | code?
        
         | mrfusion wrote:
         | Perhaps consider a personal account and a professional account.
         | 
         | Only put your best work on the professional one.
        
           | em-bee wrote:
           | 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
        
         | bgroat wrote:
         | This.
         | 
         | 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"
        
           | pferde wrote:
           | 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.
        
             | bgroat wrote:
             | > Do people really put stuff like "half finished tutorials"
             | and little exploratory non-projects up on the Internet?
             | What for?
             | 
             | If I want to track version control across multiple machines
             | without rolling my own git server or bothering to mark the
             | repo private?
             | 
             | I don't think it's an old thing. I think it's a HN crowd
             | not really understanding user experience thing
        
             | pferde wrote:
             | 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.
        
             | poulpy123 wrote:
             | > 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?"
        
             | Hackbraten wrote:
             | 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].
             | 
             | [1]: https://github.com/claui/aws-credential-1password
             | 
             | [2]: https://github.com/claui/aws-
             | credential-1password/blob/main/...
        
         | polishdude20 wrote:
         | 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.
        
         | beej71 wrote:
         | Private repos are great for those half-baked projects you don't
         | want people to see.
        
           | antholeole wrote:
           | 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?
        
             | bodge5000 wrote:
             | 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
        
           | [deleted]
        
         | laurent123456 wrote:
         | 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).
        
           | Aeolun wrote:
           | > it's useful to see the candidate's coding skills in advance
           | 
           | Yes, but only if it's representative of their work. Good luck
           | finding the one kind of sensible library I've written in the
           | 100 forks and experiments.
        
             | lolinder wrote:
             | 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.
        
           | Cthulhu_ wrote:
           | I've googled people's names + github if their GH wasn't
           | provided, just out of curiosity.
        
           | tsukikage wrote:
           | +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.
        
         | isthisfree wrote:
         | 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 wrote:
           | 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!
        
             | jenscow wrote:
             | 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.
        
             | theshrike79 wrote:
             | 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 100EUR/hour, I don't want
             | you spending your time doing stuff manually if it can be
             | automated with 15 minutes of boilerplate work.
        
               | jstx1 wrote:
               | These are some very low bars for a project to pass.
        
               | orwin wrote:
               | 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.
        
               | rileymat2 wrote:
               | > 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 wrote:
               | 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.
        
               | theshrike79 wrote:
               | 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
        
               | TheaomBen wrote:
               | 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 wrote:
               | 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.
        
               | BeetleB wrote:
               | 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?
        
               | theshrike79 wrote:
               | To be honest I've never seen a single project on sr.ht :)
               | 
               | But I think it's a plus for using something off the
               | beaten path, provided that the other conditions are met.
        
               | inetknght wrote:
               | > _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.
               | 
               | All of the rest of your points are good though.
        
               | Akronymus wrote:
               | I mostly interact with github via a standard git cli,
               | which does NOT bug me about it.
        
               | dvtrn wrote:
               | Which is something I would think someone who assesses
               | people based on how much they know Github.....should
               | probably know
               | 
               | How ironic ;)
        
           | scruple wrote:
           | 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.
        
         | lbotos wrote:
         | 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.)
        
           | unboxingelf wrote:
           | 100% this. Show me you're actually interested in this stuff.
        
             | anthonypasq wrote:
             | why do you care?
        
             | yiyus wrote:
             | 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.
        
               | unboxingelf wrote:
               | 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.
        
               | fartcannon wrote:
               | The soup of buzzwords is because of the shitty
               | algorithm/outsource your org uses to pre-screen for
               | candidates.
        
               | yiyus wrote:
               | 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.
        
           | floren wrote:
           | 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.
        
             | chakkepolja wrote:
             | 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?
        
               | floren wrote:
               | 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.
        
               | bjourne wrote:
               | 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.
        
             | jimbokun wrote:
             | Too bad, because "fixing a technical error or expanding the
             | comprehensiveness" of existing documentation would be a
             | very strong signal to hire!
        
               | torginus wrote:
               | You mean, when it's meant to signal that a given person
               | fixes every little thing they come across, and not 'hey,
               | this guy contributes to LLVM!'
        
               | floren wrote:
               | 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.
        
           | soneca wrote:
           | > _" 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.
        
             | marcosdumay wrote:
             | 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.
        
               | soneca wrote:
               | Good point
        
             | conro1108 wrote:
             | 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?
        
             | jimbokun wrote:
             | Or maybe the managers will decide to only interview people
             | with a GitHub link?
             | 
             | Could go either way.
        
             | bruce343434 wrote:
             | This strikes me as unnecessarily bitter and cynical.
             | Application is a two way street. _Would_ you even want to
             | work for a company like that?
        
               | poulpy123 wrote:
               | Most people work where they find work, not where they
               | want to work. It's less true in IT, but I'm still betting
               | it's mostly true there
        
               | wiseowise wrote:
               | If they pay well - absolutely.
        
               | soneca wrote:
               | 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.
        
               | slothtrop wrote:
               | A company doesn't necessarily begin and end with the
               | person hiring.
        
             | pclmulqdq wrote:
             | Giving as few reasons to deny your application before an
             | interview just seems like good practice. The whole process
             | is arbitrary anyway.
        
               | nsv wrote:
               | 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.
        
             | codefreeordie wrote:
             | 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.
        
         | Cthulhu_ wrote:
         | > 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.)
        
           | hdjjhhvvhga wrote:
           | > This is my Github too
           | 
           | 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.
        
             | Juliate wrote:
             | 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".
        
               | jenscow wrote:
               | Use github for what you want. However, when you put the
               | link on your CV, _you_ chose to use it as a portfolio.
               | 
               | But for me, experimental work is fine - I use github for
               | conversation items.
        
               | Juliate wrote:
               | 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.
        
             | [deleted]
        
         | pizza234 wrote:
         | > 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).
        
         | lmarcos wrote:
         | 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.
        
         | coffeeblack wrote:
         | _I do not want a future employer judging me on the basis of the
         | half-finished amateurish experiments_
         | 
         | I would not want to work at a company where the tech people are
         | not aware that most repos are precisely that.
        
         | MisterBastahrd wrote:
         | 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.
        
         | tym0 wrote:
         | 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?"
        
           | mauvehaus wrote:
           | 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.
        
             | pc86 wrote:
             | I disagree but want to explain why.
             | 
             | 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.
        
           | mikepurvis wrote:
           | 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.
        
             | cnity wrote:
             | 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.
        
               | mikepurvis wrote:
               | 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.
               | 
               | [1]: https://github.com/mikepurvis/advent-of-
               | code/blob/master/202...
        
               | cnity wrote:
               | 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).
        
               | fartcannon wrote:
               | 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.
        
             | II2II wrote:
             | > 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.
        
               | mikepurvis wrote:
               | 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."
        
               | swatcoder wrote:
               | This smells of career stage myopia.
               | 
               | 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.
        
               | II2II wrote:
               | 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.
        
             | HWR_14 wrote:
             | > other pretty important stuff that can still bubble up,
             | like the person reinventing the wheel where a well known
             | library could have been used
             | 
             | OTOH, reinventing the wheel as a hobby and to deepen
             | understanding makes perfect sense.
        
             | bodge5000 wrote:
             | 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 just glad I don't have my github on my CV
        
               | mikepurvis wrote:
               | > 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.
        
               | bodge5000 wrote:
               | 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.
        
             | whiddershins wrote:
             | What if I wanted to reinvent the wheel to increase my
             | knowledge?
        
               | lbotos wrote:
               | Make a readme that says "This project is me exploring how
               | to do Y so I can learn the ins and outs". Solved.
        
               | reificator wrote:
               | 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_?
               | 
               | My repos are hidden specifically because I do them for
               | fun. I'd make them public if tinkering were an understood
               | thing but its not.
               | 
               | > _If you give me six lines written by the hand of the
               | most honest of men, I will find something in them which
               | will hang him._
               | 
               | Better to have a clear separation between work and play.
        
               | BeetleB wrote:
               | > 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_.
        
             | swiftcoder wrote:
             | > 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.
        
               | chipsa wrote:
               | 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.
        
             | Zababa wrote:
             | > 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.
             | 
             | When I think about "reinventing the wheel" as something
             | negative, I think about something like "Medical researcher
             | discovers integration, gets 75 citations":
             | https://fliptomato.wordpress.com/2007/03/19/medical-
             | research....
        
             | jameshart wrote:
             | 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?
        
               | mikepurvis wrote:
               | 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.
        
               | jimbokun wrote:
               | The difference with software is that you are not allowed
               | to look at the skyscraper, because it is the intellectual
               | property of another company.
        
               | jameshart wrote:
               | 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?
        
               | jimbokun wrote:
               | Nah, you could just have them come and build something at
               | your office while you watch them, and ask them leading
               | questions when they get stuck.
        
           | shikoba wrote:
           | > Github projects are any more representative of the work
           | 
           | They are, that's the moment you see how the person code when
           | she/he is responsible. You see the real skills and potentials
           | of that person.
        
             | jameshart wrote:
             | I disagree profoundly with this assertion.
             | 
             | 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.
        
             | [deleted]
        
             | xboxnolifes wrote:
             | > 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.
        
         | ozim wrote:
         | 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.
        
         | dkdbejwi383 wrote:
         | 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.
        
         | idop wrote:
         | 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.
        
         | deepstack wrote:
         | > 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.
        
         | starkd wrote:
         | 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.
        
         | renewiltord wrote:
         | 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.
        
         | ensignavenger wrote:
         | 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.
        
           | tmp_anon_22 wrote:
           | Lots of resume aggregators and ATS require or at least
           | present a Github URL field whether you like it or not.
        
             | mdm12 wrote:
             | In such cases, I stick with the tried-and-true 'N/A'. I
             | still get offers, so it doesn't auto-delete my application!
        
       | lordnacho wrote:
       | Huge problem with this, apart from not everyone has a GitHub, is
       | that code and expertise are not the same thing.
       | 
       | You may spend years learning about some field like systems
       | programming, and then when you make a contribution to the Linux
       | kernel it's only a few lines. There's no way to know from that
       | how well you actually understand the kernel. You might have a lot
       | of experience, but so did previous contributors, so it looks like
       | you only did a little bit when actually you know quite a lot.
       | 
       | Also there's a lot of work in coding a few lines of code that
       | isn't just those lines. You may have taken apart very large
       | systems and grepped huge amounts of logs to understand something,
       | while having written many intermediate versions of a solution,
       | only for you to figure out the problem could be elegantly solved.
       | 
       | For me the smart way to interview has always been the open ended
       | technical discussion. People who don't know the vocabulary show
       | this very quickly. Imagine pretending to be a surgeon, you'll
       | last one minute. People who are close to the work but haven't
       | done it will last a bit longer but there are so many technical
       | terms they will also drop out, typically when you ask for some
       | sort of judgement on A Vs B. This still hasn't gone wrong for me,
       | my only dud hires have been people who wanted to do something
       | else rather than couldn't do it.
        
         | gwd wrote:
         | > Also there's a lot of work in coding a few lines of code that
         | isn't just those lines. You may have taken apart very large
         | systems and grepped huge amounts of logs to understand
         | something, while having written many intermediate versions of a
         | solution, only for you to figure out the problem could be
         | elegantly solved.
         | 
         | If that's the case, then that should be evident in the commit
         | log.
         | 
         | My one commit in the Linux kernel mostly just moves a few
         | assignments / variables around; but the commit message should
         | make it clear the effort that went into it.
         | 
         | https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
        
       | jasfi wrote:
       | Resume parsing is something I'm working on, see
       | https://lxagi.com, it's in the examples.
        
       | nojito wrote:
       | >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.
       | 
       | We get well over 500 applicants per role. It's absolutely
       | unreasonable to ask our hiring teams to go through the applicants
       | githubs
        
         | keskival wrote:
         | Much fewer than 500 would be left after the initial screening I
         | would hope.
        
       | cryptica wrote:
       | Resumes are not as dangerous as technical tests. 90% of top
       | companies have terrible technical tests which select mediocre
       | candidates and pass up on excellent candidates.
       | 
       | Technical tests with time limits are the worst; this is in part
       | because if the candidate doing the test is more skilled than the
       | engineers who designed the test, the candidate might take longer
       | than anticipated to complete the task because they've thought to
       | do some additional sub-tasks which the people who designed the
       | test did not anticipate and which they would not appreciate or
       | understand. For example, extra logic related to error handling
       | and security will take more time to implement but are critical in
       | evaluating a developer's skill level.
       | 
       | It's happened to me multiple times that I did a test but could
       | not complete it within the allocated time. Then explaining to the
       | engineers why it took longer to complete just doesn't register
       | because they don't seem to understand how important this error
       | handling logic is or why it's important to reset the state of the
       | system between each test case.
       | 
       | I usually don't insist much because if they are like this during
       | the interview process, I can be sure that they will be even worse
       | if I start working there. It's sad because many of these jobs are
       | highly paid and would provide credibility on the resume - At
       | least until the industry figures out that the financial success
       | of a company is usually not correlated with tech talent;
       | certainly not the kinds of companies which solve every problem by
       | throwing 100 engineers at it... That's just brute force; it
       | doesn't require much skill.
       | 
       | Another issue with technical tests is that some developers with a
       | background at a famous SV company will expect you to do things a
       | certain, very specific way (based on how the famous company did
       | it) and not realize (due to lack of other industry experience)
       | that there are multiple valid ways to achieve the same (or
       | better) results for the specific use case which is being
       | discussed. They are overfitted to their past role at the famous
       | company.
        
         | shagie wrote:
         | > ... 90% of top companies have terrible technical tests which
         | select mediocre candidates and pass up on excellent candidates.
         | 
         | This is one of the confusing parts of interviews. They are not
         | necessarily designed to select the _best_ candidate, but rather
         | the least risky candidate.
         | 
         | It is quite possible to have a technically excellent candidate
         | who would be a very risky hire and the interview process is set
         | up to _avoid_ hiring that candidate.
        
           | cryptica wrote:
           | This sounds like kicking the can down the road because the
           | quality of technical tests seems to keep getting worse each
           | year. All these supposedly low-risk hires have caused the
           | quality of engineering to decline over the years which caused
           | a decline in the hiring process which creates a vicious
           | cycle. The risk actually builds up in the long run. It's not
           | surprising why security is becoming such a big issue for big
           | companies nowadays.
           | 
           | If you always hire below your current level of talent (I.e.
           | the apparent 'safe zone'), overall talent will keep
           | declining.
           | 
           | Unfortunately, developers in many companies feel
           | uncomfortable hiring people who might be more skilled than
           | them because they don't want to risk being displaced from
           | their current position or introduce more competition for
           | future promotions. I've seen it happen from the other side
           | where I gave my approval for a candidate who was very good
           | but they were rejected in favor of a different candidate who
           | was below average. It was obvious that the second one was not
           | as good but I suspect that my colleagues may have felt
           | threatened by the first one.
        
       | mgas wrote:
       | Too many people here are crowing about the GitHub thing, and not
       | enough about:
       | 
       | > Above all, I try to hire people who I'd want to pair with
       | tomorrow. People who are better than me, and people who I can
       | learn from.
       | 
       | It seems the only way to get hired period is to have all the
       | experience in the world, at least from the author's perspective.
       | This mentality is far more dangerous since it disallows the idea
       | that someone can get better at a job over time.
       | 
       | Also I feel like this conclusion is just a longform version of
       | "we only hire ninjas and rockstars". The author openly disdains
       | applicants who are so "full of themselves" that they send in
       | overly detailed resumes, but conveniently omits the fact (which
       | everyone here knows) that resumes have to be catered to the
       | filters of your HR software to even land on a hiring manager's
       | desk.
       | 
       | His conclusion is that stuffed resumes are for losers, and only
       | he, the hiring manager with the Midas touch, can see the true
       | value of an individual by glancing over their code and preparing
       | some pitfall questions. This smacks of self-centered egotism and
       | coder bro mentality.
       | 
       | Also as others have pointed out, good coding jobs exist in
       | fintech, government, and 1000s of other industries that this guy
       | sneeringly looks down his nose at.
        
         | drewcoo wrote:
         | Not the author, but . . .
         | 
         | Better can mean better at learning or teaching, cleaner
         | approaches to problem-solving, interesting combinations of
         | ideas I wouldn't have thought of, more potential, or any number
         | of other things.
         | 
         | I firmly believe in only hiring people who are better than I
         | am. That involves looking for ways the candidate is better than
         | I am instead waiting for the candidate to fail the entrance
         | exam.
        
         | em-bee wrote:
         | well it depends whether you hire a junior or a senior position.
         | 
         | the general rule is that if i don't hire juniors, then as a
         | manager i want to hire people who are better developers than
         | me.
         | 
         | otherwise if i hire juniors, i obviously expect them to learn,
         | but the paring point is still relevant, and even juniors may
         | bring an interesting perspective to the team, not just their
         | coding skills.
        
           | mgas wrote:
           | Totally agree on jr vs sr. Another point that is conveniently
           | overlooked in the article so the author can have his holier-
           | than-thou moment. It seems he's hiring seniors, and only
           | wants stars.
        
       | ChrisMarshallNY wrote:
       | I wouldn't call them "dangerous," _per se_ , but they are mostly
       | done to fool AI screeners, these days, and are nothing more than
       | a few data points and buzzwords.
       | 
       |  _> 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._
       | 
       | My experience, is that interviewers don't look at this stuff _at
       | all_. It 's downright crazy. Instead, they rely on leetcode
       | tests.
       | 
       | These are short, academic tests, using algorithms that are seldom
       | seen IRL (I have been coding for over thirty years, and have
       | never seen one single binary tree. I've seen one or two roughly
       | similar structures in some image processing algorithms, but only
       | in a couple of ones that weren't very performant, and we ended up
       | removing these).
       | 
       | But they can be practiced, and are quite familiar to folks just
       | barely out of college.
       | 
       | I've not bothered to practice these. I can do OK on them (they
       | are usually just common sense exercises), but some kid that has
       | spent most of the last month (of their current employer's time)
       | practicing these, will absolutely kick my ass. It's not worth it.
       | 
       | Also, I have noticed that interviewers are looking for rote
       | answers, which also applies to more practical exercises, like
       | take-home tests. They don't like unusual approaches. They are
       | controlling for conformity. That's interesting, as some of the
       | companies doing this, are crowing about "disruption."
        
       | kerberos84 wrote:
       | resumes can be full of lies, github profile as well. that is why
       | you have an conversation (interview) with the candidate and get
       | to know them.
        
         | keskival wrote:
         | People keep saying that, but I have never encountered an
         | untruthful resume.
         | 
         | Fraud is a crime.
        
       | code_runner wrote:
       | My biggest takeaway from this article: this is why I deleted all
       | of those projects from github never to be seen again (prior to
       | private repositories).... the projects where I was just having
       | fun for once and learning instead of being stuck in analysis
       | paralysis and trying to think about 85 different OWASP
       | recommendations at once.
       | 
       | My biggest takeaway from the comment section: thank god that
       | there are more reasonable people than I first assumed.
       | 
       | I have an idea for a hobby/fun webapp I could build that maybe
       | one or two people I know might get use from.... and I'm excited
       | just thinking about it because its going to be low stress and a
       | fun learning experience. Thats what my personal github is. I
       | don't put the link on my resume and I don't really have a desire
       | to either.
        
       | jeffrallen wrote:
       | "Tell me a story of when you solved a difficult bug."
       | 
       | "Tell me about a time you found yourself in conflict with your
       | coworkers."
       | 
       | These two questions, in the hands of a skillful interviewer and
       | interviewee, will get you all the info you need.
        
       | dopamean wrote:
       | I dont understand the point of these blog posts. Is he trying to
       | say this is how everyone should hire? Because if we all only
       | hired based on "would I want this person to be my boss" or "is
       | this person smarter than me" then no one would ever get their
       | first job in the industry.
       | 
       | I cant help but feel like this isnt even how this guy actually
       | hires. This feels like a post intended to gain linkedin clout or
       | something.
       | 
       | Edit:
       | 
       | I feel like it's worth noting that this guy is "Chairman of the
       | Board" at his company and previously "CEO." So his expectation is
       | that everyone he hires who is presumably paid less than him be
       | more talented than him. What does he think this blog post
       | communicates to potential hires?
        
       | davidhyde wrote:
       | > "Then, come the interview, the guy can barely code, much less
       | know the ins and outs of variable scope. It turns out there is
       | very little correlation between how good a resume is, and how the
       | interview actually pans out."
       | 
       | I think that this is more of an argument about how inaccurate and
       | dangerous interviews can be compared to how dangerous resumes
       | are. You can practice interviews and get better without actually
       | becoming a better developer. Same with algorithmic coding tests.
       | Developers who are happily employed rarely get to practice
       | interviews.
        
         | keskival wrote:
         | I'll second this.
         | 
         | It is more likely the interviewer has misjudged the ability of
         | the candidate for any one of myriads of potential reasons in
         | the interview proper, than that the resume was somehow
         | deceptive.
        
       | jameshart wrote:
       | Mostly, resumes I see are just... lifeless.
       | 
       | A list of places you have worked, with dates, and names of
       | systems or applications that will mean nothing to me, and the
       | technologies upon which they were built.
       | 
       | A resume like that tells me nothing more or less than that you
       | have remained employed as a programmer for X years.
       | 
       | I am usually sifting through multiple such resumes, all of which
       | tell me that these candidates are... yup, definitely programmers.
       | They have programmed stuff.
       | 
       | Please, when writing your resume, try to add one thing to each of
       | the date-range jobs that you list:
       | 
       |  _Tell me how you grew and developed in that time_.
       | 
       | Just a couple of sentences highlighting the main things you
       | learned as part of that role. Why do you consider yourself a
       | better, more hireable person now, than you were before you did
       | that job?
       | 
       | That is worth _so_ much more to me than exactly which version of
       | .net that particular SaaS billing platform was built in.
        
         | jjice wrote:
         | As someone who was in college very recently - this is exactly
         | what they tell you to do, at least at my college and with all
         | the new grad resumes I've looked at as well. It's unfortunate.
        
       | denton-scratch wrote:
       | > The first thing I look for in a resume is a GitHub URL.
       | 
       | Wow - that would narrow the field a bit (if the github account is
       | a pre-requisite). For example, I don't interact with Microsoft
       | online properties at all. I don't much care for git. And even if
       | I did use git, I'm not in favour of entrusting important
       | information to online service providers such as Github.
       | 
       | Lucky I'm not looking for work, I guess.
        
       | giantg2 wrote:
       | I just assume anything I do will be seen as a negative. Don't
       | list a GitHub - negative. List the Github - they assume that's my
       | top quality code and that it wasn't mostly written 8-10 years
       | ago.
        
       | TimPC wrote:
       | Resumes are mostly useless in tech. Juniors have too little of
       | note to put on them and Seniors only need to demonstrate enough
       | experience to get a tech screen given the severe shortage in
       | talent. Filtering out someone because they didn't put enough time
       | into their resume is silly. It's even more silly when that resume
       | may be a scrape from LinkedIn and may not even be provided by a
       | first party.
        
       | motohagiography wrote:
       | > _Would I want this person to be my boss? Would I learn a
       | significant amount from him or her? What if this person went to
       | work for our competition?_
       | 
       | Sincere question I would have is, people who work at companies
       | with intense vetting processes to find just the right person,
       | fire fast, and avoid bad hires at all costs - how is that going?
       | You're in, do you see yourself still there in 3 years?
        
       | 7speter wrote:
       | I see a lot of comments here deriding githubs, but what if you're
       | breaking into the industry? Surely in this case its a good thing
       | to have a github link on your resume? For me, being one of those
       | people trying to break into tech, I curate my github with
       | projects, whether success or failure, to show the sum of my own
       | initiative and research, whether borrowing code structure from a
       | given online course for a bigger project, or practicing a concept
       | on my own (I got much better at this recently). While I may not
       | have a degree or previous work experience, I think my github can
       | be a useful indicator for a prospective employer; whether I'm at
       | a place they are fine with and/or I'll be someone they could get
       | up to speed with if need be. Maybe I'm wrong...
        
         | Juliate wrote:
         | And that's perfectly fine.
         | 
         | The issue is to set/have the expectation that necessarily
         | "github = portfolio" and "no github or messy github" = not a
         | good fit" and that candidates not fullfiling this expectation
         | would not be relevant.
        
         | cudgy wrote:
         | The person that wrote this won't hire anyone unless they are
         | better than themselves. So only experienced and top notch
         | candidates will be hired. I find the criteria stated to be more
         | about an ideal hire rather than a typical hire. Pie in the sky
         | expectations that do not really provide much insight into
         | general hiring in my opinion.
        
         | watwut wrote:
         | There is difference between judging people based on what they
         | claim to be their portfolio and based on everything they have
         | on github. What you describe sounds like a portfolio.
         | 
         | But for many people, their github is more of free backup space.
         | They dont curate it. The whole "stop reading what they done
         | seriously and look only at what is in their github" is the
         | issue.
        
           | 7speter wrote:
           | Oh, I have a portfolio too, which is a distillation of the
           | "complete" (enough), mostly front end projects I've worked
           | on. My github has those as well as attempts at fullstack
           | projects for whom I get hung up with affordably and
           | practically hosting... I think both can help create a picture
           | of where someone is.
        
         | pydry wrote:
         | This'll probably get me downvoted but I suspect the comments
         | come from a position of insecurity as older tech people with
         | kids and without much spare time are afraid a line on their CV
         | might not be competitive with 20 somethings with a shiny github
         | profile.
        
           | 7speter wrote:
           | Whats more absurd is I may end up like these people rather
           | soon since I'm a 30 something :)
        
           | Juliate wrote:
           | There's part of that, and that's a good thing: having kids,
           | not having much spare time for work-related stuff _is a good
           | thing_.
           | 
           | As the contrary. It's up to your options and your choices.
           | 
           | And that's irrelevant to your employment/work capacity.
           | 
           | A decent recruiter is aware of that. Others are optimizing
           | for something else than a balanced contractual work
           | relationship.
        
             | pydry wrote:
             | it's entirely irrelevant to work capacity. It's a popular
             | thing to look for because where it does exist and is good
             | it's a strong hard-to-bullshit signal of a good developer.
             | 
             | That doesnt mean that the candidates who dont have it
             | _arent_ equally good. It just means that you cant easily
             | tell it without investing resources into interviewing them
             | and others who look as good as them.
        
           | watwut wrote:
           | People "without much spare time" are actually fine. Their
           | github profile is actually empty or non-existent. So, this
           | whole thing is not threat to them at all. OP will continue to
           | read their CV without finding something bad on github.
           | 
           | But, people who do use github a lot as a place to mess in are
           | threatened.
        
           | scarface74 wrote:
           | I have these things called _hobbies_ and a _life_ outside of
           | coding. When I was single, my hobby was teaching fitness
           | classes, personal training, weightlifting and running.
           | 
           | Coding has merely been a method to turn labor into money to
           | support my addiction to food and shelter for over 25 years.
        
       | mcv wrote:
       | Of course a resume could be full of lies. That's why nobody hires
       | blindly based on the resume but always has an actual interview.
       | During the interview, talking about code, you'll notice soon
       | enough whether the candidate knows what they're talking about.
       | And that doesn't have to be (whiteboard) coding challenges or
       | questions about obscure language details. Just talk about how
       | they code, what coding style they prefer, how they organise their
       | code, etc.
        
         | denton-scratch wrote:
         | Not sure what a "whiteboard" coding challenge is.
         | 
         | The last interview I did, I was asked to find and fix a bug in
         | a small code fragment. On my own, I'd have fixed it in a jiffy;
         | with two interviewers looking over my shoulder I was nervous,
         | and it took longer.
         | 
         | But if you're interviewing on the basis that the candidate
         | claims in their resume to know language X, then a brief test of
         | that is essential; and an online test doesn't cut the mustard -
         | it could be anyone doing the work.
        
           | mgas wrote:
           | A Whiteboard coding challenge is the exact thing you
           | describe. But instead of interviewers looking over your
           | shoulder, they look at the whiteboard as you stand in front
           | of them and write code on the whiteboard.
        
         | beej71 wrote:
         | I've found this works to great effect. I ask the prospective
         | interviewee ahead of time for an example of some code they
         | wrote that they're proud of.
         | 
         | And then in the interview, I ask them to teach me how it works,
         | what could be improved, etc. I might not know anything about
         | it, but I can tell when someone's pretending to teach a thing.
         | 
         | Once had someone bring in a device driver in C for a JavaScript
         | position. Now, I've never written a device driver, but I know
         | the general concepts, and the applicant's description was
         | cogent. They got the job, and they were a great hire.
        
       | travisgriggs wrote:
       | Oh goody. Now I can anticipate an article in a week or so talking
       | about the issues people are having relying too heavily on using
       | GitHub trawling as a hiring signal.
        
       | vmception wrote:
       | 2012 with 2012 logic
       | 
       | A couple hiring managers and recruiters here still do it, thats
       | cute
       | 
       | One things thats changed since 2012 are that private github repos
       | are free
        
       | Distozion wrote:
       | It's an interesting duality of engineers - love the coding
       | challenges when they are the ones evaluating, while refuse to do
       | them themselves :)
        
         | rmbyrro wrote:
         | I'm usually open to coding challenges when the challenger is
         | going to dedicate at least 10% of the time I've put for a
         | feedback.
         | 
         | Some people think it's OK to ask the candidate to dedicate 2
         | hours, then send an automated email rejecting. I don't think
         | this is polite, let alone respectful.
         | 
         | At least have the decency to dedicate 10 minutes to writing
         | down three bullet points for why they were rejected.
        
           | Yhippa wrote:
           | You even get a rejection email?
        
             | [deleted]
        
         | torginus wrote:
         | I think (moderately difficult) coding tests are a great tool
         | since they establish a clear, and mostly objective benchmark
         | for performance, which is hard to fake. While they certainly
         | don't give you a complete picture, I think they are one of the
         | most efficient tools for establishing a base line of competence
         | with regards to both the interviewers and interviewees time.
        
         | higeorge13 wrote:
         | People use the take home tests the wrong way. They should be
         | sent to a small number of candidates that are close to the
         | final stage. But most people send them after the first filter.
         | Then they waste both candidates' and their time and also spend
         | zero time to send any valuable feedback since the pool of
         | candidates is big at that point. And this creates a frustration
         | to experienced engineers not wanting to spend any time on such
         | a process.
        
           | dvtrn wrote:
           | > But most people send them after the first filter.
           | 
           | I once got sent an automated email after applying to an org
           | with a coding challenge _before the first filter_. Before
           | even any recruiter /HM or anyone actually _at_ the
           | organization sent me an email acknowledging they received my
           | application.
           | 
           | I initially bristled, and reached out to the generic
           | "recruiting@" email that was present in the HackerRank email
           | for the company, asking if I could at least have a screening
           | call at minimum before committing time to a coding
           | assessment.
           | 
           | They said no.
           | 
           | In the position of "needing work yesterday", I did the
           | challenge.
           | 
           | And was promptly ghosted.
        
         | hocuspocus wrote:
         | I really like coding challenges when they're done in a
         | productive way:
         | 
         | - Short and fully automated, for instance to skip an initial
         | technical screening;
         | 
         | - Longer, but leading to a follow-up interview.
         | 
         | It's a tool, it can be misused. Be respectful and both parties
         | can benefit from it.
         | 
         | It's like whiteboarding: I don't enjoy companies that expect me
         | to have seen the problem already and regurgitate the answer,
         | but it can be a pleasant experience too.
        
         | wink wrote:
         | We once asked someone for some sample code. Anything they'd
         | done at university really. Let me tell you, the whole team had
         | no idea that you could actually run Python code with such a
         | formatting of tabs and spaces and whatnot, being a white space
         | sensitive language and all. With all goodwill this still looked
         | like someones first program that accidentally ran after fixing
         | the interpreter/compiler errors. Imagine a printed out cover
         | letter but you fixed the typo in your last name with a sharpie
         | and it had coffee stains on them.
         | 
         | There are differences between "code this weird thing on a
         | whiteboard" and "show us some code that you're not terribly
         | embarassed about" (instead of searching on github)...
        
       | makach wrote:
       | Hiring people comes with a high degree of risk. That is why you
       | have a probation. Reading code is also risky. I usually forget
       | why I did what I did and more often than I would like to admit
       | the BLAME is mine - a resignated "..who wrote this?" often turns
       | into - a-ha, it was me.
       | 
       | Resumes is good in the same way grades are good. They might get
       | you to the interview, so don't knock it down just yet.
       | 
       | The hard skills are absolutely important! But the soft skills are
       | equally so. When you talk to your candidate your first impression
       | will be the most important indicator on wheter you will be able
       | to endure working on varieties of task in the immediate future
       | and far away future.
       | 
       | My favorite soft metric is to take them to lunch and observe how
       | we can interact, talk and <sic> hygiene.
        
         | the_snooze wrote:
         | I think more organizations should have candidates (especially
         | senior ones) give a job talk. It's standard practice in
         | academia, but academic job talks tend to be overly long and
         | high-stakes; basically an hour-long lecture about one's
         | research. An industry job talk could just be a 15-minute
         | presentation about a technical topic of the candidate's
         | choosing, followed by Q&A. The candidate has full control over
         | what the topic is, and the audience (i.e., the hiring panel)
         | gets a good feel for that person's interests, communication
         | skills, and soft skills.
        
           | Cd00d wrote:
           | This is what my company is currently doing. First step after
           | a screener call is a 45 minute meeting with the hiring panel
           | to present anything the candidate wishes - some presentations
           | try to fill the full time, some are brief and there's more
           | discussion.
           | 
           | We started doing this to get rid of the repetitive background
           | summary the candidate has to give with each member of the
           | hiring team in 1:1s. Overall, I think it's working well, and
           | wish that places I was interviewing for myself would follow a
           | similar process rather than multiple hours of 1:1 before a
           | tech screen.
        
       | smallerfish wrote:
       | As a hiring manager for a tech startup, I find resumes useful as
       | a filter.
       | 
       | There is a class of applicants who produce 3-4 page resumes
       | filled with tedious details, with every technology they ever used
       | bolded, and turgid prose describing internal software projects as
       | if they should be common knowledge. It takes me probably 15
       | seconds to move on to the next candidate if I see one of those.
       | 
       | The next thing I filter on is choice of employers. If I see
       | health insurer, big insurance, blah fortune 500 firm, government
       | contractor, ... over and over again, then unless there's
       | something in the first half of the first page of the resume that
       | otherwise catches my eye, that resume is also going in the
       | discard pile after 30 seconds.
       | 
       | Finally I'll scan for interesting projects. I generally want to
       | find people who have done more than just CRUD UIs, and show some
       | passion about the technology they've built and worked with. For
       | somebody who makes it past this point, I'll have spent max 60
       | seconds with their resume. I then customize and send the message
       | in the ATS and invite the applicant to check out the company and
       | job posting.
        
         | denton-scratch wrote:
         | > 3-4 page resumes
         | 
         | That's way too much, even for a long career. Two pages is
         | enough. The more resume there is, the more bullshit you have to
         | read. The career history part should be a list of job-titles
         | and dates, with a brief description of each role, noting any
         | salient achievements. Many recruiters will set aside any resume
         | longer than two pages.
        
           | smallerfish wrote:
           | I once had a candidate submit a 20 page(!) resume. They were
           | so full of themselves. That one I actually did spend 5
           | minutes with to see what they found so fascinating about
           | their history, but it was otherwise an instant reject.
        
             | denton-scratch wrote:
             | A 20-page resume bespeaks someone inexperienced in job
             | applications.
             | 
             | One of the important skills I would be looking for in a
             | recruit would be the ability to express themselves clearly,
             | concisely, and persuasively. Clarity and conciseness are
             | marks of the ability to think. Persuasiveness is actually
             | something that makes me suspicious, but in many jobs the
             | ability to persuade others is an asset (leadership
             | positions, for example). So YMMV.
             | 
             | I've always struggled with conciseness; I'm in love with
             | the sound of my own voice.
        
             | astura wrote:
             | Was it this guy? - https://en.wikipedia.org/wiki/Impossible
             | _Is_Nothing_(video_r...
        
             | Cd00d wrote:
             | That may be a cultural/experiential difference. You may not
             | be familiar with CVs as opposed to resumes.
        
             | HWR_14 wrote:
             | In some industries (or academia) a 20 page resume listing
             | every project, publication, patent, etc. is considered
             | normal and desirable. If could be that case.
        
           | em-bee wrote:
           | all right, i am guilty of that. my resume has 5 pages, but it
           | is split up in clear sections that i can easily remove if
           | appropriate:                   page 1:             general
           | objectives             current occupation             summary
           | of the most important or interesting skills and projects
           | page 2:             skills (that's the list of all tech i
           | ever worked with. just the names, no details. only the most
           | important ones are bold.)             work history (list of
           | companies, dates and titles)         page 3:
           | education             detailed work experience (that's a long
           | list of every project i ever worked on, and the role i had
           | there, split up in multiple subsections that i can include as
           | appropriate)                 software development
           | sysadmin work         page 4:                  mentor and
           | teaching experience                 presentations and
           | workshops         page 5:                 organizing events
           | experience working with kids (that i only include for
           | relevant ed-tech or training jobs)
           | 
           | so technically, you could stop reading after page 2. and only
           | scan the rest if you want more details.
           | 
           | do you think it would be better to just skip the project
           | list? i think it's better than a list of projects on github
           | (which wouldn't have any of the interesting projects)
        
             | denton-scratch wrote:
             | > do you think it would be better to just skip the project
             | list?
             | 
             | Hey, I'm not a specialist in this stuff - I've tended to
             | stay in the same job until it became impossible for some
             | reason or other, so I haven't applied for that many jobs.
             | But I was hitched to a careers consultant for 15 years,
             | whose core trade was advising students on how to write
             | resumes. Its only purpose is to get you an interview; if
             | you drop your pants in the resume, then there's nothing
             | left for the recruiter to be curious about.
             | 
             | A resume is a concise overview of your education and
             | career. If you feel you need to describe your objectives
             | and attitudes, or expand on some major achievement, I think
             | that belongs in your covering letter - which can be an
             | essay of sorts (but I keep mine short). The covering letter
             | is tailored to the firm you are applying to. The resume can
             | then be boilerplate, so you can use the same resume for
             | each firm you apply to; only the covering letter is
             | customised.
             | 
             | I treat the resume as a sort of teaser. The covering letter
             | has all the stuff about "If I can't get a job with your
             | firm I'll have to kill myself, because no other employer
             | will do" (no, please don't say anything like that!). But
             | even the covering letter should not be more than two sides
             | of paper. I'd stick to one side. If your concise pitch
             | doesn't get you an interview, then doubling the length
             | isn't going to improve your chances.
             | 
             | Self-testimonials are a waste of space, if your recruiters
             | are any good. For example, "I am a good team player" is
             | worthless, unless you can provide evidence, such as "In my
             | present position I mentor new recruits, and provide
             | training courses for my colleagues". And I think that kind
             | of stuff belongs in the covering letter.
             | 
             | Again, I stress that I'm not a master of these matters. And
             | most of my experience is based on UK hiring; I think
             | puffing yourself up is more expected in the US tech
             | marketplace. I've had one job in the USA, and I think I
             | probably undersold myself that time.
        
               | em-bee wrote:
               | well, the first page is more or less the cover letter.
               | and i do adapt that depending on the job.
               | 
               | hiding the list of projects for the sake of having
               | material in the interview seems to contradict the idea
               | that people want to see my projects on github.
               | 
               | either they do want to see projects or they don't. the
               | project descriptions aren't detailed, and definitely less
               | than a github project. so there still is plenty to talk
               | about.
               | 
               | and i prefer interviews to be about things that can't
               | easily be put in writing. spending the interview talking
               | about historic facts feels like a waste of time.
               | obviously as a candidate i can't choose what the
               | interviewer wants to know, but by getting the facts out
               | of the way, i feel like getting the freedom to talk about
               | things that are actually interesting.
               | 
               | worse, if i am asked to share something about an
               | interesting project, i might not know what to talk about
               | because i don't know what the interviewer wants to hear.
               | but if they have the list of projects they can skim it,
               | pick one they find interesting and ask about that. at
               | least that is how my thinking goes. i haven't actually
               | been interviewed for some time, being more on the
               | opposite side of the table.
               | 
               | as an interviewer i value these details because they
               | allow me to find things to talk about. that is especially
               | important with candidates who are not outspoken and may
               | not be doing well answering open-ended questions. or they
               | may just feel nervous, and not know what to say. the more
               | i know about them up-front the easier it is for me to
               | find something to talk about that they should be familiar
               | with and ease them into the situation.
               | 
               | i agree that a long prosaic CV where it is difficult to
               | find the things that the hiring manager is looking for is
               | not helpful, but a list of projects which is effectively
               | a kind of portfolio as an appendix should not be that.
               | 
               | maybe i should explicitly separate the project list from
               | the CV, so that it doesn't look like the CV itself has 5
               | pages.
        
             | tqi wrote:
             | From what I've seen, a few things that could be helpful
             | are:
             | 
             | - Skip the objective, they are often really generic so
             | people have become accustomed to just skipping ahead rather
             | than reading carefully.
             | 
             | - Presentations and workshops, especially if they are at
             | bigger conferences, could be worth highlighting for more
             | senior roles.
             | 
             | - Education is good to keep just in case there is some kind
             | of automatic filtering.
             | 
             | Personally I have an extended version of my resume that has
             | every job / project written out (that I plan to keep adding
             | to over time), but when I submit a resume I pare down the
             | items to only the ones most relevant to the role.
        
             | theandrewbailey wrote:
             | > skills (that's the list of all tech i ever worked with.
             | just the names, no details. only the most important ones
             | are bold.)
             | 
             | Only put down skills and technologies that you want to work
             | with. I used to put Pentaho on my resume, even though it
             | was the most frustrating thing I've ever worked with
             | (before or since). A recruiter messaged me once about a
             | Pentaho role, which I declined. I dropped Pentaho from my
             | resume immediately.
             | 
             | > summary of the most important or interesting skills and
             | projects
             | 
             | Aaand you can stop right there. Pages 2 and onward can be
             | safely omitted.
        
           | derwiki wrote:
           | I feel like one page is enough unless you have a truly
           | remarkable career. At this point my earliest roles just don't
           | earn their keep; no one cares any more that I was a Micro
           | Computer Support Specialist in undergrad.
        
         | onion2k wrote:
         | _I generally want to find people who have done more than just
         | CRUD UIs.._
         | 
         | FWIW I could describe my current role as "Building a cash
         | management application to track $500m+ revenue for a global
         | ethical cosmetics organisation" on my resume, which is 100%
         | true, but really it's a React app with about a dozen pages of
         | fairly simple CRUD actions. What the reality of the app is and
         | how someone describes it on their resume are two _very_
         | different things.
        
         | astura wrote:
         | >If I see health insurer, big insurance, blah fortune 500 firm,
         | government contractor, ... over and over again
         | 
         | That's where 95% of the software jobs are. Where are people
         | supposed to work if not the places that employ the majority of
         | software engineers?
        
           | cmrdporcupine wrote:
           | Not to mention there's a regional bias here. There are plenty
           | places around the continent that just don't _have_ many cool
           | "startup" type jobs. (Or if they do there's a feeding frenzy
           | for them because everything else in the area is
           | insurance/finance, etc.)
        
             | smallerfish wrote:
             | I'm aware of that, and have done a lot of hiring from the
             | midwest, fwiw. I've been in a position where I don't have a
             | ton of time for mentoring, so I tend to hire senior
             | engineers who are used to running with looser requirements
             | than they may get from a bigcorp, and don't mind juggling a
             | main project with a small backlog of cleanup or bugfixes. I
             | learned this filter after not doing it, and having
             | candidates used to a more structured environment flail.
             | That said, like I mentioned originally, if you can
             | demonstrate in your resume (perhaps even with a "What I'm
             | looking for" section) that you have the skills necessary to
             | thrive, I'll overlook this point.
             | 
             | There are simply too many candidates to give everybody a
             | fair chance, and a good number of candidates left over
             | post-filters who will require fewer interviews to narrow
             | down to a hire. Resumes are about marketing yourself to get
             | to the initial screening call so that you can make your
             | case that you are qualified. It sucks, but if you haven't
             | been dealt the lucky cards and you want to break into
             | startups, I think it's probably useful to know the
             | filtering that you're up against.
        
         | sys_64738 wrote:
         | I spent 30 seconds reading your message here and another 30
         | seconds in this response. You sound like a plain awful manager.
        
         | htkibar wrote:
         | This is horrifying to read. So much bias...
        
           | smallerfish wrote:
           | Tell me one you find horrifying and I'll explain the
           | rationale for doing it.
        
             | quanticle wrote:
             | _I generally want to find people who have done more than
             | just CRUD UIs, and show some passion about the technology
             | they 've built and worked with._
             | 
             | CRUD stands for Create, Read, Update, Delete. Isn't every
             | UI, at some level, a CRUD UI? A wiki is a CRUD UI. A recipe
             | tracker is a CRUD UI. A custom CMS for a community
             | organization is a CRUD UI. A custom web forum is a CRUD UI.
             | Facebook is a CRUD UI.
             | 
             | Someone could reimplement Mediawiki, and you'd reject them
             | because "it's just a CRUD UI?"
        
             | ensignavenger wrote:
             | The Fortune 500 one is a bit disconcerting. I know there
             | are a lot of Fortune 500 developers that would not fit well
             | in a startup, but there are plenty of interesting projects
             | within many Fortune 500s where you would find great
             | developers who would be great startup employees. You do say
             | that you look for something else that catches your eye...
             | but its hard to know what that may be and is probably a lot
             | of chance.
             | 
             | You also state that you want to see "passion" for the
             | technology they have used. I don't really know how to put
             | that in a resume. I have a lot of passion for most of the
             | tech I use- I think that would show within minutes during a
             | conversation or interview. But I'm not confidant my resume
             | really communicates it. Putting "I Love Python!!!" in my
             | resume seems a bit over the top...
        
               | smallerfish wrote:
               | The fortune 500 one I qualified (as I mentioned to a
               | couple other people who objected to this.) I understand
               | why it's disconcerting, but in my position (small
               | startup, small team, need to not waste 3-6 months on a
               | bad hire) I need to increase my chances for a successful
               | hire. Lots of bigcorp devs are used to having everything
               | laid out for them. Early stage startups are unlikely to
               | give the same structure.
               | 
               | Passion for tech - you are right that this is hard to
               | boil down to a formula. I'm looking for people who
               | exhibit signals like (for example) they read HN, have
               | interests in learning languages beyond the ones they're
               | comfortable in, have maybe messed around a little with
               | hardware, were in technology clubs in high school or
               | college, learned programming as a kid, have a hobby
               | project, etc. It's not so much about the hours that
               | people will put in, but rather their engagement / pride-
               | in-work / creativity / ability to propose alternate-
               | solutions, all of which are good things to have, and are
               | easy to qualify for with "enjoys technology."
        
               | ensignavenger wrote:
               | At least at my current job at a "boring" Fortune 500, we
               | don't work that way at all. I'm sure there are plenty
               | that do though. I guess if you are getting enough hires
               | using your current system, there is certainly no reason
               | to change it.
               | 
               | I suppose I should consider a way to indicate the I read
               | Hacker News on my resume :) Thanks for responding, I may
               | be able to improve my resume some by considering how to
               | show more of those things. Right now, I focus a lot on
               | Python in my resume, because that is my primary language
               | of expertise and what I use every day. But I am very
               | interested in Rust and various functional languages in
               | general too.
        
             | tqi wrote:
             | What kind of projects are the people you hire working on,
             | and is it more than just CRUD UIs?
        
           | beej71 wrote:
           | I think the only really uncommon thing here is that they're
           | spending a full 15 seconds per resume. :)
           | 
           | When I put together a resume, I figure I have about 3 seconds
           | to get them to decide to continue reading the resume. So I do
           | my best to put in whatever it takes to accomplish that
           | (within the bounds of truth).
           | 
           | No one reads a resume straight through; they skim for the
           | highlights they want to see.
           | 
           | The more skimming passes you get them to make over your
           | resume because you've kept their interest up, the more likely
           | the interview.
           | 
           | And if you're thinking that a resume is a poor format for
           | getting this job done, you're right. :)
        
             | Cd00d wrote:
             | Why don't you have a recruiter paring down the number of
             | resumes dramatically so that you can actually give each one
             | that passes that review adequate reading?
        
               | recursive wrote:
               | 1. Recruiters are expensive. 2. It's hard to find a
               | recruiter who doesn't _increase_ your incoming resume
               | volume without a corresponding increase on quality or
               | fit. As far as I can tell recruitment has settled into a
               | stable equilibrium of being a volume game.
        
           | woodweb wrote:
           | What is so horrifying? He's hiring startup developers who
           | need self-direction.
           | 
           | Look like his rationale is if you can't speak high level and
           | you can't resist over-engineering solutions; it isn't going
           | to work out. That saves everyone time and sounds reasonable
           | to me.
        
             | em-bee wrote:
             | it also depends on the companies. where i am now, big
             | corporations work their engineers to exhaustion and teach
             | them a very competitive attitude. that's not something i
             | want in my small company. i need cooperation and mutual
             | support, where developers back each other up and not try to
             | gain favors with their manager at the expense of their
             | teammates.
        
             | Cd00d wrote:
             | He's flat out rejecting people for corporate experience.
             | You don't know the reasons people take jobs or why they're
             | looking for a change.
        
               | smallerfish wrote:
               | I qualified that by "over and over again" and "first half
               | of first page". If you're switching from nothing but
               | bigcorps to startups, you need to give me something on
               | the resume to make me think that you can adapt to the
               | cultural change.
        
       | baazaa wrote:
       | There's like half a century of IO psych literature showing
       | resumes to be very poor predictor of job performance. Good to see
       | this guy's own experience confirms what everyone (besides
       | managers) already knew.
        
       | [deleted]
        
       | stmw wrote:
       | "The interviews are spent discussing code, and writing code. It's
       | what we programmers do day in, day out. It's the one things that
       | matters." - very true. That's also literally the idea behind
       | interviewing.io and similar platforms that have been making this
       | point for years* - so they get to coding with the candidate as
       | quickly as possible. Maximizes information for _both_ the hiring
       | manager and the candidate on whether they want to work together.
       | 
       | * https://blog.interviewing.io/resumes-suck-heres-the-data/
        
       | nerdjon wrote:
       | "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."
       | 
       | Many others have commented on this line so just throwing in my
       | opinion.
       | 
       | I have long wondered if my lack of having public code on GitHUb
       | has been an issue with getting hired. (Not that I really have
       | issues, but you have to wonder what opportunities you did not
       | get).
       | 
       | My lack of any code isn't out of a lack of love of coding (I in
       | fact do, I have a few personal projects I have just never chosen
       | to open source them... largely because I know that I made some
       | questionable decisions since I had no code review). I also
       | struggle with getting into working with other projects, not
       | necessarily out of a lack of desire but it just feels daunting.
       | 
       | I do truly understand the desire for this, but if this is
       | something the hiring manager was looking for... I would hope that
       | once they do hire someone they encourage them to open source some
       | of what they are working on or contribute to projects while
       | working.
        
         | keskival wrote:
         | You don't need to open source your code to publish it on
         | GitHub. You can just put the code there in a public repository,
         | but not put an open source license for it.
         | 
         | The code remains your copyright and no one else has a license
         | to use it.
        
       | woeirua wrote:
       | I prefer to ask the applicant to either submit code that they are
       | proud of, or to do a small toy problem if they don't have
       | anything they can readily share. Then we talk through their code
       | during the interview, asking them questions like: what problem
       | were you trying to solve, did you solve it, what problems did you
       | run into along the way, how would you design this code
       | differently, and of course any specific questions if we find
       | glaring technical issues in their code.
       | 
       | I've found this approach to have a very high signal-to-noise
       | ratio as it's virtually impossible for someone to talk at depth
       | about their code if they don't know what they're doing. Also, you
       | can't study for this type of interview, so you can't game the
       | system.
        
         | bern4444 wrote:
         | I had an interview where this was the case. I had a bit of code
         | I was very proud of and had fun writing. It wasn't more than 75
         | or so lines. This was the best interview since it allowed me to
         | share a related interest of mine through the code sample I
         | brought.
        
       | didcot wrote:
       | *I'm only upvoting this article in hopes that people will read
       | the comment section.*
       | 
       | "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,..."
       | 
       | I really enjoy coding in my few hours (read < 1 hour) of spare
       | time after my son goes to bed, and while I could spend that time
       | preening immaculate projects to impress employers and keep my
       | commit history alive, that would kill the joy of programming for
       | me. I would seriously consider a career change if maintaining
       | code as a second job was required to keep my career alive.
       | Additionally, I have seen many job candidates attempt to make
       | github accounts specifically for resumes and the results are
       | mostly mediocre due to the lack of time and motivation required
       | to build something informative enough to effect the outcome of a
       | hiring. If anything the general consensus from looking at theses
       | github accounts is on average more negative than positive when we
       | see repositories of "bootcamp" exercises.
       | 
       | The author states a disclaimer "Doing open source is not a be-all
       | and end-all by any means" which may be true in his case, but what
       | he is doing is encouraging this behaviour in other workplaces.
       | IMO resume-github showboating has lessened in the past few years,
       | but I would hate for us to regress again.
        
         | fer wrote:
         | Yep, fully agree.
         | 
         | I'm considering writing a small library that I've always needed
         | at every job I've had (and always had to half-ass implement
         | part of its functionality due to time/budget constraints). To
         | have it slowly cooked, pristine, fully tested, reliable and a
         | pleasure to use for people. Because that's what I wanted at
         | those times in those jobs.
         | 
         | Not only I would love working on it, but would also help with
         | an aggressive "if you like it, good, if not, good luck with
         | your coding tests" approach to being hired. Disclaimer: I do
         | poorly in tests.
         | 
         | But if I was required to have that, I wouldn't ever had a job
         | until now, simple as that.
        
       | k__ wrote:
       | _" first thing I look for in a resume is a GitHub URL"_
       | 
       | Ah yes, gatekeeping at its best.
       | 
       | Because every skilled person has time to build stuff in public.
        
         | eric4smith wrote:
         | You know what kills an interview really fast?
         | 
         | When you ask the candidate to see some code and they tell you
         | every single thing is under NDA.
         | 
         | Brah, if you're a programmer, you have at least some tinker
         | code lying around that you can show.
        
           | [deleted]
        
           | hocuspocus wrote:
           | If that were even remotely true then almost no Apple employee
           | would ever manage to find another job.
        
           | ReptileMan wrote:
           | The only thing I have is project Euler in haskell. What
           | insights will you get about that corporate java job
        
             | dinedal wrote:
             | If you're slinging Euler in Haskell, the insight is that
             | you're probably overqualified for most corporate java jobs.
        
             | recursive wrote:
             | That you can write code. That's a positive signal. There's
             | a reason FizzBuzz exists.
        
           | scarface74 wrote:
           | I haven't written a single piece of code outside of work
           | since I started working - in 1996.
           | 
           | The only reason I have any open source code is because my
           | company has a very easy open source process. I extract
           | reusable non customer identifying code from projects and it
           | usually takes at most 3 days for approval.
           | 
           | There is also a company sponsored open source project I
           | contribute to.
        
           | Silhouette wrote:
           | The point is that you might not _want_ to show toy code. Toy
           | code I 've written for fun is rarely written to the same
           | standards I'd use for anything important, including code
           | written for work.
           | 
           | It probably won't have elaborate CI/CD tooling with a clear
           | branching strategy.
           | 
           | It probably won't have a comprehensive test suite.
           | 
           | It probably won't have systematic error handling.
           | 
           | It probably won't have carefully written comments to help
           | other people find their way around it.
           | 
           | Most important of all it probably won't be designed or
           | cleaned up to the standards of good professional code,
           | because I wrote it for fun or to solve some specific problem
           | and not to be a portfolio piece and I stopped once the code
           | had served its purpose.
           | 
           | If anyone I might work with insisted on judging me on code
           | like that they'd never get a realistic view of my level.
           | 
           | If I wanted to show someone an example of code that did
           | faithfully represent what I can do I'd want to show them some
           | of the many projects I've completed to a high professional
           | standard at work. But of course that code really is usually
           | confidential and at least in my case that tends to be because
           | it's important to the business and might not be public
           | knowledge yet so it really would be very unprofessional if I
           | went around handing it out to anyone who asked.
        
           | astura wrote:
           | I don't... I haven't written any code outside of my 9-5 job
           | since I graduated from college almost 20 years ago.
           | 
           | I am still a really good employee and I always get excellent
           | performance reviews.
        
         | pydry wrote:
         | I see this attitude everywhere and I swear it makes no sense at
         | all. Interviewing and selecting and hiring candidates _is_
         | gatekeeping. Thats literally all it is.
         | 
         | I guess the implication is that it's elitist or somehow unfair
         | gatekeeping?
         | 
         | If you ask the question "is it a more _elitist_ form than
         | gatekeeping than looking at your fancy university credentials
         | or experience at a FAANG? " then I think it's not so much.
         | 
         | IME it's less time consuming than leetcode and take home
         | projects and about 1000 times less soul sucking than both.
        
           | hocuspocus wrote:
           | It's not unfair gatekeeping, it's incredibly dumb
           | gatekeeping. You're definitely going to miss out on
           | interviewing good candidates.
           | 
           | If the candidate can show code and you're willing to look at
           | it because it saves everyone's time, then sure, go ahead. But
           | there are plenty of very good reasons a candidate might not
           | be able to do so.
        
             | pydry wrote:
             | For sure, but I cant really think of another _low friction_
             | way to detect high quality candidates.
             | 
             | CVs are easy to bullshit as the OP points out and
             | ascertaining performance on a technical interview comes at
             | a high cost.
             | 
             | Search costs matter. Other than "I worked with this guy"
             | (which doesnt scale) I dont know of a quicker method of
             | uncovering an obviously decent programmer.
        
               | Juliate wrote:
               | Search costs matter, and GitHub browsing is low friction,
               | but extremely low signal on a very narrow bandwidth.
               | 
               | A lot of the best (technical-wise and ethic-wise)
               | collaborators I've had had and have no public profile,
               | some even not on LinkedIn. You won't find them there.
        
               | pydry wrote:
               | _shrug_ this is the exact opposite of my experience. All
               | the really great people I 've worked with have had at
               | least _something_ there and I 've _never_ worked with
               | somebody with a great github profile that wasnt also a
               | great programmer.
               | 
               | Having a decent profile is rare enough that it cant be
               | your whole hiring pipeline but IMHO it's a great reason
               | to let somebody skip an assessment stage or prioritize
               | them for interview.
        
         | mouzogu wrote:
         | tbh would prefer someone look at my code instead of some
         | leetcode test.
        
         | DJHenk wrote:
         | It can be worse. As I understand it, this person just wants to
         | see code. I'd imagine that sending a zip file, or express
         | willingness to do some small assignment would suffice too.
         | 
         | Meanwhile, I have been blocked from applying for a position
         | multiple times because the online form required me to enter a
         | LinkedIn profile, which I don't have. It would require a lot of
         | time to create a profile and message all my relatives and past
         | co-workers to build a nice looking network.
         | 
         | I just treat this as a sign that we were probably no a good
         | match anyway.
        
           | felipemnoa wrote:
           | And here I thought I was the only one. Glad I'm not the only
           | one without a LinkedIn profile.
        
             | formerkrogemp wrote:
             | Honestly I'm not sure you need one for programming. In
             | accounting it's kind of required.
        
           | marssaxman wrote:
           | Wow, that's awful! What a thoughtless requirement. On the
           | other hand, it's helpful of them to filter themselves out of
           | consideration so quickly. Who'd want to work at a place like
           | that?
        
         | zarzavat wrote:
         | Software engineering is a highly-compensated professional job.
         | It's a given with such jobs that professionals are expected to
         | spend some of their free time on their own career development.
         | 
         | This means working on open source, staying up to date with new
         | technologies, learning interview techniques.
         | 
         | Everybody is entitled to _a_ job but nobody is entitled to a
         | fancy job.
        
           | RalfWausE wrote:
           | And not everybody (as a personal statement from me) is at all
           | interested in a "fancy" job...
        
           | HWR_14 wrote:
           | > a highly-compensated professional job. It's a given with
           | such jobs that professionals are expected to spend some of
           | their free time on their own career development.
           | 
           | Except most highly-compensated professional jobs don't expect
           | people to get continuing education on their free time. The
           | state bar and medical boards not to mention engineering
           | certifications all require continuing education. Everyone
           | I've known in those fields is paid for the continuing
           | education credit time.
        
         | rmbyrro wrote:
         | It doesn't have to be a _real-world_ open source project.
         | 
         | Could be a project you built to learn a language or framework,
         | for example.
         | 
         | Or some library you wrote for your own personal use. If there's
         | nothing sensitive, you can publish it under an open license or
         | even without any license at all...
        
           | nemetroid wrote:
           | My employer doesn't allow publishing code that was written
           | during working hours.
        
             | Gravyness wrote:
             | Why would you publish code that was written during working
             | hours?
             | 
             | Why not publish an university project, a learning exercise,
             | or something you built for fun? Surely there is more reason
             | to create something than you're getting paid to do it,
             | right? Or are artists just silly?
        
               | marssaxman wrote:
               | I publish practically everything I write in my free time,
               | whether it goes anywhere or not, but I would never link
               | to that playground on my resume!
        
               | nemetroid wrote:
               | I think some of my university projects are published. But
               | they're quite old by now, and not representative of the
               | production code I write. I do learning exercises quite
               | frequently when getting into new
               | libraries/frameworks/languages, but again, that's on
               | company time.
               | 
               | I don't begrudge others that do, but I don't code in my
               | free time, I have other hobbies. Thus getting back to the
               | original point made:
               | 
               | > Because every skilled person has time to build stuff in
               | public.
        
           | bluescrn wrote:
           | Some employment contracts claim ownership of anything you
           | create even outside of working hours, so even publishing
           | those little learning projects could potentially be
           | problematic.
        
             | rmbyrro wrote:
             | This is another problem.
             | 
             | For this purpose, you only need to show _authorship_ ,
             | which is different from _ownership rights_.
             | 
             | In general, your employer can't stop you there. Some
             | exceptions would be if it conflicts with their products or
             | if you disclose technological knowledge that could
             | jeopardize competitive advantage.
        
               | quanticle wrote:
               | _Some exceptions would be if it conflicts with their
               | products_
               | 
               | Amazon has that provision in its employment contract. The
               | problem is that Amazon has its fingers in so many pies,
               | no matter what you write, you could potentially get in
               | trouble with legal. One person I knew there had to wait
               | six weeks for approval from legal so they could work on a
               | Lisp interpreter.
        
             | sofixa wrote:
             | How are those legal anywhere? Thankfully they aren't here
             | in France.
        
               | maccard wrote:
               | Even if it's not legal, I'm not going to sue my employer
               | to stake ownership over an evening project.
        
               | rmbyrro wrote:
               | You don't need ownership here, just _authorship_.
        
               | formerkrogemp wrote:
               | American exceptionalism at its finest.
        
               | astura wrote:
               | https://www.joelonsoftware.com/2016/12/09/developers-
               | side-pr...
        
               | bluescrn wrote:
               | Even if they're not likely to win in a court battle, most
               | people don't want to risk a dispute over something
               | trivial.
               | 
               | Would you expect a little game jam game created in a
               | weekend to lead to an ownership dispute with an employer?
               | - Probably not, but I'm aware of a case where it has
               | happened...
        
       | agentultra wrote:
       | > Then, come the interview, the guy can barely code, much less
       | know the ins and outs of variable scope. It turns out there is
       | very little correlation between how good a resume is, and how the
       | interview actually pans out.
       | 
       | Be careful with this assumption.
       | 
       | Interviews generally measure how well a person responds to
       | anxiety. This can overwhelmingly dominate and mask any signals
       | about their competency.
       | 
       | I can talk about algorithms and data structures all day and have
       | little difficulty solving fairly challenging problems.
       | 
       | Stick me in an interview and, depending on a lot of different
       | factors, I can easily come across like this person. Sure I've
       | built open source libraries, written countless articles, and have
       | given talks at open source conferences but at the end of the day
       | I can't handle 5 hours of talking with people and then do even
       | the most basic tasks. Anxiety and exhaustion will over-ride
       | everything at that point.
        
         | xena wrote:
         | I wonder if that's why I tend to do better at job interviews
         | with a mild bit of entheogens in me.
        
       | rmbyrro wrote:
       | Wouldn't hurt adding a (2012) to the title.
        
         | verytrivial wrote:
         | (Or editorializing to add an accented-e. I honestly thought I
         | was about to read a story about resuming some process after it
         | was interrupted!)
        
       | irrational wrote:
       | >Surely resumes are the only way to deal with the volume of job
       | requests some companies get?
       | 
       | This is partly true. It is truly shocking to me how many resumes
       | has spelling and grammatical errors. If there is one single
       | document you will ever write that must be spelling and grammar
       | error free, it is your resume. As soon as I come across a single
       | spelling or grammar error in a resume, it immediately gets
       | trashed. I don't care how good a programmer your are, details
       | matter. If you are going to be sloppy with your resume, you are
       | going to be sloppy with the company's code.
        
         | miguelrochefort wrote:
         | > I don't care how good a programmer your are, details matter.
        
           | irrational wrote:
           | How do you know I didn't do that on purpose? ;-)
           | 
           | But, I don't care about your spelling and grammar mistakes in
           | emails and slack messages (and hacker news comments) after
           | you are hired. Its just on your resume where it matters.
        
         | maxk42 wrote:
         | > It is truly shocking to me how many resumes has spelling and
         | grammatical errors
        
       | jeroenhd wrote:
       | The nice thing about this method of hiring is that I probably
       | wouldn't want to work for a company that trusts someone with such
       | silly biases to pick candidates anyway. The code I write and push
       | to my self-hosted Gitlab is none of your concern.
       | 
       | If you're going by some trivial standard (github repos, leetcode
       | ranks, whatever the case may be) you're going to be talking to a
       | lot of people who made it a priority to get hired, not to write
       | good code or even work well in a business environment. I'd argue
       | that high-effort resume stuffing is even worse than the lazy
       | kind, because you might be tempted to give the candidate the
       | benefit of the doubt or skip over some of the validation
       | questions that a resume-based hiring process might demand. You
       | might even end up hiring bad coders who are better at making
       | stuff up and repeating textbook excerpts than writing or
       | maintaining any real code.
       | 
       | The author states that during interviews he talks through the
       | code the interviewee has written and the decisions they have
       | made, but such a process could easily be reversed as well. Grab
       | some company code with known architectural flaws or technical
       | debt and walk through that. Ask what they would've done
       | differently and why. Ask what they would do to improve it. This
       | probably works best with some archived code from stale branches
       | or sunset products so you don't give off the impression that
       | you're doing this for your gain and you won't risk leaking any
       | important company secrets anyway. Better yet, grab some of your
       | company's open source projects (Your company has a public Github
       | as well, right?)
        
         | PenguinCoder wrote:
         | >The code I write and push to my self-hosted Gitlab is none of
         | your concern.
         | 
         | Agree and this is a reason I selfhost my own git server and
         | repositories. I still want to use git, but what I personally
         | write is none of a third parties business. I have a bunch of
         | scripts and a few programs in various language's, some side
         | project websites and the like. But none of that is something a
         | potential employer needs to see or start dissecting.
        
         | commandlinefan wrote:
         | > I probably wouldn't want to work for a company that trusts
         | someone with such silly biases to pick candidates anyway
         | 
         | The good news is, it's probably not true anyway. Whenever you
         | see these posts, they're almost always written by somebody with
         | a weak resume who spends all of their free time maintaining
         | open source, hoping to convince somebody _else_ to read their
         | github profile.
        
         | inetknght wrote:
         | > _The code I write and push to my self-hosted Gitlab is none
         | of your concern._
         | 
         | From an intellectual-property standpoint: it actually might be.
         | 
         | But I do think intellectual property laws need to change.
        
           | [deleted]
        
       | thunderbong wrote:
       | This article is talking about seeing only aspect of the
       | interviewee. In my opinion, although coding capability is
       | obviously required, there are so many aspects of an individual
       | that needs to be seen before they can be hired.
       | 
       | Also, Github is not the only code repository in the world!
        
       | Juliate wrote:
       | The whole article gives a strong "never work with this type of
       | person" vibe, with a big NO to their own 3 closing questions.
       | 
       | From the naive "GitHub profile is relevant" take, through the "a
       | developer MUST know the ins-and-outs of their techs anytime or
       | they're just not worth it", through the "code is the one thing
       | that matters" (sheeesh...).
       | 
       | I would happily fail and laugh out from an interview with that
       | kind of employer profile.
        
       | eric4smith wrote:
       | I saw something here a few days ago in about "reading code for an
       | interview". We were in the middle of hiring. And I decided to
       | give it a shot.
       | 
       | It was eye opening.
       | 
       | Our stack is Elixir and I made the programmer tell me what a few
       | functions were doing line by line and he aced it. I'm hiring him.
       | (He does not know Elixir).
       | 
       | This is completely right. Resume's are a waste of time. They
       | don't tell you about any of the capabilities of the candidate. If
       | anything some candidates are smart enough to make a really
       | beautiful resume to fool you.
        
         | [deleted]
        
       ___________________________________________________________________
       (page generated 2022-04-25 23:02 UTC)