August 12, 2015
Over the years I've been to a lot of technical interviews on both sides of the table and if there's one thing I've learnt and thats the fact that its really hard to get right. How do you tell if someone will be good at writing good quality code in an hour or 2 of talking to them? Do you even know after a week of them working? Are the people asking about TDD(insert trendy buzz word at the time) because they actually do it or because they want to do it. Do they actually understand what it means?
Its a strange process because actually everyone wants it to succeed. The team hiring really want someone to help them and the candidate most probably also wants the job. So whats the problem then? Surely you just hire the first person who applies and then everyone wins? Well unfortunately hiring a new candidate is one of the most expensive things a company can do. Getting it wrong is even more expensive! The wrong candidate can not only produce low quality work but can also cause other once productive members of the team to also produce low quality work.
So enough with the problems. What are some of the ways to make this a better process for everyone?
Well firstly from the companies point of view its important that candidates actually know as much as possible about the role before they even start the interview. Technologies don't tell you that much but if a company is based heavily on legacy tools but makes it seem otherwise then there will be a surprise. Surprises aren't good. Ever. Hopefully at the interview but even maybe after all the contracts have been signed they will find out. At that point all they have done is wasted every ones time. A developer will lose motivation very quickly if they feel that they have been miss-sold the role and they will leave. That leaves everyone at the same point as before but much later on.
The company needs to ask relevant questions to gauge the level of the candidate. This is not always that easy to do since everyone has different experience. Whos to say that your questions don't cover the 10% of the topic that the candidate doesn't know but actually they have real strengths to bring to the team. If you think about it, a strong developer should have strengths that the interviewer isn't experienced in. If they all knew the same thing then the team would be much weaker. So what are appropriate questions - Well try not asking something that you can google in 10 seconds. Don't try test their memory. Any decent company has access to a search engine. So who cares how many .net implementations of ICollection there are? If its a question that your best bet is going to msdn then you're most probably being too specific. As an example, rather have a conversation about when a HashSet is appropriate? If they havent used it then explain what it is. Who cares if they didn't know it existed? You don't know every single part of the api so why should they. What you are looking for is the conversation so its your job to structure it to flow.
If the candidate is junior then check their fundamentals. Data structures are always important. What do they know about the development ecosystem? Its not about them getting everything right, its about the conversation. If a junior developer is willing to admit they don't understand but are interested then thats a really good start. You never want to get a junior superstar that will never improve because they believe they know everything.
If they're more senior, then its always good to focus the interview on their experience. If they did a lot of winforms, did they ever have an instance when a background thread doesn't update the UI. See if they understand why that would happen. As they get more senior is gets a little trickier in a way. The more experience they have, the more broad your interview conversation will be. You more need to try understand how they look at problems and their views on common development problems. You are looking for someone who could possibly steer other developers to best practices. Theres no script for that. Ideally you need to just roll with it and hope you know enough to keep your side of the conversation.
If I'm going to a ASP.NET MVC web role interview I'll google "ASP.NET MVC interview questions". The scary thing is that most of the interviews I've done in Johannesburg and London ask questions from the first page of the results. Its not that I don't use all those features when I work in those sorts of projects, its just that its always good to refresh your knowledge and make sure you're prepared. I can see that its important to know those things but it shouldn't be the main focus of your interview. The exception of course is if you are hiring a specialist contractor who only needs those skills.
The common wisdom these days is that somewhere in the process you need to write code. If I'm interviewing and I don't ever need to actually code then thats a warning sign to me. The way I see it is, how they interview me is how its most probably been for everyone else in the team. A thorough interview process is a good thing. There's a better chance of a strong team. It doesn't need to be long but it should cover most of the bases.
A common complaint about interviews is that they are a different skill set to working in a team. Getting experience with interviewing greatly increases you chances. When I contracted in London, you all worked with a 1 week to a 2 weeks notice period and so interviewing was always a big part of the process. All the contractors I worked with believed that its a skill that you need to practice. Its very hard to nail the first interview in a while. You sometimes need a couple dud interviews to get a good feel for the market and to practice telling your story. So as a tip, try not to only interview when you really need the job. Schedule an interview every now and then and use it as a learning experience. Worst case you learnt something, best case you found an awesome new job.
Its not ideal but its the world we live in. If getting better at the process helps you get that dream job, then why not work for it? Its hard but practice really does make perfect!