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.


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.

  • 1
    @CodexArcanum - That isn't entirely uncommon, some larger companies will have the possible subordinates of a higher level candidate as a part of an interview panel.
    – rjzii
    Commented Nov 11, 2010 at 14:48
  • 1
    Its a small company with a small IT staff. We're hiring someone for a year or two to help with developing software to replace our existing one, not necessarily as a permanent employee. Doubt they'd replace me since I know their business fairly well and they like my work, but even if they did, I'm confident I can find another job. Also, they're willing to pay the new guy quite a bit more then me and doubt they'd replace my salary with his/hers.
    – Rachel
    Commented Nov 11, 2010 at 15:00
  • 2
    Ask them to explain something you have problems understanding in a way that you can understand it. Just don't tell them you have problems understanding it. :)
    – snakehiss
    Commented Nov 12, 2010 at 9:49
  • 5
    There may be some discomfort here on either side. Use it to your advantage. A great hire for this role will be someone who can mentor you while respecting you; who's open to the fact that you may know more about the situation even if you have less experience in general; with whom you can build a good relationship. If you're getting bad vibes -- patronising, sycophantic, disrespectful, "you don't really matter" -- then you probably don't want to work with this person.
    – poolie
    Commented Nov 23, 2010 at 22:53
  • 1
    @Thor, I added an update
    – Rachel
    Commented May 1, 2011 at 18:42

12 Answers 12


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.

  • 27
    I used up all my votes, but -1 for expecting free consulting and +1 for generating a list of problems.
    – Josh K
    Commented Nov 11, 2010 at 14:15
  • 16
    You could present interesting problems that you have already solved and see how his/her solution compares with yours. Of course, it might not be better since he didn't have as much time to think about it, but just seeing how he/she goes about it will tell a lot.
    – mbillard
    Commented Nov 11, 2010 at 14:19
  • 27
    An experienced person will see the 'free consultancy' a mile off and this will harm negotiations. There are several companies in the industry that have a reputation for making candidates do week-long projects as part of their interview process and then don't hire them, but often implement their suggestions. Commented Nov 11, 2010 at 15:20
  • 6
    @JBRWilkinson - I don't think anyone is suggesting week long projects, I think they're suggesting interview questions based on the sort of problems the team are currently facing. That's perfectly reasonable, after all, they're the sort of things that if they were in role at the time of interview they'd be expecting to contribute towards. Commented Nov 11, 2010 at 16:24
  • 3
    @JBRWilkinson An experienced person will see the 'free consultancy' a mile off and this will harm negotiations. I strongly agree. The Free Consultancy scheme is awful and unfortunately not unheard of. Commented Nov 11, 2010 at 16:57

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.

  • 2
    That's an interesting take on it. I generally view my age/inexperience as a disadvantage so its interesting to see how it could be turned around to my advantage
    – Rachel
    Commented Nov 11, 2010 at 17:40
  • 16
    It is expected that you will quiz someone in an interview; you don't need to lie and say that you've never used a technology in order to ask them those same questions. e.g. "I see you know $technology_x. Could you give me an overview of it, why and where I would use it, and an example of how you've used it in a project?"
    – user21007
    Commented Apr 30, 2011 at 3:41
  • 1
    Yeah, be honest. Don't say you've never used something before if you have. Just ask the question. I think what LGriffel is trying to say is catch them off guard. Place yourself below them, so they become over confident. If they really don't know something, it will show quickly.
    – d-_-b
    Commented May 2, 2011 at 3:37
  • This seems to go hand in hand with one of Einstein's quote: "If you can't explain it simply, you don't understand it well enough." It seems the candidate would be forced to state things simply and abstractly and be patient to explain something to you. All these are skills that you really want a senior developer to have.
    – c_maker
    Commented Jun 13, 2013 at 10:58

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.

  • 51
    This. "N years experience" only occasionally means "Really good programmer". The biggest idiot on my current team (I didn't hire her, incidentally, she was there before) regularly boasts about her 20 years of experience, then goes on to say things like "Source control always hurts developers". That's not to say that there aren't salty old hackers whom I'd love to work with, but I'm less impressed by their year count than by their knowledge and reasoning skills.
    – Inaimathi
    Commented Nov 11, 2010 at 14:59
  • @Inaimathi this deserves 1000 upvotes :-) Commented Nov 11, 2010 at 16:23

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.

  • 1
    +1 (votes man!). You aren't looking for a magician in a senior programmer, you're looking for someone who you can mentor and help less knowledgeable programmers. If they aren't good at transferring knowledge they won't be good at the job.
    – Josh K
    Commented Nov 11, 2010 at 18:43

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.


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.

  • That's actually one of my concerns... how being interviewed by someone obviously their junior will affect the interview. I'm young so there's no way I'll be able to fake having a lot of experience
    – Rachel
    Commented Nov 11, 2010 at 15:51
  • 1
    @Rachel - some of my interviewees had been working in the industry since before I was born. I usually found the best way to calm the nervousness after step one was to skip to step 3 and get the candidate comfortable talking about his or her strengths.
    – justkt
    Commented Nov 11, 2010 at 16:04
  • 4
    @Rachel how being interviewed by someone obviously their junior will affect the interview if they can't cope with that, they are no good Commented Nov 11, 2010 at 16:22

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


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.


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.


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

  • 2
    +1 for "don't pick someone who knows all the answers but can't teach". That's a huge factor for me as I always want to keep learning
    – Rachel
    Commented Nov 11, 2010 at 17:38

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.


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.

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