Some thoughts on interviewing

I am interviewing candidates for two Application Engineer positions at Ning, and there are a few thoughts that come to mind as I have been doing this.

I'm looking for two things when I look at a candidate's code: style and substance.

Regarding style, is the code clear, well-documented, unit-tested (ideally) and maintainable? Is this candidate's code going to be pleasant to dive into and maintain, or is it going to be a mess of logical spaghetti that's going to be a headache to modify?

Regarding substance, does the candidate have deep knowledge in some area that they can bring to the team? Things like Computer Science knowledge, Unix knowledge, OO expertise?

I am coming to believe that a good grasp of English grammar is quite an asset. If you know what a noun and a verb are, you know what I mean when I say that good object names are nouns and good method names are verbs. And, funny as it sounds, I am a believer that good names are the heart of a good design. If you have well chosen names, your design can scale in size to a large codebase; not to mention, good names are a sign that you are thinking clearly.

I also believe that adding doc blocks to every class, method, field, and constant is very helpful to future maintainers (including yourself). This seems to be contrary to majority opinion – most programmers are of the opinion that well-chosen method names are enough. However, I would much rather make modifications to a class that is documented throughout than one without any doc at all. A well-chosen name is good, but accompanying documentation is even better. Sometimes a phrase won't do – you need a sentence or paragraph. Look at the Java SDK documentation – every class, method, and field is documented – it's great. In response to the objection that the doc basically repeats the function name (/** Gets the color. */ for getColor()), see "the ideal comment" in How to Write Doc Comments for the Javadoc Tool for ideas on how to make comments more helpful.