I'm coming late to this discussion, but there is one point I'd like to make. Our "interviews" in the world of software engineering, are immensely different fro

I'm coming late to this discussion, but there is one point I'd like to make. Our "interviews" in the world of software engineering, are immensely different from "interviews" in the standard sense of the word. I've worked in different fields, and I talk to people who work in other fields. Most of those fields work in a way that is described in this article - interviews are question and answer sessions, where people are evaluated by a number of highly subjective criteria. "Tell me about your fundraising experience?" "How do you deal with difficult clients or coworkers". That kind of thing. Software interviews are exams. They're not "more like" exams, they are flat out exams. There is very little banter. The closest I've come in google and Netflix interviews has been the more open-ended system design style question they often put in there, but even that has an academic test quality to it. It's pretty much 5 hours of technical exam. "How do you find all matching subtrees in a binary tree" might be a question - and you really are expected to get it written at the whiteboard. "Find all permutations of a set". "Find all square sub matrices in an NXM matrix." The "top" companies are good at modifying the question so that you must know how to do this but can't just regurgitate it. Alternatively, you may do a "take home" exam. Most recently, I did a mini rails project. I actually liked my result, I kind of enjoyed writing it. However, it was a no-hire, one reason given was that my routing was non-standard. True. I hadn't really thought about it, it was a take-home, so I mainly focused on the UI and code, and just chucked in a couple of named routes for demo and testing purposes. The other reason was that there was some duplicate code (I disagreed and had a reason for this, but there is no chance to defend your code, you write it and send it in, and they say "no hire"). I have no idea if it was a real piece of crap and they were just being nice. It had 100% test coverage and git for version control, and implemented a few features. Unfortunately, like I said, I never got a chance to defend the code. Our processes in high tech are badly broken. I'm probably done interviewing, my next job will have to be one that doesn't involve a software interview. The routing and duplicate code, along with a google interview, pretty much sealed the deal for me. My advice to people is (this isn't my idea) be an X that programs, not an X programmer. Coding is an amazing tool for a job, but avoid making it your job. For instance, I actually know a fundraiser who does a lot of data science, and he's a rock star in his field, but I guarantee you nobody asks him to reverse a binary tree in an interview! Best of luck out there. Our interviewing processes are their own special version of horridness, just not uselessness described here.