... I think if a company asked me to submit a small program that might take up to two hours to create I would actually be pleased...
Quoting Admiral Ackbar, It's a Trap. For two, maybe three, reasons.
1. No question is ever so well asked that there is not wiggle room in a correct answer. Only a complete program spec, covering all situations, is really sufficient. And adherence to a complete spec would take
way too long for a take-home interview question. Language? Platform? Language version? Allowed libraries? Environment assumptions? Compiler? Compiler version? Efficiency? Memory usage? I/O requirements? Naming conventions? Program structure? etc.
2. Regardless of the quality of your coding skills, there is going to be something 'wrong' with it. Every company, and consequently, every technical interviewer, has a different coding practice and different coding standards. If the organization has a coding standard, the interviewer is used to that standard. Deviations from that standard automatically seem conspicuous, even if the code is correct.
E.g., How much error checking is expected? Too much and the code looks overly complicated. Too little, and the code looks careless. What is the company culture about this kind of thing? You, the interviewee, don't know, because you don't work for the company...
3. There is no guarantee that whoever reviews your code knows their @$$ from their elbow in the first place. Its
very common to find that your interviewer knows less about programming (or whatever the field happens to be) than one's self. However, interviews are commonly organized such that the interviewer is expected to be in the position of superiority, both intellectually and otherwise. When those roles are disturbed, people react in funny ways, e.g., with unjust negative opinions.
This point (#3) really only counts for half credit, because it is not specific to take-home coding assignments -- it can happen in any interview -- but a take-home assignment gives the @$$hat interviewer ammunition.
Facebook
Twitter