1. How is a small team of programmers to know that you will be able to collaborate with them effectively within the space of an interview ?
2. What exactly do you mean by "competitive problems" or "puzzles"? What is off-limits?
I am asking 2. to identify what you mean by a puzzle. For example, let me take the substring matching problem. There are a ton of ways of doing those which for me traverse the realm of being both puzzles and also in some ways important computer science questions [1]. You could do brute force. You could have a moving hash window and use that to check if the substring is present. (Sort of Rabin Karp). You could build a trie called a suffix tree. Now the way intuition works (at least for me) is that you either know how to solve it, and then you sort of recollect the details in a few minutes. Or you have no idea of how to do it and probably don't know how to create a solution like that unless it was super critical that you go figure this out. And the problem is that the real world never throws things straightforward at you. Curveballs at least in the engineering world require transforming previous solutions into something new. So unless you grok trees, how will I know if you really will be able to spot that a random problem is just a tree problem with some modifications and then go ahead and implement it, instead of say spending a few weeks refreshing graphs.
[1] http://cstheory.stackexchange.com/questions/19759/core-algor...