Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > Personally, I'd rather see how a potential hire *tests* his code than how > he writes it. Writing code is easy. Testing code is harder. Testing it > properly is harder still -- it's amazing how many people forget that it's > not just necessary to test the function on data that *works*, but also on > data that fails as well (unless, of course, you're happy with function > behaviour that is unspecified in the face of errors). > > I also want to see when the coder thinks she's done.
Perhaps I'm reading more into your choice of words than you intended, but I'm curious what you envision a "coder" does. I think of "coder" and a rather low-level job. Somebody who just writes code. I'm generally looking for somebody who is more of a software engineer. Somebody who is not just writing some code, but who is building a product. That means, as you suggest, that it's documented, tested, robust, maintainable, portable, all that good stuff. > If I say "Write a function that does fizzbuzz", does she assume I > want *just* the function, or does she ask questions like "Do you want > documentation and tests? What sort of tests?". I think this depends on the situation. For writing code at a whiteboard while i watched, I'd expect the candidate to concentrate just on the code itself. If it was an assigment, as in, "Write a program to do X, and mail it to me by tomorrow", I'd expect a much more complete treatment. -- http://mail.python.org/mailman/listinfo/python-list
