Designing applications "schema first" is a disastrous technique which will trigger the architecture astronauts in every developer. With your set of interview questions, you could very well miss a really skilled programmer because he or she understands that keeping stuff simple is hugely more important than not having denormalized data in the database.

Data point. This problem was suggested because one of the developers wrote that exact application as a weekend project, and that was exactly how he designed it - schema first. He noticed that it was both simple and interesting, and therefore was a possible fit for interviews.

The right answer to all those questions are YAGNI and KISS. :)

Believe me, I'm aware of that. Our favorite interviewees had answers with both of those characteristics. However a major source of real life complications is when YAGNI turns into, "oops, we did need it". And we were actively looking for how people handle that transition, so we asked the questions anyways.

Interestingly, the right brand of KISS made that easy. But that is a different topic...

But those answers aren't valid so the questions seem to be rigged against the candidate as in "come up with a schema similar to the one I would have designed - not more complex than that and not more simple".

ALL interview questions are "rigged against the candidate". You know them, you know how they work, the candidate hopefully does not. The goal is not for the candidate to get the "right" answer - it is to see them exercise their skills. This is doubly true of open-ended design questions, which this definitely is.

I've seen way to many situations in which developers or other persons tried to design a complete schema in which every thinkable and unthinkable instance where covered. Which leads to an incredible amount of work implementing the application that is to use that schema. The more complex the schema, the more complex everything around it has to be which exponentially increases the amount of bugs.

Absolutely. One goal of this question was to identify and reject that kind of developer. I think we did a pretty good job at it.

Designing applications "schema first" is a disastrous technique which will trigger the architecture astronauts in every developer.

You apparently know only incompetent developers.

My experience is the exact opposite. Competent developers will come up with simple schemas that solve the requested problem in a straightforward way. Furthermore when you're given a complicated spec for something you're supposed to build, the act of trying to lay out a schema for that spec is an excellent way to smoke out inconsistencies and hidden assumptions about how the application is supposed to work. Taking these back to the product manager lets you clarify things before you start writing code.

Once that is sorted out, you have your data store designed, your front end in the spec, and a pretty reasonable idea how every layer between is likely to work. Finishing off a basic CRUD application from there is fairly routine.

With your set of interview questions, you could very well miss a really skilled programmer because he or she understands that keeping stuff simple is hugely more important than not having denormalized data in the database.

ANY set of interview questions is going to miss some really good programmers. For that specific team, the ones missed would generally have not been a fit in how that organization worked.

The relevant facts are that there are teams. There are players on the teams for a period of time. Teams meet on particular dates and play games. In each game, a specific set of players are present. Each player does things that are tracked (comes up to bat, hits home runs, etc).

This is enough domain information to solve the interview question.

But this is a good one as well.