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.

comments powered by Disqus

Did you know?

I'm a software engineering consultant. This means I can help your company with your software engineering needs:

  • providing temporary manpower for short-staffed software projects

  • helping new software projects get off to a good architectural start

  • improving the performance and reliability of old, legacy software systems

  • doing an important investigation or small project that you've always wanted to do but haven't had time for

Since 1999, I have done software engineering projects for the Canadian government, for Silicon Valley startups, and for established Bay Area companies, for small companies and medium-sized companies, for successful commercial projects and open-source projects. 

Currently accepting small projects. If you have one, email or call me.