how can I determine if the code sample they’ve provided me is efficient and of good quality?

The things you will not be able to evaluate are correct use of language idioms and library usage. So, these are not things you should try to look at.

What you can evaluate is:

• How well structured the code looks like
• Well named variables (can you make sense of things)
• Well composed functions/units of code
• Consistency in the code base

The above points (though not exhaustive) will indicate whether the code smells or not and should be something an experienced programmer can identify as being good or bad.

In short – look for things that should indicate good code regardless of language.

Have them flowchart it or walk you through it as part of the interview. You have the perfect excuse to ask and it tells a fair bit of how they think to see how they explain.

If they are going to jump to your preferred language you know you have a lot of mentoring coming so you should be looking for good logic / reasoning skills above all anyway.

If they are going to stay working in their preferred language you are going to have to accept that they will me somewhat self-managing on the finer language specific details until someone else comes up to speed anyway, so all you are going to have to interact with is the design side there as well.

Bone-headed / obviously wrong code aside, efficient will largely depend on the compiler / interpreter of the language in question, and you won’t really be able to eyeball that from a code sample. A code sample could be beautifully written and elegant as fine china on doilies but run slow if compiled / interpreted poorly.

You won’t be able to evaluate idiomatic usage of the languages features / syntactic sugar / conventions without some familiarity.

You should be able to tell if it is well written in general based upon universal considerations such as tidiness, control flow, variable naming, order of operations, and so forth.

However, more practically, if you know what the language is going to be going into the process, you could try to find one or more style guides for that language, go to the book store and flip thru a couple of books for that language and skim the code examples looking for analogs to something you are familiar w/ in your language(s) of choice, check out one or more open source projects that use that language, and so forth.

If you have the time and if there is not a cost barrier, you might even go so far as to set up a development environment for that language and crank out a Hello World app, do a code kata, or otherwise write a simple little app in it. You’ll develop a rudimentary frame of reference pretty quickly and not only will this give you a leg up for the specific purpose of reviewing the code in question, you might be compelled by the language and branch out a bit.

Regardless of language:

• Are there clear separations of concerns, appropriate use of classes
  (for OO languages), or any indications of deliberate attempts to break
  down the code into reusable, modular ‘chunks’?
• Similarly, any evidence of testing – unit testing or otherwise?
• If it’s production code, is it strewn with debug strings that might suggest little separation between development and deployment?
• Does the code follow any kind of naming convention (whether you like that convention or not is immaterial!)?
• If you have the file, rather than a printout, does every function/class in the file relate to the (so if it’s a file called data_access_layer, evidence of functions that process images would probably be out of place).
• Any indications of a lack of trust for user input are good too, especially for web-based languages like PHP. So structures like input = escape(input) at least show you that they’re aware of the issue.
• Comments or self-describing code is always good. There are several schools of thought on the amount of commenting that should be present, but a complete absence of comments
• At the cost of being cynical, I would also google some of the code before the interview. It could easily be a copy and paste job, sadly.

Not saying that any code that doesn’t have all of these is automatically poor, but I’d consider these to be indicators of someone who has reflected on and considered their practice.

However, for all of these indicators, you should ask what the rationale for the code being like that is. There may be a good, language-specific reason for their choices…and after that, google is your friend when they and the other candidates go away, as you can check whether what they said sounds plausible…!

Good luck, as hiring good people is one of the most important roles in your organisation 😉

You should ask someone who knows the language in question to come to the interview or have a look at the sample. Such a person will much more likely find the bad spots if any.

Is the candidate going to be working in a team? Let the team members meet him and ask questions about his skills.

Ask them about the limitations they’ve come across while using the language. Ask them to show you a simple SQL query. Any Php dev worth a hoot should be able to bang out a basic select/update/delete query without too much effort.

doug