<story><title>When hiring developers, have the candidate read existing code</title><url>https://freakingrectangle.wordpress.com/2022/04/15/how-to-freaking-hire-great-developers/</url></story><parent_chain><item><author>gaoshan</author><text>This is exactly what I started doing at my company a few years back. You are presented with a complete app written in the stack we use. This app has some bugs we will solve to get it working (nothing that&amp;#x27;s a trick... actual, commonly encountered bugs that have all the error messaging you need to solve them). Once it is working you will walk me through a particular flow of the app, explaining what is going on and why we do it this way. There are optimization opportunities (purely optional, there for you to notice), areas we can dig into if we choose (or if I feel the need to). If you tear through it we can examine a different flow in the app. Perhaps we could discuss the database structure and how it might be improved or changed, maybe we dig into some CSS or into some GraphQL or any other aspect that we need to. I&amp;#x27;ve had people stumped and unable to continue but the vast majority of devs can make a good stab at it, even if they are not familiar with the specific stack. The best devs are barely slowed down by such unfamiliarity and can still reason, logically, about the code.&lt;p&gt;So far I&amp;#x27;ve had really positive feedback from job candidates. A couple even described it as their favorite interview ever! I feel like it has worked well, given the people we have ended up hiring.</text></item></parent_chain><comment><author>88913527</author><text>I only once ever had an interview as you describe, and from a candidate perspective, it was my favorite! I had fun with it, and it was far more collaborative with my interviewer. I got to learn from them, instead of just regurgitating straight CS knowledge. It was all around a more human centered process. I got to learn that I would enjoy working with my interviewer, for example (this was a smaller company, so probably less applicable at scale-- unless you can continue to have the interviewers be candidate&amp;#x27;s colleagues, at scale).</text></comment>
<story><title>When hiring developers, have the candidate read existing code</title><url>https://freakingrectangle.wordpress.com/2022/04/15/how-to-freaking-hire-great-developers/</url></story><parent_chain><item><author>gaoshan</author><text>This is exactly what I started doing at my company a few years back. You are presented with a complete app written in the stack we use. This app has some bugs we will solve to get it working (nothing that&amp;#x27;s a trick... actual, commonly encountered bugs that have all the error messaging you need to solve them). Once it is working you will walk me through a particular flow of the app, explaining what is going on and why we do it this way. There are optimization opportunities (purely optional, there for you to notice), areas we can dig into if we choose (or if I feel the need to). If you tear through it we can examine a different flow in the app. Perhaps we could discuss the database structure and how it might be improved or changed, maybe we dig into some CSS or into some GraphQL or any other aspect that we need to. I&amp;#x27;ve had people stumped and unable to continue but the vast majority of devs can make a good stab at it, even if they are not familiar with the specific stack. The best devs are barely slowed down by such unfamiliarity and can still reason, logically, about the code.&lt;p&gt;So far I&amp;#x27;ve had really positive feedback from job candidates. A couple even described it as their favorite interview ever! I feel like it has worked well, given the people we have ended up hiring.</text></item></parent_chain><comment><author>andrewflnr</author><text>&amp;quot;Bugs we will solve&amp;quot; seems to imply there&amp;#x27;s still a coding component. Is that correct? That&amp;#x27;s a different thing from what OP describes (and FWIW I&amp;#x27;m pretty sure I like yours better).</text></comment>