Over the last few years, there has been some real strides in the way companies are conducting technical interviews to gauge technical talent. Platforms like Coderpad (where I work hehe) have really become game changers, especially in todays world of Covid and remote hiring.
I've spoken to a lot of people over the last few months in my new role at CoderPad - Heads of HR, heads of engineering, engineers themselves. People at small companies, people at tech giants. I've gained some pretty amazing insight into how companies are conducting technical interviews and the types of things they look for in candidates (spoiler alert: it's different for every company). I still think there are massive strides to be made in not only evaluating talent, but allowing talent to stand out. Technical interviews are probably some of the most nerve-wracking moments in an engineers life and I still think some things are being done wrong. Here are some of my thoughts…
**Note: These are just thoughts - companies of course know how to hire for their company better than I do.**
I hear a lot of people worrying about candidates cheating during a technical interview. Well define cheating to me. If it's Googling, that means your engineers that currently work at your company aren't allowed to use Google when they are stuck. Just kidding of course, but seriously…
If you are worried about plagiarism, I get it. But if you've set up your technical interviews correctly, engineers are very good at telling if someone has copied code. Get a candidate to explain their thinking, and if they are plagiarizing - they won't know what they are talking about in "their" code.
But let me explain a little further on this point of cheating…
A typical software developer at X company, will spend 8 hours a day at their desk coding away on features, bug fixes and typical work. Hours are often spent pondering documentation, Stackoverflow and internal notes on how best to write maintainable code that will be approved for production.
While you can get a good indication of a candidates thinking in a 30 minute code session, not everyone works this way. Some people take time to think about ideas and concepts. The best way to solve this is by coming up with interview questions that are relatable to your company, and answers this question: Will the candidate be able to fulfill XYZ role from the answers/thinking they showed during this technical interview.
But if you are worried about them Googling or using notes during the interview, be upfront about it. I don't mind if you don't want a candidate to use Google or their own notes. But put some trust in people and I guarantee the interviews will be better because of it.
Let me tell you about a little story from one of the best engineers I know/worked with - now a VP of engineering at a pretty largescale payments company. A few years ago, he was on the hunt for a new role. He obviously had recruiters going bonanzas for him - and at times he would accept their invitation.
One of these companies made him complete a "pre-screen" questionnaire with technical questions in a multiple choice manner. Not that I'd advise this ha, but he purposely answered every single question wrong to see what would happen - and all things considered, he was CTO of the company we were both at. They moved him onto the technical project regardless of his score. What a waste of time!
One time I was interviewing with one of the major banks - they gave me a multiple-choice questionnaire and recorded me through video while taking the exam. I took the quiz twice. The first time I took it I had my webcam cover on so the camera wouldn't work - they wouldn't accept my quiz even though I got 100%. So I had to take it a second time. But why video me?? And why do you think me answering these questions gives you a good indication to move forward in the interview process??
Not only were they recording me which I still think is a weird privacy concern, but the role was for a more back-end focused position. The multiple choice questions included some strangeeee HTML questions. I can't remember the exact question, but I had never even heard of this HTML thing they asked about and I highly doubt other engineers had heard of it either.
I'm sorry but using multiple choice quizes and word answer questions to evaluate technical talent is stupid! How does a test, where the candidate has a 1/4 chance of answering the question correctly evaluate their technical ability. Get rid of them!
I am not against live technical interviews, I think they can be really beneficial to understand how candidates think and break down questions (even if their code doesn't work). But again, I want to get the complete picture and assess a candidates skills correctly. I don't think you can do that solely in a live technical interview.
I think that a combination of Live and a Take-Home project gives you the full picture. You get a good understanding of how they think through live technical interviews. And then you can get a grasp of how they work in a "real-world" environment with the Take-Home. Being able to sit down at a desk and work through a problem like you would in an everyday situation at work.
Ok - I hear you saying it now. "We don't have time to do both", "The candidate isn't going to want to do a Take-Home", "I can get everything I need from a live interview".
Let me say this - your spending a lot of money $ on an engineer, you do have time lol. If the candidate doesn't want to do a take-home project, then maybe that's showing you their work ethic?? (the candidate not having time due to a current job, family etc is a valid issue - but can be solved by giving them time on the take-home). And perhaps you can get everything you need from the live-interview, but in my experience, not every engineer flourishes in a live technical interview. They are a high-stress environment. Give candidates an environment they can flourish in and showcase their true abilities - I guarantee you'll be hiring better people because of it.
While I think it's ok to use questions you find from the internet for technical interviews. I think it's better for both you, and your candidates if you can at least simulate tasks that your engineering teams work on every day.
A very basic example: Let's say I work at a payments company. If I'm hiring a Frontend React developer that will be working on creating credit card forms and modals, maybe come up with a technical interview that simulates them building React components for a modal, and a form.
Another example from the large bank I interviewed at - they asked me to design a Vehicle using OO principles. While I understand it gives me a good chance to explain my knowledge on a simple overview of OO concepts. The position was to work on their trading platform. Why not use a more applicable example like designing a Shopping Cart using OO. It would simulate more closely on what I would be working on. Trades after all do end up in some type of Cart when you want to place an order.
So these were just a few points I've been thinking lately. Nothing set in stone, and obviously not applicable in all cases. I realize technical interviewing is very hard. Hard for companies, hard for candidates. But they have to be done. So why not put some real thought into them. On that note…
If you're looking for software that will help you with technical interviews, reach out and I'd be happy to talk more about CoderPad and how we can help. We've been building something that I think you might like 😉