Earlier quoted context omitted.
I also drew a complete blank at an interview in a coding problem... and then went home an implemented it (taking quite a bit more time than I'm comfortable admitting ;-) ). Interviewing is hard (from both sides). Sometimes it just isn't your day. Sometimes it just isn't your job. I was quite depressed when I screwed up that interview because it was the first one I had done after taking 5 years away from programming p…
Unit test are not just for people who write bugs (parent comment), a good start would be to test for the 9th row the problem was asking for. Since you can't test all possible values a representative sample would be good enough. Just to be pedantic: It's not TDD if he already wrote the functional code ;)
I could write a failing test that PT(1) = [1]. I could make it go green easily, and then write a failing test that PT(2) = [1,2,1] and make that pass, using my algorithm. Depending on how much you did in the last step, there may be no more failing tests that you could write. I can imagine maybe one more failing test, but after that you are done.
That's what I meant by "and then there is magic". The "test driven" doesn't really help the "design" at all. Your first test is the trivial case and the second test is "did it work?" I could arguably skip the first test altogether, and whether or not I wrote the second test before I wrote the production code is completely irrelevant because the test doesn't help you write the code.
Now, you might want to "refactor" this to be:
PT(n) = (n.choose(i) for i in [0..n-1])
(This is just pseudo code for a list comprehension that returns an array of n choose i for all the values of i from 0 to n-1). I could then write the code for choose(), but I'm in the same boat -- there is no benefit to writing choose() TDD because your first test will be trivial and you r second test will require the full answer.
While my "refactor" could use the tests I wrote with my "TDD" of PT(), I haven't demonstrated the value of TDD at all because the "refactor" is not related to the tests. I could just have easily written that code first and then written a test to see if it was correct.
Finally, if a bug is introduced to the code, the tests may pick it up, but are almost certain not to shine light on what went wrong because the tests are not related to the design of the code.
This is an excellent example of code that I would not write TDD (and I write 99% of everything TDD). I might not even write it test first depending on my mood.
Trying to be slightly diplomatic, the point of my post was that in all likelihood, a person who gives you this programming problem to demonstrate your TDD abilities has no clue about TDD. The alternative explanation is that they intentionally picked a problem that doesn't work well for TDD and wanted the person to explain why this was a sucky problem.
If you weren't very familiar with TDD, I could imagine this tripping you up pretty badly. You'd think, "what the hell test am I going to write?" As you point out, it doesn't really matter -- you can write any test that will sort of test that your code can grossly come up with the right answer. After that there's not actually anything beneficial you can do.