Training Badge
Submitted by DeveloperManager on


Hi All,

This is not particular to developer interviews, but we have a position open for a developer, and recently sitting in an interview with my Senior Developer I was struck by our questions and was hoping to find a way to improve them.  The problem is the questions my developer asked were technical, almost textbook.  Questions like:

  • What is the difference between “constant” and “readonly” variables in C#?

To be clear, this is how we've always done interviews.  They’re the kind of questions my Senior Developer was asked by me when he interviewed here, so he is just carrying our practice forward.

The problem I'm wrestling with is that we have interviewed people who knew some of the answers, missed questions and would perhaps get a C if we scored it like that.  This doesn't necessarily mean this person is going to be a bad programmer. 

I'd like to find a way to change our interviews to a format where we can glean some idea of the person's aptitude.  I am all for hiring someone who needs some coaching or classes to come up to speed, but I've also errored in this in the past and hired someone who was a great culture fit and eager, but just couldn't pick up the technologies we used no matter how many courses, classes or conferences we sent him to.  In the end we let this person go after 18 months of working with him.

One thing I've considered is when someone doesn't know the answer, giving them the and then asking a follow up question about the same topic to see if they could apply the concept or understand why you would use "readonly" instead of "constant" to use the above example.

Any feedback or advice is appreciated. While we have hired good developers with our current system, but I'm convinced we can improve our approach to catch some of the potentially great employees who we may missed in the past.




talJoffe's picture

This is how I interview developers (I'm an RnD team manager):

start with asking him/her to describe an interesting project/feature he/she worked on.
I use probing questions to understand what was their individual contribution. How they came up with the
solution, what would they have done differently in hindsight etc.

The goal here is to see level of understanding and impact in previous job.

I follow with a fairly straight forward white board coding question "return permutaionts of string".
Here I see problem solving skills and some coding practices (styling, is he/she testing the result etc.)

For there I continue to use this piece of code as an setting stone to a new application and ask question on how to 
Structure the server, how to optimize data base access, possible volnurabilities, caching mechanism etc.

Here I see familirarity with design consideration that are required for the position I'm interviewing for (Back end developer).

The 3rd part should be replaced with something that represents the day to day tasks I would expect the interviewee to tackle if accepted.


Another important thing is to do phone interviews before in order to filter out irelevant candidates.
Here I focus on asking what the interviewee is looking for and what I'm looking for to see there is a match and continue to ask a few simple technical questions (the kind you can google for like "10 C# interview questions you have to know"


In my firm we also do a coding test (on a laptop we provide) for about 3 hours, behavioural interview with HR (I sometime join) and Manager interview with Group manager (I join if not been to at least 2 other interviews).

From listening to the podcast episodes about interviewing I think I'm using the manager tools recommendations

NLewis's picture

When we interview for my department it's a three-stage process.  The first is the phone interview.  If they pass muster, we invite them in for a standard interview and a written skills test.  Mixed into the test are a series of questions designed to gage other aspects of the potential employee.  For example, "Name five current (Our Company) employees and tell us a little about them."  or "Please hilight the answers to the following question in yellow."  We do not provide a hilighter.  

We have hired people with less technical experience who demonstrated a propensity for solving problems, networking, and other key skills.  We've been very happy with the results so far.  

keilecpod's picture

Sometimes, as you have already told people with less technical experience, they may be inclined to solve problems that could not be solved by the experienced, the main thing is to ask the right questions.

G3's picture

I'm wondering if you've considered this: