Ask HN: Why are live interviews higher signal than public GitHub code in hiring?
I do understand that me looking at your github is faster and easier for you than me getting you to problem-solve live, and also potentially more representative of the kind of work you&#x27;d actually be doing once employed. From my POV, if I&#x27;m hiring someone to solve problems, I&#x27;d like to see how they solve a problem; and certainly your github is a record of you solving some problems.<p>Nevertheless.<p>If it&#x27;s a toy problem, I&#x27;d rather it was my pick of toy problem than your pick of toy problem. If it&#x27;s a hard problem or a significant open source contribution, it will take much more time to fairly evaluate than a toy problem, and so there needs to be some form of screening of candidates first because there is only so much time and there are more candidates than that.<p>In order to evaluate your open source contribution on github, I need to invest considerable time understanding the codebase you are working on and the problems your changes are solving before I can even begin to properly think about your changesets, then prepare myself as I would for a live code review in order to give you a fair hearing; otherwise it&#x27;s just Elon Musk&#x27;s &quot;send me your best line of code&quot; all over again. I could enter the interview without the preparation and just let you talk me through things from cold, but then what I am really evaluating is your communication skills, not your problem-solving skills; which may be appropriate for some positions, but does not help me much if what I need is someone to problem-solve.<p>When there are more candidates than available positions, it then takes even more investment after the interviews to compare candidates to each other, and the results are relatively subjective.<p>Such a process may be appropriate for some senior or specialised positions with relatively few applicants, but in general does not scale well during We Just Got New Budget So Let&#x27;s Recruit All The People month.<p>The live interview with simple questions and toy problems, for all its faults, has the (admittedly dubious) advantage that it is self-contained and that multiple candidates get similar or identical questions, making it easier not only to agree on a shortlist but also to spot potential problems with the interview process itself. One might <i>then</i> go look at github repositories as well as scheduling longer meet-and-greets for the most interesting people to make the final selection.<p>This isn&#x27;t great, but choosing whose codebases to properly look at based just on the candidates&#x27; CVs is even worse, and that (or even <i>worse</i> methods! - they exist!) is what we are left with if we exclude the phone screen &#x2F; live interview as a tool from our hiring pipeline.<p>(Note that writers, when submitting their novels to publishers, also don&#x27;t throw the entire novel at the publisher from cold (or if they do, they aren&#x27;t likely to get very far) - they generally have a cover letter with a brief summary, and supply a representative sample for the reviewer to read; different publishers have different rules for these, but generally no more than a chapter. Moreover, many publishers don&#x27;t accept direct applications, or only accept them during specific, brief, time periods - by requiring the author to get an agent to agree to represent them, they are effectively outsourcing that initial screening step)