The definition of gaming the system is different here. These days unless you are implementing a library yourself. You are probably never ever going to even reverse a linked list ever in your life. Or deal sit down with a math text book when you code. Those days are probably gone in the 80's.
That means asking these questions is akin to you taking an approach to judge an candidate on things which have nothing to do his job. That's why so many programmers don't about all this. The reason is for 99% of the work they are likely to do they don't need to know it.
Under such circumstances when you ask these sort of questions the only way candidate can deal with them is not by actually learning how to solve them. But learn them just for the interview sake.
So you end up hiring some one on a criteria doesn't matter. And the candidate manages to beat you by system of work which defeated your original means of judging him.
You could just ask: How is lists:reverse(List) implemented in Erlang, or if you don't know it, how could it be implemented? What are the trade-off and limitations for different implementations?
Since most abstractions are leaky, you can make a good argument, that learning how libraries tick, even if you are never going to rewrite them, is a useful skill.
Understanding the limitations of libraries might help you use those libraries better. Using libraries can be a part of delivering business objectives.
I don't think that list reversal is a good interview question. At least not as a positive discriminator. Though it might help you weed out people: I'd probably not want to hire people who can't figure out how to reverse a list. If they'll stumble upon such a simple problem, they might also stumble over the more complicated problems we have to solve to deliver business objectives.
I wrote `can't figure out' deliberately. Not knowing how to reverse a linked list, but being able to come up with an algorithm after a few minutes thought is perfectly adequate.
I agree with you - it is a weeder-outer, but not an includer-inner - there are lots of people who can write code to reverse linked-lists that I don't want to hire.
In particular I don't want to hire the people who would rather write their own implementation than use a library (think Not-Invented-Here and Yak Shaving).
Indeed. By the way, in purely functional implementations of a list reversal there are non-trivial trade-offs to make. (See Janestreet's standard libraries for OCaml.)
If you don't need to know how to solve algorithmic problems or use mathematics and you're programming, why the fuck is your job still not automated or outsourced?
That means asking these questions is akin to you taking an approach to judge an candidate on things which have nothing to do his job. That's why so many programmers don't about all this. The reason is for 99% of the work they are likely to do they don't need to know it.
Under such circumstances when you ask these sort of questions the only way candidate can deal with them is not by actually learning how to solve them. But learn them just for the interview sake.
So you end up hiring some one on a criteria doesn't matter. And the candidate manages to beat you by system of work which defeated your original means of judging him.
I think this is what gaming the system means.