[sontek]

We tell them "Write this how you would write a real world application". We don't care if it is OO or functional or whatever... We just care if it is well designed. We don't tell them to write tests but if they don't then that means they don't write tests in the real world either.

[gcp]

There's just too much context missing from what this "real world application" is supposed to be or where its supposed to serve to make the concept meaningful.

What size inputs am I expected to handle? What platforms must this run on? What environment can I suppose is available? What performance is available? What kind of tests does your company use?

I think you're making too much implicit assumptions that everyone is programming in an environment similar to yours if you state it that way.

[sontek]

I described it in my initial comment:

"We prefer giving them problems like writing a text based guess the number game or tic tac toe. Mindless easy to solve project."

Language, Environment, etc doesn't matter. If you are interviewing people on that stuff then you aren't finding the best candidates.

They get to choose everything outside of the problem to solve and it is an extremely dumbed down project like I said in the original comment. The "real world" part is in the implementation... How well is the code architected? Did they write tests? Are there performance issues? Bugs?

We don't expect people to be perfect either, we learn more from the discussion afterwards, since its not a puzzling problem we get to focus on software design and not the problem itself, which we feel is more important.

[aen1]

Why would I write tests for Tic-Tac-Toe? It's insanely easy to exhaustively hand-test, or just look at the code to see its validity. If you expect tests on something that simple, then you're expecting people to waste 1/3 of their time testing code that is sure to work.