Good points in the article but as usual much of it continues the trend of "do X, Y and Z to pass an interview" which rarely crosses into the other side of the v

Good points in the article but as usual much of it continues the trend of "do X, Y and Z to pass an interview" which rarely crosses into the other side of the venn diagram of useful skills / talents to have being a software developer day-to-day. I would much rather see a take home assignment of "this is something we've had to do before", give them a few days to work on it, bring it in, make sure they can explain it, make sure their code isn't horrible or if it is there is a damn good reason then sit down with them and work together on adding a new feature. Together. Get an idea how they work with others, how they approach problems, architecting, etc; it seems so brain dead simple and yet almost no one does it. > Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation. In one breath the author acknowledges that it's a waste of time but in the next he's saying you should understand them at least at a high level. There are a ton of useful algorithms and the ones you're going to memorize are not going to be useful in day-to-day work. They simply won't be. Merge sort, quick sort, binary search, etc are all useful but they're also some of the least complex algorithms that you'll never need to implement directly (and if you have to for whatever reason yes you can Google it) and algorithms that ratchet up the complexity are hard to memorize (at least for some people). Common development patterns are far more useful than trying to memorize any algorithms, in my opinion. > Arguably, the most important thing in passing a coding interview is to be well prepared. The best way to do that is to practice common interview coding questions over and over and over again until you know them cold. This part fills me with dread for any upcoming interviews. Practicing answering questions does one thing: it helps you memorize questions and answers. It doesn't help you be a real employee. It doesn't help you jump into wireshark to figure out what's wrong with the network because you hit a wall with debugging your ruby on rails app. It's just useless for anything but the interview. For me I have an online portfolio, several open source projects, references; I'm not saying I'm "too good" to be tested but the fact that I have to waste time and energy memorizing typical questions and answers just so I can provide value to another organization just feels wrong to me. Everyone seems to claim there is a shortage of technology workers in SV so I would expect this ENTIRE process to work the opposite way than what it really does.