Algorithmic Interviewing – Optimizing to Hire the Wrong Developer

Nice counterpoint, but you are making a some assertions here that don't seem to follow -

So you say there are developers who are good at putting lego bricks together to solve business problems, but introduce bad, unmaintainable code because they are bad as engineers.

You say algorithms questions are a good way to identify them.

To me, algorithms questions show that you studied CS in an academic setting, and listened in class.

People who introduce bad code do so because:

* They 'don't have time to do it right', the root of this being that they lack the confidence or judgment to say a task will take longer.

* They lack experience maintaining code, or haven't learned the skills to write maintainable code. This happens wen people have mostly worked alone, and can be rectified by working closely and under someone good who reviews their output for a while. CS school does not teach this.

* They 'have not heard of' things that 'should be' common knowledge, e.g. unit testing. Fresh graduates often lack 'common knowledge', as do people who worked a long time in a role that just used some specific, older stack.

With all these problems, the way to fix them is to properly monitor and understand people on a team, but also they must have the humility to take advice. I'm guilty of identifying too much with my code sometimes, but we've all seen people who get very very defensive.

Look, I'm all for discriminating against people who didn't study CS. It keeps my wages up right. But if you are trying to solve this problem you describe, surely identifying the actual cause of what is bad about these candidates is a better idea?

Do you hire a mechanic who knows how the car works in intimate detail over a mechanic which knows how to fix cars? Depends. But usually if they know how the car works chances are they are also great at fixing them.

In tech it is the same, with the additional wrinkle that you want to hire aptitude over experience.

Oftentimes that's the first answer that the interviewer is looking for (without the attitude). But then they want to see you code a MergeSort or QuickSort up from scratch, and explain the difference between them.

Why? Because what happens when your data set exceeds available RAM? Then you can't use the stock libraries, since they're all designed for in-memory datasets. You have to rely on external sort, which is a cousin of merge sort but has fairly different properties because of the vast difference in performance between RAM and disk. Or what if you have multiple computers available to you? Do you implement a parallel external sort over the network as a library (or service), or do you rely on domain knowledge of the keys to do some sort bucketing to each computer, like a radix sort? What are the trade-offs between each one?

Software engineering is somewhat peculiar in that 95% of the time is spent gluing pre-made components together, and yet the majority of the money is made off the 5% that requires actual creativity and knowledge. Why? Because gluing components together is a commodity. You can do it, but so can every other college grad who knows how to Google StackOverflow answers on the web. The folks who make $300K+ a year at Google/Facebook or get acquihired for a mil or two a piece or found a startup that strikes it big are the ones who know how all the "standard" stuff works on the inside so they can take it apart and piece it together in new and innovative ways.

FWIW, I was hired by Google in the depths of the 2009 recession because "You have both solid front-end skills and deep algorithmic knowledge, and that's not a combination we see very often." I work with a number of Ph.D's from top universities who are doing cutting-edge machine-learning and ranking algorithms. Many of them cannot code themselves a UI if their life depended upon it, let alone stay up-to-date with emerging web standards, stay away from browser quirks, debug obscure Javascript or CSS corner cases, or pay attention to client-side latency.

Good web development is harder than it looks. I've done some pretty impressive algorithmic stuff (eg. ported Arc to Javascript, wrote a Scheme interpreter in Haskell, built a JIT in LLVM, coded a conformant HTML5 parser in C), and I'd say that on a day-to-day basis, web development requires the largest body of knowledge and the greatest ability to make trade-offs in your head.