Green Lumber Fallacy in Software Engineering
I agree with the author, mostly, though I don&#x27;t have as much of a problem with the deeply technical questions he&#x27;s suggesting one shy away from -- my problem is with how the responses are handled by the interviewer.  And as far as the whole &quot;give them the actual work&quot; approach, I love it -- I do it, and I stand by it, but don&#x27;t abuse the candidates time in the process.<p>For the most part, I avoid the data structures-style questions.  We have a limited time as interviewers and while these show off a candidates knowledge in areas we may need very rarely, I&#x27;d rather have someone who is productive at using what the framework we write code in provides.  I stick with &quot;when is it appropriate to use &#x27;X&#x27; vs &#x27;Y&#x27;&quot; style questions but usually don&#x27;t have to ask them; the candidate reveals that knowledge (or lack thereof) through other questions and I <i>hate</i> whiteboard interviews.  I don&#x27;t penalize the candidate for lacking knowledge they&#x27;re never going to use on the job, but I like to know what areas they have <i>deep</i> understanding of.  Before I ask these questions, I&#x27;m careful to point out &quot;I don&#x27;t care if you know the answer to this or not -- you might encounter that once in 10 years, here -- but if we do encounter it, it&#x27;s helpful to know if you have a deeper understanding than others on the team.&quot;  For the most part, though, it&#x27;s a waste of time and I&#x27;d rather spend that time on the next two points.<p>My preference is to ask the candidate (very carefully) to provide a link to <i>anything</i> they&#x27;ve written that they can legally[0] share openly.  My explanation includes all of the following: I am not interested in judging them on the code they send me -- in fact, I want their worst.  I want the code that they don&#x27;t care about, that they wrote in a hurry to solve some random problem that <i>they</i> had and that &quot;just needed to work and do that one thing&quot;.  I&#x27;ll use that code as a starting point to discuss refactoring -- i.e. &quot;What if you wanted to take this code and make it worthy of a product you&#x27;d sell&quot;.  If there&#x27;s <i>absolutely nothing</i> that they are <i>comfortable</i>[1] sharing, I ask them to take a few minutes and find a project in the framework we&#x27;re interviewing for on GitHub that we can use for that purpose.<p>As for the &quot;give them the actual work&quot;, we have a single-sheet project we give to <i>every</i> candidate, Junior, Mid or Senior.  It&#x27;s a &quot;to do&quot; app with basic requirements: Must use a database of some kind for storing&#x2F;retrieving data (Sqlite is called out as an option, but anything relational is allowed), it must allow adding, marking complete, unmarking complete and deleting.  We additional coach Senior&#x2F;Mid developers to include things that would be important for a completely released application with examples (none of which are required), such as documentation, instructions for starting&#x2F;setting it up, installers (with advice not to take this too far as that&#x27;s one hell of a rabbit hole).  Depending on the outcome of the &quot;actual work&quot;, we might follow-up in a similar manner to ask them questions about their choices.<p>I&#x27;ve seen everything from a To Do app that used SignalR to perform its operations, allowing multiple users to watch the check-list get updated in real-time (complete with a WiX installer, OWIN hosted web service running as a Windows Service with everything wired up and a doc generation project[2]) to a simple HTML-template based solution that is done in four files.  Of course, we check the usual sources for obvious evidence of whole-sale copying, but we&#x27;re not terribly strict here, either (this point is made on the spec sheet -- it&#x27;s such a simple app, it shouldn&#x27;t require a lot of research&#x2F;copy-pasta to build).<p>[0] The first time I did this, I left off that &quot;legally&quot; part and the candidate shared code that -- while not representing anything their employer would care about (basic library code that probably every programmer as written from time to time) and certainly not representing anything the company I worked for was interested in &quot;stealing&quot;, it carried a copyright that they did not own.  Unfortunately, it disqualified the candidate (not my choice in this case, but the company I was working for at the time had concerns that the employee might introduce liability we didn&#x27;t want).  And I don&#x27;t want any candidate to think I&#x27;m asking them to break their contractual obligations in order to get a job -- we operate ethically and don&#x27;t want to imply otherwise.<p>[1] I&#x27;m always careful to say &quot;comfortable&quot; so as to allow them to not have to feel bad about not having any code written &quot;outside of work&quot;.  I have met many software developers (albiet often in the Junior&#x2F;mid-level skill levels) who simply don&#x27;t care to write software outside of work.  At the senior level, I&#x27;ve met several software developers who haven&#x27;t written anything publicly shared in a while -- they&#x27;re working too much at their current job, have families, and might not have the time to devote to things outside of that.  Interviewing sucks and anything I can do to disarm the person and get them talking&#x2F;excited will help me to evaluate them better.<p>[2] The dude <i>really</i> wanted the job.  OK, I lied, the dude was me, but it was rare that I wouldn&#x27;t include these things in an app I was writing for my current employer, so those parts were automatic (and easy at that point) for me -- it felt wrong not to include them.  I used the documentation to explain my choices, mostly, which avoided a second technical interview.