Read on Twitter
Coding interviews are actively destructive. They DO NOT reduce risk. What they DO do is weed out qualified candidates. I was once given a question that ***I had invented*** for a final exam in my own UC-Berkeley Extension C++ class. 1/6
I was told that the answer was wrong because it didn't exactly match some template written by my former student. If you're weeding out the teacher who actually devised the question you're using, something is seriously wrong. 2/6
In another interview, I used TDD to solve a problem and was chastised ("I didn't tell you to write tests."). In yet a third, I solved the problem elegantly in an OO way, but the interviewer (who was much junior to me) didn't understand OO principles. 3/6
To him, "passing" meant producing hacked-together garbage with no OO structure, and I was rejected. They said "you need to add getters and setters to that class." 
Anyway, I'm glad that I don't care about those sorts of jobs any more, but many do. 4/6
Anyway, I'm glad that I don't care about those sorts of jobs any more, but many do. 4/6
Coding interviews tell you **nothing** about a person's ability do real work with a real team, collaborate effectively, learn, or do anything else meaningful. They tell you that somebody can code up a trivial problem in some language that you may not be using next year. 5/6
They also tell you nothing about whether the candidate can *program* or do any of the important things (e.g. test) needed to actually produce software. They elevate laundry-list thinking, hiring for a specific skill set that will be obsolete a microsecond from now. Dump them! 6/6
