[Sodman]

You have to remember though that coding interviews != production code. Taken to the extreme, are you also adding logging, metrics, performance benchmarks, etc?

TDD is great if you can get it working in a tight interview time schedule - they can also reveal any misunderstandings of requirements before the actual solution is implemented!

On the flip side however, many interviewers have experienced countless folks who spend the majority of the interview time on tests and setup, only to run out of time on delivering the solution to the actual presented problem. When I feel like somebody's spending too long on these things I'll try to nudge them towards wrapping up the tests and moving onto the solution. You would be surprised though by just how frequently it's met with open hostility, by candidates with only 10-15 mins left in an hour-long interview and no solution started!

[hinkley]

And in a real situation I have all of these tools set up and running, so I shouldn't need to spend more than a minute faffing about with them. I'm just writing exploratory tests to make sure that I've got the bits right before I put them together. Even in an hour task those tools can be a force multiplier, once you figure out how to make them work instead of fighting them constantly.

What's happening in interview loops is that we're implicitly or explicitly selecting for people who prefer to YOLO instead of writing tests, and then we are surprised how hard it is to get new and existing hires on board with mature testing processes. The people you need don't work here, they work somewhere else.