I'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'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 "shortage" of talent while tolerating or even perpetuating practices that (in my opinion) clearly drive away talented people.

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't post exact interview questions, I would say that the difficult level questions from "cracking the coding interview" and other sites are probably indicative of the difficulty level of my interview. For example "find the least common ancestor of two nodes in a binary tree" or "find the sub matrix with the larges sum in an NXM matrix" would be pretty typical questions (though of course you won'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.

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'm employed full time, married, have kids, coach soccer, shuttle kids around to music practices, and so forth, so getting time to study isn't as easy as it used to be). I should have asked for three months. 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'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'm probably much stronger now than I was when I did my interviews. I actually kind of like challenging data structure problems, it's a side of programming that I kind of missed).

But here's what I learned from the experience: where it comes to interviewing and getting a job, you really need to be exceptionally strong on the basics if you'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'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'm not defending the interview process here, I'm just trying to explain to people what they need to do to be prepped for these interviews.

Now, I do have a few disagreements with Anna's article, in particular around the solution of the "take home". Although I'm sympathetic to the idea of a "take home" exam rather than an in person, and I see some benefits, ultimately, I don'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) "we've decided not to move forward with your application at this time". 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's time without a comparable investment themselves, here's the full link:

http://www.gayle.com/blog/2013/09/18/companies-who-give-cand...

To me, I think the first thing we need to do is recognize that any "shortage" 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's not about whether a candidate can find all matching subtrees in a binary tree, it's whether that candidate can afford to drop everything to get into such mental/coding shape that they are able to do this at the whiteboard. If they can't, perhaps that's a sign that they have life demands that are incompatible with what tech companies are looking for?

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 "leaders". Until tech addresses these problems on a much more fundamental level, expect those with choice (ie., those aren'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.

I do think that the recent focus on tech hiring is a positive sign that we're starting to look beyond superficial fixes ("make programming cool!") and more deeply at the process itself.

Here's another very good blog post that addresses this: http://www.fastcompany.com/3043082/most-creative-people/why-...).