Presumably, any feature implemented to spec in TDD would have a test written for it (first). The TDD project will have a subset of functionality but will implement each feature with simple objective tests correctly.
The idea is that the other project will implement a feature first, then fix bugs found.
The assumption here is that both projects are not yet complete. For the TDD project, not all features have been implemented. For the non-TDD project, not all bugs have been ironed out.
In the interview, this is explained by a hand-wavy explanation that both projects asymptotically approach the ideal project state of feature-complete and bug-free. The TDD project approaches it from the bug-free direction and the non-TDD project approaches it from first hitting the features.
This would quickly be followed with the ol' "Does this rag smell like chloroform to you?" and some sub-conscious (unconscious) hypnosis technique. If you have the flashy-thing from Men In Black, you can use that instead of chloroform.
Edit: after reading the other responses, I think I have a better one:
There's a TDD principle: Write just enough code to pass the test
Look for code above and beyond the spec (i.e. anticipating future expansion of scope), in any method. Similar features like generalizing cases with only one concrete implementation are also signs. TDD shouldn't have such things.