Confessions of a technical interviewer

Since I started my career as a software developer back in 2003 I have been involved in a lot of interviews in all possible situations.

I was the one who was applying for the job, the one that had a saying in the hiring, the one who took the decision of hiring/not hiring, while at Wantsome.ro, where I am teaching a .NET programming course, I am working with people to help them pass technical interviews.

It shouldn’t happen, but it can get tough during interviews

And I had failures in all situations, in some interviews I didn’t get a job offer even though I believe I was pretty qualified for it, while in some other cases I took wrong decisions and hired some developers I really wish I didn’t. But most interesting I was able to recognize 3 kinds of interviewers. And based on the interviewer type you can find out a lot about the company you are applying to and your possible future colleagues. So let me explain how a junior interviewer behaves and what means to be a senior one, no matter how many years of experience they had in the field of software development.

Junior interviewers

By junior interviewer I don’t mean someone who is a junior developer and also an interviewer. It doesn’t really matter how many years of experience he has, it is more about what he is after during a technical discussion with a candidate.

Now everybody asks the basic questions like OOP ones, framework related, regarding your previous projects and experiences. So it is not about these. Instead the junior interviewer will always look for ways to impress you with his knowledge. He cares less of how much you know or what you should know and he will ask questions about strange situations that he found, confronted and solved or maybe details about a specific class from a framework. During the interview it is more about him shining than discovering the candidate.

And I can confess that in my first years as an interviewer I was doing that a lot. Questions about situations you only find once in a few years, very specific cases about how the framework you use is behaving, stuff that if a developer knows doesn’t tell you anything about his coding or problem solving skills. In 80–90% of the cases the person being interviewed said ‘I don’t know/ I never got in such a situation’ and that was the end of questions like that. But for me that was a sign that I knew more, that I was the senior, that I was shining.

I still hear about this quite often at the place where I teach, my students told me about some strange questions they received. While they apply for junior positions they don’t always get interviewed by senior developers and skilled interviewers so they get into all sort of situations. The only thing they can do is not to worry about them and instead concentrate on the important stuff, like algorithms and problem solving techniques, OOP basics, web — HTTP — MVC details. And if you take the feedback from your interview and see where you need to get better, an offer will come sooner or later and might be even from the same company who said no 6 months ago.

Advanced Junior interviewers

In some of the interviews I have been involved I noticed this trend of digging around things the candidate doesn’t master very well. It is like that if the interviewer feels that you are not very good at doing something he will keep asking you about that. Now this is a little more advanced that those strange questions, but it is still not a step in the right direction because the interviewer should focus more on what the candidate knows and what is he experienced on. As an interviewer, once you found something that you feel your candidate doesn’t know well enough, mark it down and move on. If you just circle around what he doesn’t understood well enough, there a lot of things that he might know and you might miss them.

Try to see what the candidate knows, don’t concentrate on his weaknesses

I believe that from a certain level any developer can block another one with a question, there are so many things to learn out there that everyone has gaps in his knowledge, it is just a matter of time until they will be found. If you concentrate on those once you find them the whole interview experience goes down and the candidate will not feel good about not knowing to explain the concept well enough. And it can get worse when it becomes the center piece of the interview and what everyone will remember about it in the next months or maybe years. And as an interviewer your goal is to find out what that person knows and to see if she can be a good fit for your job description.

Senior interviewers

Now at some point I realized the strange questions were not helping at all. And also if I find a gap when someone explains a concept after a few tries to see if she doesn’t understand it, I will move on. There are so many things you can ask during an interview and there is a limited time for it. Such a discussion should be more related to the day to day work and less about strange things happening with your framework that you will see once every 2 years. And because I want to get as much as possible from the candidate the atmosphere is as informal as it can be.

And that’s when I introduced live coding during the interviews. I tried to cover OOP basics not by asking what is polymorphism, inheritance or composition, instead we worked on a design of a real task you would possible get from a client. How would you implement it, how to make it flexible and scalable, what tests should be in place. And this helped me avoid hiring some developers that were really good at talking about concepts, but they couldn’t write any code at all.

Concentrate on experiences and possible situations, avoid trivia questions

A way to easily spot a valid candidate is if he is clear in explaining his past experiences and what he build makes sense, like not reinventing the wheel. Even for developers applying for their first job, they have small projects that they built during their studies. I aim to avoid the trivia questions and talk more about experiences and how to handle all sorts of situations. Even if the candidate missed one or two important concepts it might be OK. The software world is very vast and there are a tone of other things he could know. And one of the tasks at my job is to find those things and if I think they can help us then welcome to the team.