I&#x27;d like to start by thanking Anna (the author of this post) for identifying and writing about something that I consider to be a very serious problem in tech.  While I disagree about some of the details, I&#x27;m in complete agreement that hiring practices (among other things) are a serious in our industry, and I feel increasing frustration with an industry that constantly talks about a &quot;shortage&quot; of talent while tolerating or even perpetuating practices that (in my opinion) clearly drive away talented people.<p>I recently went through the interview gauntlet, including (at one company) five hours of whiteboard exercises with a short break for lunch.  While I can&#x27;t post exact interview questions, I would say that the difficult level questions from &quot;cracking the coding interview&quot; and other sites are probably indicative of the difficulty level of my interview.  For example &quot;find the least common ancestor of two nodes in a binary tree&quot; or &quot;find the sub matrix with the larges sum in an NXM matrix&quot; would be pretty typical questions (though of course you won&#x27;t know the questions in advance).   This is at the whiteboard, no programming environment to try things out,  under time pressure, in what can only reasonably be called a stressful environment.  Many people who took difficult in-person exams consider these to be among their most stressful academic experiences.  In software, we consider this to be a normal part of changing jobs.<p>I agree with Anna that the amount of preparation is considerable.  I brushed up on data structures and algorithms, but I only allowed myself three weeks (I&#x27;m employed full time, married, have kids, coach soccer, shuttle kids around to music practices, and so forth, so getting time to study isn&#x27;t as easy as it used to be).  I should have asked for three <i>months</i>.  I did get the basics back, so I could implement various tree traversals, code up a hash map, do dfs and bfs on a tree, solve binary problems, but I just didn&#x27;t get fluid enough to do this in a creative way at a whiteboard (On the bright side, I actually enjoyed the work, and I still study these things now.  I&#x27;m probably much stronger now than I was when I did my interviews.  I actually kind of like challenging data structure problems, it&#x27;s a side of programming that I kind of missed).<p>But here&#x27;s what I learned from the experience: where it comes to <i>interviewing</i> and getting a job, you really need to be exceptionally strong on the basics if you&#x27;re going to be able to solve these kinds of problems at a whiteboard in a 45 minute interview.  I know you can look up DFS, but only if you have a while to solve a problem, under less time pressure.  I you need to use DFS to solve a related problem that you haven&#x27;t seen before, in 45 minutes, at the whiteboard… you just need to know this cold.  You need to be read to apply it cold.  I&#x27;m not defending the interview process here, I&#x27;m just trying to explain to people what they need to do to be prepped for these interviews.<p>Now, I do have a few disagreements with Anna&#x27;s article, in particular around the solution of the &quot;take home&quot;.   Although I&#x27;m sympathetic to the idea of a &quot;take home&quot; exam rather than an in person, and I see some benefits, ultimately, I don&#x27;t like this approach.  This is partly because of my own personal experiences - I once spent the requested 5-7 hours on a homework assignment, sent it back to the recruiter, and heard nothing back, crickets chirping, aside from checking in with the recruiter politely even week or so, until I got a one sentence call back (again from the recruiter, never did talk to a developer) &quot;we&#x27;ve decided not to move forward with your application at this time&quot;.  I think Gayle Laakman McDowell wrote a very good summary of how this practice can become abusive - ultimately, her argument is rooted in the way it allows companies to burn a lot of a candidate&#x27;s time without a comparable investment themselves, here&#x27;s the full link:<p><a href="http:&#x2F;&#x2F;www.gayle.com&#x2F;blog&#x2F;2013&#x2F;09&#x2F;18&#x2F;companies-who-give-candidates-homework-assignments-knock-it-off" rel="nofollow">http:&#x2F;&#x2F;www.gayle.com&#x2F;blog&#x2F;2013&#x2F;09&#x2F;18&#x2F;companies-who-give-cand...</a><p>To me, I think the first thing we need to do is recognize that any &quot;shortage&quot; that tech companies are experiencing needs to be considered in the context of how tech hires.  A cynical part of me thinks that this process did exactly what it was intended to do, that it&#x27;s not about whether a candidate can find all matching subtrees in a binary tree, it&#x27;s whether that candidate can afford to drop everything to get into such mental&#x2F;coding shape that they are able to do this at the whiteboard.  If they can&#x27;t, perhaps that&#x27;s a sign that they have life demands that are incompatible with what tech companies are looking for?<p>This has been a long comment, thanks to everyone who read this far.  I do think tech has a long way to go.  The problems run much deeper than the solutions I hear about from silicon valley &quot;leaders&quot;.  Until tech addresses these problems on a much more fundamental level, expect those with choice (ie., those aren&#x27;t compelled to study certain subjects and work certain jobs as a condition of getting to live and work in the US) to continue to avoid this field in favor of other professions and trades.<p>I do think that the recent focus on tech hiring is a positive sign that we&#x27;re starting to look beyond superficial fixes (&quot;make programming cool!&quot;) and more deeply at the process itself.<p>Here&#x27;s another very good blog post that addresses this: <a href="http:&#x2F;&#x2F;www.fastcompany.com&#x2F;3043082&#x2F;most-creative-people&#x2F;why-software-maker-fog-creek-is-helping-its-competitors-hire-women" rel="nofollow">http:&#x2F;&#x2F;www.fastcompany.com&#x2F;3043082&#x2F;most-creative-people&#x2F;why-...</a>).