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.