<story><title>Show HN: I made a job board that doesn&apos;t allow HackerRank tests</title><url>http://borderline.biz/careers</url></story><parent_chain><item><author>thewebcount</author><text>One of the things I&amp;#x27;ve done is to hand a candidate some existing code and ask, &amp;quot;What do you think of this code? Do you see any obvious problems? Are there things that work but could be done better? Is there anything exceptional in there? Tell me what you see.&amp;quot; This allows you to test that they know how to read code, which is what they&amp;#x27;ll be spending the majority of their time doing. You can ask them how they&amp;#x27;d improve it, which should give you an idea of how they write code, too. And of course, you can see their experience by checking out their resume and if possible running some of the apps they worked on. And if they have any code on GitHub, etc., you can check that out, too.</text></item><item><author>AlchemistCamp</author><text>&amp;gt; There are better ways to test candidates.&lt;p&gt;Genuine question here: what&amp;#x27;s the better way?&lt;p&gt;I&amp;#x27;m not a fan of whiteboard coding challenges, even though they got me my first &amp;quot;real&amp;quot; Bay Area tech job.&lt;p&gt;On the other hand, take home challenges eat up a lot of time and credentialist filters like going to a name brand school (or even having the right major) filter me out.&lt;p&gt;My go-to for when I&amp;#x27;m in a hiring position again would be recommendations from my personal network, but that has its own flaws and doesn&amp;#x27;t scale very well.&lt;p&gt;I think at the core of the problem is that most companies are extremely risk adverse in their hiring and would gladly miss a Jeff Dean type of super-performer in order to reduce their number of bad hires.</text></item></parent_chain><comment><author>colmvp</author><text>One of the companies I interviewed at had me do this exercise at the end of the interview and to be frank, I bombed it quite badly. One issue was the syntax was so weird compared to the type of code I&amp;#x27;m used to writing and reading from others in library code that it was hard for me to comprehend the logic without the benefit of looking it up.&lt;p&gt;I was filled with anxiety working under the time pressure to understand a document of code which I had very little context of, and no previous relationship with the reviewer so I kept thinking to myself whether or not the question that came into my mind was stupid obvious.&lt;p&gt;In contrast, when I had take-home tests, I scored exceptionally high on all of them, leading to offers. I recognize that a lot of people here hate them because of the time involved and it&amp;#x27;s akin to spec work, but IMO it felt much more like my usual day-to-day life as a developer.&lt;p&gt;One of the take home tests had existing code to work from but again, working at my own pace and having access to online resources to read docs was much less anxiety provoking.</text></comment>
<story><title>Show HN: I made a job board that doesn&apos;t allow HackerRank tests</title><url>http://borderline.biz/careers</url></story><parent_chain><item><author>thewebcount</author><text>One of the things I&amp;#x27;ve done is to hand a candidate some existing code and ask, &amp;quot;What do you think of this code? Do you see any obvious problems? Are there things that work but could be done better? Is there anything exceptional in there? Tell me what you see.&amp;quot; This allows you to test that they know how to read code, which is what they&amp;#x27;ll be spending the majority of their time doing. You can ask them how they&amp;#x27;d improve it, which should give you an idea of how they write code, too. And of course, you can see their experience by checking out their resume and if possible running some of the apps they worked on. And if they have any code on GitHub, etc., you can check that out, too.</text></item><item><author>AlchemistCamp</author><text>&amp;gt; There are better ways to test candidates.&lt;p&gt;Genuine question here: what&amp;#x27;s the better way?&lt;p&gt;I&amp;#x27;m not a fan of whiteboard coding challenges, even though they got me my first &amp;quot;real&amp;quot; Bay Area tech job.&lt;p&gt;On the other hand, take home challenges eat up a lot of time and credentialist filters like going to a name brand school (or even having the right major) filter me out.&lt;p&gt;My go-to for when I&amp;#x27;m in a hiring position again would be recommendations from my personal network, but that has its own flaws and doesn&amp;#x27;t scale very well.&lt;p&gt;I think at the core of the problem is that most companies are extremely risk adverse in their hiring and would gladly miss a Jeff Dean type of super-performer in order to reduce their number of bad hires.</text></item></parent_chain><comment><author>mattm</author><text>I do this as well.  It&amp;#x27;s the best signal to noise ratio.  Developers spend much more time reading code and understanding the system rather than writing code, yet interview questions don&amp;#x27;t acknowledge this.&lt;p&gt;It also works even if the person doesn&amp;#x27;t know the language because you&amp;#x27;ll get to see them mapping this new language to something they already know and it can give a good understanding of how well they think of things beyond just the code in front of them.</text></comment>