Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've interviewed a number of candidates for salaried positions. I was recently informed that we are hiring a consultant for a few months to help us develop a native iPhone application. We are a .NET shop and none of us have any experience with iPhone development. I've also heard rumors that we are planning to hire more consultants in the future to help develop on other various platforms.

How should I interview these consultants, considering that I have no experience with this type of development? Without regards to platform specific questions, what are the things I need to keep in mind when interviewing consultants?

Normally when I interview candidates, I'll ask questions that I know the answer to. I would never ask a candidate something that I don't know how to answer. Since this is a different situation, what do I need to ask in order to make sure they are subject matter experts in their respective fields? Is it appropriate to ask specific questions that we'll need to eventually solve during the interview?

share|improve this question
add comment

5 Answers

Hmmm, tough situation.

I think I would primarily focus on general problem solving skills and attitude. Asking the candidate to write code for a couple of general (non API specific) problems in a language both of us know, or even in pseudocode can quickly weed out the inept. And if we see that (s)he thinks clearly and writes clean code in one language, chances are that (s)he will produce the same quality in others too.

The other kind of questions would be open ended ones about his/her career and projects up to now, digging deeper at interesting spots. These can be good to smell any possible inconsistencies/exaggerations in the candidate's CV.

Fair enough, none of this proves that the candidate has the required experience in iPhone development. But if (s)he seems to be factual and correct in areas I know well, IMHO there is a higher chance that (s)he is not boosting about skills/experience I can't directly verify. Also, in an open ended discussion I can detect whether or not (s)he is genuinely interested about the subject and committed to deliver quality work to solve clients' problems, or just spending the minimal expected effort on tasks to rake in the cash.

share|improve this answer
add comment

In my experience, it's best to treat an interview as if you're just having a conversation about technical topics. You can tell a lot about someone's skills just by talking about general topics that should be known to any programmer.

For instance, you could start by talking about version control. You can learn a lot about whether or not you want this person working with you based on their feelings and knowledge about the subject. Would you really want to work with someone who felt that version control was stupid if your employees all agreed on a set standard for how often to commit and what to commit. If using version control isn't something they consider a requirement, then that tells you volumes about their value to you.

Many of the concepts in different languages are similar. For example, both C# and Java have concepts of reflection, inheritance, abstract classes, garbage collection, polymorphism, and many others. Pick a few of these topics and discuss them. Keep in mind that it's less important to look at right vs. wrong answers if you're a Java programmer talking to a C# programmer as there may be some slight differences you're not accounting for.

But do look for gross inaccuracies in the person's thought patterns. If they describe how they use inheritance and polymorphism all the time but their resume shows only small projects, perhaps this suggests a penchant for over-architecting the projects.

I strongly feel it's important to trust your gut. If your gut tells you no, then say no. It's also helpful to have a second, third, or even an Nth opinion. Let other team members come in and do interviews as well with the contractor. Trust your team to give you good feedback on whether or not to hire. Your team isn't going to want someone working with them who they either don't respect or who will create problems.

Last but not least, use pseudocode. Ask the candidate to do some programming exercises, but make it language agnostic. This puts you both on a more even playing field and eliminates syntactic details that the compiler/interpreter will handle anyway.

share|improve this answer
add comment

I like this question. Obviously, the situation is not easy, since you can't evaluate correctly someone in a domain/language you don't know well.

I often see HR people (alone) interviewing developers, and it always surprises me how bad are their interviews. Your case is different: you are already experienced in .NET; all you lack is a deep knowledge of iPhone development.

1. General skills evaluation

I suggest to try to determine less how good an interviewee is in iPhone development and more how good she is in general programming. For example, you can ask very general questions which can be solved in most programming languages, and listen about the language-independent solutions proposed by the candidates.

As an example, here's a question (no time limitation) I asked to my last interviewee (I'm a .NET developer, while the candidature was for a PHP programmer):

Taken a valid XHTML code as a string, you must minify it by removing every meaningless whitespace (for example, see the raw HTML code of Google home page). What will be your approach(es)?

Here, I don't care if a person has a deep knowledge in PHP. What matters is that this person can solve a not-so-simple problem like that, and especially find quickly one or more correct solutions in a context of stressful interview.

  • If the person doesn't find anything, well, it's bad. It means that the candidate would probably take too much time finding right approaches at work, or will start coding before thinking.

  • If the person says that this can possibly be done with regular expressions, it means that she knows what regular expressions are, and probably has some knowledge in general programming. I consider this answer valid, even if using regular expressions in this context is totally wrong.

  • If the person says that we need to parse the code, build an XML tree, and then output it, trimming different parts, there are good chances that even if this person lacks some knowledge in PHP, she will learn fast how to use it and become a valuable employee. At least she takes care of listening the details of the question, makes difference between HTML and valid XHTML and probably knows why regular expressions must not be used in this context.

Finally, remember that there is no such a thing as a "good developer in [put language here]". If a person has general development skills, is good at communicating her ideas, documenting code, using SVN, etc., even if she doesn't really know a certain language, she will learn it quickly.

2. Previous projects success and contractors satisfaction evaluation

The problem is that the previous approach fails when you need somebody for a short period of time. As an employee can spend a few weeks improving her knowledge in a precise language, you can't afford a consultant spending weeks learning things if you need this consultant for a few months.

In this situation, I don't see any magical solution to use during an interview. In order to evaluate the skills of this consultant, you must be an expert in the language, or to hire an expert to evaluate the consultant. But, of course, to hire an expert, you must first evaluate her, so you need to be an expert or to hire another expert before, etc.

On the other hand, instead of asking technical questions during interview, you can probably ask the consultant about her previous missions and projects, then contact the companies which used to work with this consultant and ask them their opinion about the real development skills of the person.

Also, just looking at previous projects can give you an idea of her skills. It's very hard to do, but remains possible, especially for large projects. A good developer with no skills in a precise language will have some pain to build a large projects: while she will achieve with ease basic things after reading a few pages of a book/manual, the things will start getting harder for something less basic.

Imagine, for example, a good PHP developer who just started to learn C#. She will probably miss the point of delegates, lambdas, etc., or use them as if it was a sort of PHP lambda functions, which is much more limited and ugly than in C#.

Another example: if C# has garbage collector, why do we need to use using around classes which implement IDisposable, and what is the difference between disposing and finalizing an object?

There are also points that the person will not understand well. Why:

string name = this.Person.FirstName;

may fail with a weird exception, whereas:

string name = this.Person == null ? string.Empty : this.Person.FirstName;

will work fine, for example?

3. Knowledge of language tricks evaluation

Before looking at previous projects and contacting previous contractors, there is another thing you can do. On StackOverflow or other websites, there are frequently people speaking about some nice tricks to use in a language, a sort of things the beginners don't know. You can use those discussions to prepare interview questions.

Since it may be not very clear, here's an example for JavaScript. I don't know JavaScript well, so if one day I will interview a JavaScript programmer, I will probably use those tricks, among others, to see if the person knows the language.


The three points above are equally important. You can't hire somebody because she solves problems fast, or because she achieved large projects successfully in the past, or because she masters the tricks of a language. Use all three, and you may have a more or less precise image of the skills of a candidate in a language you don't know well.

share|improve this answer
Normally if I'm interviewing candidates, I wouldn't mind if they didn't have a deep understanding of a particular technology or language. But in this case, I do care because this consultant is only going to be around for a few months. We need him to be an expert that can get things done, not fumble around and try to pick up things. –  SkyOrg Feb 5 '11 at 21:36
@SkyOrg: I understand better the issue. To address it, I added some information to my answer. –  MainMa Feb 6 '11 at 11:20
add comment

Here are some ideas.

Instead of asking about technical aspects where you would know the correct answer, try asking more process-oriented questions, e.g. "How do you ensure that the delivered software is bug free and working according to specification". If the consultant starts talking about test driven development, and acceptance tests being formed in a collaboration between you and the consultant, you should get a nice feeling. If he answers something in the lines of "I rarely make bugs", then I would get nervous.

Another thing to try is to search the net just to learn about some of the obstacles/pitfalls of iPhone development (here is a free one, the iPhone doesn't have garbage collection, so you must follow some standards to keep make sure memory is freed correctly). So fire some question like, "I can understand that there is no garbage collection on the iPhone, how do you ensure that the app doesn't leak memory". If the answers seem reasonable, and he is good at explaining the concepts, then there is a good chance that he/she is a good iPhone developer. Hopefully he'll also mention something about tools to detect memory leaks ;)

share|improve this answer
add comment

TwoThree suggestions:

  1. ask the consultant enough general questions to determine if they are qualified to write code, and have a personality that you can work with. Then bring in someone else to grill them on the technical development details of the iPhone platform (if necessary).

  2. or, give them the specifications for the application and ask for a flat bid, timeline, and deliverables (features/artifacts) for each iteration

  3. do both of the above. Pick the one you think you can work with that did not get upset by the second question.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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