How do you interview someone with more experience than you? [closed]

Question

The company I'm working for is looking to hire a senior developer with more experience than me, and they expect me to do the technical part of the interview. I've only been programming a few years and am not sure I have the knowledge needed to evaluate the coding skills of someone who has greater understanding/experience than I do.

Can anyone recommend some technical interview questions to ask that are a good means for evaluating higher-level programming skills, but still be ones I can understand?

I would say I'm past the jr. programmer level, but nowhere near senior. Most of what I've done is built small apps (web and desktop), some of them fairly complicated, but all of them have been meant to be used by no more then a handful of users. I feel I have a decent understanding of most programming concepts and am capable of learning/teaching myself just about anything, however I lack experience. As my boss is fond of telling me, "You don't know what you don't know".

In particular, things we'd like the person we hire to have experience with (that I don't have) is: Multi-tier development, multi-user environment, large-scale application development, two-way messaging, shared sessions, and Multi-threading/BackgroundWorkers.

UPDATE:

In response to Thor's comment below, we hired someone a few months ago and I think it has been working out great. I am learning a lot, not just about coding but also about things like design patterns, software architecture, documentation, and how other larger programming teams get stuff done. Its not always easy having someone come in and point out better ways to do things you have done, but if you can swallow your pride and be willing to try out new things you can learn a lot.

The interview process went better than I expected. I started asking questions about things I was familiar with, then asked some questions about some things I was struggling with. Whenever the interviewee said something I didn't understand, I'd ask them to explain it to me and then write it down so I could look it up later on. Overall, I felt I was able to get a pretty good idea of the applicant's skill level, intelligence, and what they'd be like to work with.

Answer 1

You can't.

Instead, I would suggest you to come up in the interview with a list of problems you have today, and ask him how he would solve them.

This a is very interesting method for the following two reasons:

1. It is free consultancy. Even if you don't hire the guy, he may suggest nice solutions to your problems.

2. If he comes with interesting solutions, he is a problem solver. The kind of guy you want to hire.

Answer 2

Use your age as an advantage.

I've interviewed a ton of people who are older than me. I pick a technology that I do know pretty well and tell them that I've heard of Technology X, but never used it. I ask the candidate to give me an overview of the technology and how they've used it in a project.

This works surprisingly well. First of all, if the candidate is only using that Technology X as a buzzword on their resume, then their explanation will suck/not make sense. Also, if they can't give you a good, concrete example of how they used a that technology in their past projects, you have a big red flag right there.

I interviewed someone who had java Spring experience. I had used Spring in my previous job, and one of the big features of spring is Dependency Injection. I told the candidate I interviewed that I had heard about Spring and never used it. He started blabbing on and on, but couldn't tell me where he had used Spring AOP and couldn't explain Dependency Injection to me, even after I explicitly asked after seeing those things called out on his resume. He just told me that they were really cool, and there's so much to learn out there, etc, etc. It really turns out he didn't know jack...and I was the only to figure that out b/c I was a younger member of the dev team.

So use your age as an advantage! Go in, be confident, and ask some questions about technology you know well.

Answer 3

Remember that just because they have more experience than you, they may not be be a better developer than you. The phrase "One year of experience repeated n times." comes up because you do see this happen in industry. Thus, your first task during the interview should be to establish that they do indeed have the relevant experience and can present themselves as someone one that knows what they are doing. Likewise, just because someone has had n years of experience in industry, it doesn't mean they have a ton of experience in a given language, library, or framework so they might still come to you from time to time asking questions while they are learning something.

Next, remember that a good senior developer is someone that you should be able to approach and asking about something that you have having problems with. This is a good time to asking them some design questions that you have had problems and see how they response and what their reasoning is in their explanation. Have they seen something similar before somewhere else, are they making an educated guess based upon experience, did they read an article online or in a journal?

Finally, another thing to look at is how they approach debugging code. In my own experience, I have found that regardless of the language, certain debugging techniques tend to be applied universality. Given the candidate an example of one of the more esoteric bugs you have encountered and have them walk you through how they would approach the bug. Do they have some insight into the problem that is not immediately obvious?

In summary, interviewing a candidate with an impressive interview can be intimidating, but there are something that you need to cover regardless of what level they will be (i.e. do they actually know what they are doing) and once that is complete you can start probing them to see how they are applying their experience. How the candidates are applying their previous work experience is going to be what is going to make one candidate standout more than another.

Answer 4

I like the Use your age as an advantage answer very much, and I would suggest something similar:

Use your lower level of experience as an advantage

This person is probably going to be your boss or mentor, so ask questions in a way that lets you find out if that person can actually mentor you.

Ask complicated questions that could be made a lot easier, or that include over-complicated problems. If he / she is any good, he / she will not only solve try to answer the question / solve the problem, but actually get to the real problem, showing you the flaws in your question. If he / she manages to do that in a polite way without intimidating you he / she is a keeper.

Answer 5

The really significant thing is that you make sure he is the right kind of experienced developer for what you need.

As people move on through their careers they tend to go in different directions in terms of what they do. You may be interviewing people who are experts in running large teams of programmers or working with convoluted legacy code and quite brilliant at what they do without them being the person who is right for your role. So try have an idea of what exactly you are looking for in advance and think of questions that will differentiate exactly the kind of developer for your job from other people.

Answer 6

I've had to do this several times. I learned to do it in a step-wise process.

1. Start out with the same questions I give to the college grads. I did this because the position I was doing the technical interview for was a programming position where we expected the developer to be hands on in the code, and I wanted to make sure the candidates could program. With only one exception none of the candidates could - they were worse than any of the college grads. All of them had been in managerial positions far too long.
2. For the candidate who passed a basic coding competency test, I had some more general "how would you handle X scenario" kinds of questions. If you are doing web services in your project, for example, think of an interesting web services question and ask the candidate how he would solve it. I wouldn't recommend that this be something you are currently working on directly, mostly because of the issue of intellectual property and company proprietary data. Don't give that stuff out!
3. Spend time asking the candidate about stuff on his or her resume. This is important. You can find out about his or her best and worst team experiences, experiences as a supervisor, and so on. Try to get a feel of the person's working style to see if he or she fits into your team.

My biggest issue when interviewing senior candidates was that they often got very nervous to be interviewed by a junior person, especially those who couldn't handle my basic coding tests. Try hard to seem non-threatening in any skills you show throughout the interview - focus it on them, even if they can't answer your questions well. Try and skew the interview to questions they can answer if they fail on the basics.

Answer 7

In terms of the actual interview process, fundamentally you treat them the same as any other person you're hiring. There should be a similar hiring process:

1. Selection, by CV or agency recommendation.
2. Aptitude test (combining things like FizzBuzz, strdup()/isAlpha(), OOD, etc)
3. Telephone interview (for quick elimination if they don't communicate well)
4. Face-to-face interview
5. Written coding exercise
6. Meet some of the team members.
7. For an experienced person, which implies higher risk and higher costs, additional rounds of interviews are acceptable but you should clearly communicate to them where they are in the process (i.e. this is 1 of 3 interview rounds).

There are many other posts on this site which cover general topics of discussion that you should cover in the interview process - here's my answer to one of them.

At all points in the interview process, an experienced person should demonstrate an excellent understanding of their advertised specialities. You can probe them, in a lot of depth, on any topic that you cover during the discussions. Take questions to the limits of your experience/comfort level and see if they can continue without worry. If you need to go off the deep-end with something you haven't got much experience with, do a web search for some sample questions (get a selection of them), read and understand the answers before the interview, and then ask the candidate any of these questions. Don't expect them to know all the answers, so have a selection of questions.

There are two types of experienced engineer you could hire:

1) Relevant Industry Experience

This is the person that you can take your list of current problems to and talk through how they might approach those problems. You should be gauging their level of understanding of each of the domain-specific topics in your industry. As you're in that industry, you can tell a 'dumb' answer from a 'good' answer and can probably spot an 'experienced' answer too. In contrast to other answers, I wouldn't expect them to actually solve your current problems - that will happen when you hire them - but you need them to convince you that they could once they got started.

2) No relevant Industry Experience

So this candidate is possibly changing industry but has good experience in the foundation technologies/platforms/skills you need. Go deep on those items, but don't expect them to be able to come up with solutions for domain-specific problems, although you could just talk around them. For example, if your company is Facebook, and the person you're interviewing is hot with PHP and C++, it would be unrealistic to expect them to know all the pitfalls of massive server farms (unless they claim it on their CV).

Answer 8

A thing I did not see explicitly pointed out, is "You know technology X very well, and it sounds very interesting. Could you please explain it to me in five minutes?"

Since you will most likely be expected to be able to maintain the code eventually coming out of the new person, it is crucial that he or she is capable of explaining it to other programmers efficiently and well. Consider it to be communication skills.

A thorough understanding is necessary to be able to meet any other developer on their skill level and communicate thoughts and ideas on their level.

If the person cannot communicate verbally, he or she most likely only write the code for the compiler, not for the maintainer.

Answer 9

I agree with Steven about mentoring part. In fact I would say that you can ask him/her questions about what are his/her views on mentorship and how does (s)he go about it in different scenarios. Then evaluate based on the answer (you can get feedback from your boss if you feel like it or discuss the actual answers in the debrief).

You can also ask questions you would ask a peer, as the candidate should probably be able to solve or at least understand your work.

Answer 10

definitely pick his brain in the interview on real problems and technologies that you currently have or intend to use

assuming he/she is a competent and imaginitive senior developer, decide to hire or not based on if you think you can learn from him/her and work well with him/her

you're not interviewing your future boss, you're interviewing your future mentor. Don't pick someone who knows all the answers but can't teach

Answer 11

Take a bunch of the problems you have already solved. Describe to him what was done to solve the problem (keep it third-person; you don't want to put your personal ego at stake here). Ask him what he would have done "differently". You should be able to, based on what he is suggesting, figure out if that would have been better or worse, conceptually, than what you did.

Answer 12

I seriously recommend you to read the book "Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent".

I never hired anybody, but sometimes when I was the interviewee, I was wishing some idiots that only know about buzzwords and were interviewing me, have the reasoning line exposed in that book. The text is very fluid and a pleasure to read.

And no, I am not making an advertisement only because this site is from the author of the book. The book is really great and I will recommend it to anybody who is in a position of hiring IT people, specially to who doesn't understand the technology - Nowadays it is very common to have a non-technical project manager or boss.