[eric_h]

So this article leads off with @mxcl's tweet about google not offering him a job because he wasn't able to reverse a binary tree on a whiteboard.

I don't think that being able to describe an algorithm you haven't had to implement in more than decade (at least, that would be the case for me, college is starting to be a long time ago for me).

Honestly right now, without looking up the answer, I probably can't reverse a binary tree on a whiteboard. I could, however, do it by test driving a solution with a real computer (I haven't flexed those muscles in a long time, but test driving would help me dig into the recesses of my brain).

Which skill set is more useful for production quality software? I can say for sure that it's not white boarding.

[sklogic]

Deriving trivially provable algorithms in a test-driven way, by trial and error, hoping that no edge cases are missed? Sounds really, really depressing. The future of software engineering is very bleak if this approach is a new norm.

[eric_h]

My point was that I would start by test driving to "dust off the cobwebs", as it were.

Personally, I don't actually believe in truly "mindless", trial and error TDD, as oftentimes it will miss the forest for the trees.

Amusingly now, three days later, I'm certain I could do this nonsense on a whiteboard now, as thinking about it three days ago seems to have primed my subconscious to dig it up.