10

As a hypothetical, if I were to interview someone for a new PHP developer position when my experience is in .NET, how can I determine if the code sample they've provided me is efficient and of good quality?

In other words, what is the best way to evaluate a programmer's code if you're not familiar with the language?

Improve this question
3
  • 1
    I hate to break it to you, but you don't :-) Include someone in the interview that does know the language or learn it yourself.
    – Joppe
    Dec 8, 2012 at 1:20
  • 2
    This is why interviewing is a team effort. You evaluate that what you're able to evaluate, and defer this sort of stuff to some technical team leads who are familiar with it.
    – Kaz
    Dec 8, 2012 at 1:34
  • For me the best metric is the size of the functions (including here nesting deepness) followed by the size of the classes/files.
    – Random42
    Dec 8, 2012 at 9:45

6 Answers 6

Reset to default
20

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.

Improve this answer
4
  • 5
    Another important one: "Are the comments clear, meaningful, and easy to understand?" Could you learn a little bit about what a piece of code does from the comments, even if you have little exposure to the language?
    – FrustratedWithFormsDesigner
    Dec 7, 2012 at 20:59
  • 2
    @FrustratedWithFormsDesigner - Comments? What are those? Seriously though, code should be self commenting. Comments should only be there to explain the why or give reasons for bad code.
    – Oded
    Dec 7, 2012 at 21:00
  • 6
    I urge extreme caution: it's very easy to end up choosing on the basis of who writes code the most like you're accustomed to, which may well be relatively poor use of that language.
    – Jerry Coffin
    Dec 7, 2012 at 22:15
  • @FrustratedWithFormsDesigner Oded probably thinks you should read this elegantcode.com/2010/04/18/…
    – Joel
    Dec 8, 2012 at 17:18
4

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.

Improve this answer
1
  • 1
    If the candidate can explain their code so that the intent and purpose behind it is clear, and visually, the organization and general structure looks reasonable, they probably have a reasonable grasp of what the code represents. And could likely repeat a similar clean reproduction. Even if particular parts are explained with as little as 'because that's what a particular refernce material showed how to do it', while naming the refernece material, you at least have a modest representation of the ability to not only 'code' but to find and apply solutions to problems they don't routinely face.
    – JustinC
    Dec 8, 2012 at 4:17
1

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.

Improve this answer
1

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 ;)

Improve this answer
1
  • In hindsight, this duplicates much of what @Oded (and the comments) said.
    – frackham
    Dec 8, 2012 at 16:21
0

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.

Improve this answer
-2

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

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.