| I'm in a bit of a similar position as the author. I've been interviewing for a while now, and have had the fortune of many companies approaching me for positions after coming across my profile on HN/AngelList/LinkedIn or discovering Toc Messenger (http://toc.im). Without exception, the next steps in the interview process for all these companies included some kind of an hour long technical interview that grilled me on my ability to solve, under severe pressure (time and otherwise), abstract algorithms and data structure problems that had no relevance to the product engineering positions they contacted me for. I haven't spent nearly as much time as some of my new grad peers on solving these types of problems, as I generally prefer to spend my time actually building things and learning new technologies and approaches to help me build things in a better way, and the difference is really starting to show. In my experience, any half-decent developer with a proper CS education can usually solve these problems (So far, I've never encountered a single problem I couldn't solve within an hour or two in the zero-pressure setting of my own dev environment at home, including the ones I had trouble finishing during actual technical interviews). Solving these problems quickly, however, is a skill that tends to come with practice. [1] Practice is unfortunately something I sorely lack at the moment, but that's been improving lately due to the sheer number of these interviews I've done so far. However, I still don't plan on spending any time outside of actual interviews to begrudgingly improve a skill that I'll maybe get to use a handful of times throughout my career when I need to switch jobs. Software development is a seller's market right now, and there is no shortage of companies that want to hire great developers. To those who want to interview me in the traditional way, I'll gladly play along with your flawed process, but please note that this process is very good at weeding out product-focused developers like me. And if you do weed me out this way, no hard feelings, because I'd at least gotten the extra practice I needed to beat this flawed system. [1] There are exceptions, of course. I have a few friends who seem to have a natural gift and interest for these types of problems, and most of them are working at Google/Facebook right now after acing all of their interviews and receiving multiple offers. But in the large majority of cases, the people who ace your traditional technical interviews are the ones who have spent countless hours reading books like "Cracking the Coding Interview" and practicing solving technical problems to the point that they can probably solve any problem you can throw at them in no time. I don't mean to belittle the talent/efforts of these kinds of developers or their potential value to your company, especially if you really need someone to tackle the hard technical problems in your field of business. However, I do want to question the wisdom of assuming these same technical developers will be the ones who are best able to iterate on and improve your product. |