A feature suggestion from me: - Allow the recruiter to decide what he's looking for in the code. e.g. Complexity / Efficiency / Clean maintainable code / OO Pr

A feature suggestion from me: - Allow the recruiter to decide what he's looking for in the code. e.g. Complexity / Efficiency / Clean maintainable code / OO Principles, etc. The biggest problem I have with job interview style 'coding puzzles' - is that the code that is optimum to solving the solution is actually not code I would want to write day to day and wouldn't be code I would want to work with day to day. The reason is because in my line of work, we are working with good clean, maintainable code, using good OO principles. This includes naming of variables, naming of functions and accounting for extendibility and maintainability from the ground up. However, most of these coding puzzles, will be looking for people to write the 'simplest' / 'most elegant' solution to the problem, often leaning towards efficiency or using the least number of lines / characters. For example, the variables will be 'x', 'y', 'a', 'b', everything will be manipulated through integer 'index' and complex reg exp's may often feature as short cuts to longer code. - Now there's nothing wrong with the solution this produces. However, overall coding style I prefer is maintainable and easily readable. Variable names have meaning, we work with concrete objects and each piece of complexity is broken into separate functions / classes. Neither solution is wrong, but the approach to either is completely different and for a interviewee it's often hard to know which path I should be treading when writing the sample code. On the one hand, the interviewer may think I lack any forethought of maintainability / readability, if I just hack together something quickly using single character variables. On the other hand, the interviewer may think I'm adding too much bloat / taking too long by using full naming and creating my objects to handle what I want to achieve.