I think it's a terrible question. I think any question is a terrible question when the real answer is "Run it and see!"
If I needed to know this in real life, that's exactly what I'd do: Create a test project, key it in, and find out. Then I don't have to worry about abstract reasoning or the finer points in the C# spec.
Just today I ran into such a question: If I fill the same typed DataTable twice with the same row, what will happen? One copy of the row, or two? And will it overwrite the first row even if I've changed it? I thought about asking someone, but I realized I could easily fire up a test project I already had that used DataSets, write a small method, and test it out.
Answer:
...ah, but if I tell you, you'll miss the point. :) The point is, in programming you don't have to leave these things as hypotheticals, and you shouldn't if they can be reasonably tested.
So I think it's a terrible question. Wouldn't you prefer to hire a developer who'll try it out and then know what happens, rather than a developer who'll try to dredge it up from his fading memory, or who'll ask someone else and accept an answer that might be wrong?
