Is Something Wrong With Coding Tests?

I'm looking for work as a senior software developer these days, so I'm doing a lot of coding interviews. I am uncomfortable with coding interviews. They're stressful; get the optimal answer, quickly, to a problem often selected to be difficult or unfamiliar. They're adversarial; you are a poser unless you prove yourself worthy. They're artificial; produce correct code, but on a whiteboard, from top to bottom, without being able to go back and add a few lines, in less than 20 minutes.

But what makes me most uncomfortable about coding interviews is that I don't see a connection to a developer's day-to-day practice. I have to develop an unfamiliar algorithm only a couple of times a year. I implement a standard data structure almost never (with the exception of linked lists). My day-to-day practice consists of decomposing hard problems into many generally-easy-to-code steps. In fact, the coding chores I perform are usually so familiar to my mind that I do them by reflex, spending most of my attention on how the piece I'm writing nibbles away at a big, hard problem. When I come to a tough bit of coding, I slow down, analyze the heck out of it, test it, and make a deliberate end of it. Concentrating on the code is a distraction that keeps me from concentrating on the problem I'm solving.

But coding tests aren't big. You can't nibble at them. They're all hard part, compressed, like evil haiku. You can't work deliberately; there's an interviewer behind you with a stopwatch. Coding tests are in fact just like CS homework assignments, where you must solve a riddle on paper and then write 10 lines of code. They reward the new grad, who has recent practice with homework problems, and no reflexes for coding. They play to the vanity of the recent hire, very impressed with their own training; unaware of how much they don't know.

When you apply for a senior position, interviewers ramp up the difficulty of the coding challenges. Instead of problems from an undergrad data structures class, they pose supposedly unfamiliar problems. These problems generally have a simple, inefficient solution, and perhaps one or more faster solutions that involve dynamic programming. The bar is higher for senior applicants than for new grads. This would be sensible if solving this kind of problem was something we all did every day so that experience made us better at it. The fact that we don't do CS homework problems in the working world makes this kind of interview a subtle form of age discrimination.

I think of myself as a talented developer, but I haven't shown well on coding tests. That makes me wonder. Are there senior applicants who do really well at coding tests? When companies hire these applicants, do they demolish deadlines and eat hard problems for breakfast, leaving a trail of shredded feature story cards? Or is passing the coding test a mental trick? I've met one guy in my career (hi ~toma) who was a lightning-fast coder. He produced five times as many lines of code as any other member of our ten-person team, and the code he produced was reasonable, if not special. Other than that, I've worked with folks who wrote bad code quickly, folks who wrote decent code at a deliberate pace, and a small number of complete morons. Why haven't I met more devs who could solve any problem brilliantly in 20 minutes?

Can I study for coding tests? Can I acquire skills that make me more capable of solving such puzzles? (The answer is yes). 

An even more interesting question is this. If I learn to be good at coding tests, will I become faster than a speeding bullet? Will it inform my day-to-day practice of programming? Stay tuned.