We hire based on personality. Before we bring an interviewee in we have looked at their bitbucket, github, portfolio, etc.. By time they get to the interview we know they are good enough to work for us, so we just talk technology with them and gauge based on that.
If the person is inexperienced or does not have a very public profile (no opensource projects), then we will drop back and throw them some random problems to solve but never a puzzle, since most people just memorize the solutions to puzzles or learn the solutions after doing enough interviews.
We prefer giving them problems like writing a text based guess the number game or tic tac toe. Mindless easy to solve project. They could spit it out in the shortest number of lines, which is what the bad puzzle questions encourage, but we are looking for how well the design/architect code. So the person who creates a good class structure and writes tests for his/her game is the one who gets hired, not the person who prefers shortest lines of code.
Well that is unfair. I got did not get an interview at a financial company for this reason. Unless stated explicitly, I'm not going to gold-plate interview code, because my assumption is that you are weeding out people who cannot code.
If you tell me to write it as OO as possible, then I'll do that. But if I can write it in a shorter, more efficient way using only arrays, I'll do that.
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.
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.
"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.
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.
Our interviews are never in the office. They are at a restaurant or bar. We just have drinks and food with them and chat. Talk about technology, them, us, etc... If we can have lunch and drinks with someone and they are talented then they are a good fit for the team.
The lunch/bar setting also loosens the interviewee up and they are always less nervous than if we had brought them into the conference room.
We don't care how talented you are if we can't stand being around you. If we had to choose between a mediocre programmer who has a lot of passion and fun to be around or a brilliant programmer who is arrogant, we'll take the mediocre guy and just train him up into being a brilliant programmer.
You're selecting for extroverts at the expense of introverts. Which may be desirable for your company, but I would (somewhat selfishly) not want that to be the common case.
we'll take the mediocre guy and just train him up into being a brilliant programmer
If you actually have a successful process for doing that, you could be owning many islands.
Its not about introvert vs extrovert, its about passion. I don't think any of the people on my team would do well socially at a bar but you ask us something about Linux, Python, etc and we could talk for hours.
"If you actually have a successful process for doing that, you could be owning many islands."
Don't pull a fox news on me, you can't rip out the most important part of that sentence ;)
If the person is inexperienced or does not have a very public profile (no opensource projects), then we will drop back and throw them some random problems to solve but never a puzzle, since most people just memorize the solutions to puzzles or learn the solutions after doing enough interviews.
We prefer giving them problems like writing a text based guess the number game or tic tac toe. Mindless easy to solve project. They could spit it out in the shortest number of lines, which is what the bad puzzle questions encourage, but we are looking for how well the design/architect code. So the person who creates a good class structure and writes tests for his/her game is the one who gets hired, not the person who prefers shortest lines of code.