The first time I interviewed for a position as a software engineer my experience was probably like most other engineers: I had a phone screen, I did a code challenge, and next I had an on-site technical interview.
Of course the on-site technical interview has its place. And for many companies and it is absolutely necessary, but in my experience (having been an interviewee many times) most companies follow the same rigid process to evaluate technical abilities of a candidate that will never even be used in the real world.
I concede and agree that there are also many companies where this type of technical interview is critically important in determining whether or not a candidate will be able to contribute to the success of the product. But as a hiring manager when you are deciding what type of process to run your candidate through you need to really take a step back and align your business priorities with your hiring process.
Particularly in a small company or a company comprised of small teams, soft skills are equally important to technical skills. In my experience as an interviewee, evaluating team cohesiveness was typically an afterthought.
In nearly all of the processes that I have gone through to “prove my worth” as a developer, a common theme was: I was sat in a room with multiple people who gave me a problem and watched on as I tried to solve it in a text editor (because IDEs are a crutch in an interview, but apparently not after you get hired.) In most cases, the problem I was given was clearly something that would never be encountered on a day-to-day basis - or possibly ever at the company.
There is a place for quantitative assessment in the interview process, and I believe in a basic code challenge up-front for that purpose. It provides you with a baseline for assessing candidates.
But once you have a candidate in the door, your mission should be to determine how you believe you can work with them, assessing their ability to learn, desire to grow, and assessing their ability to communicate and collaborate with the other team members. What’s more, you should be demonstrating to the candidate how you view them: as a peer and future team member. This person is not your adversary - they are a potential teammate.
I believe in a collaborative interview process which involves my team, the candidate, and myself. It is important to me that my team feels that the person we are interviewing is someone they can work with on a day-to-day basis. It is equally important the candidate feels comfortable interacting with the team as they may be a future team member.
To that extent, for an on-site, typically for the first 15-20 minutes we’ll just break the ice between everyone involved in the process and keep things very informal. I prefer to have some of my team members meet with the candidate without me so that there is less pressure.
Once everyone is feeling a bit more relaxed we typically move into the technical phase of the interview. As I mentioned, I believe this phase of the interview should be collaborative - as an assessment of how we could all work together, while also exercising the candidate’s technical abilities.
To feel collaborative, it is essential that everyone involved is trying to solve the same problem. To accomplish this, I will typically design a problem that spans 5-6 problem areas, based on a real-world problem and covers about 5-6 topics relevant to our development. Often, I will design the problem shortly before the interview, so that even I have questions. I prefer to not let my teammates know what the problem is until right before the interview as well, so everyone is on equal playing field.
When I present this problem to the candidate I make it clear that I want them to operate in a “real-world” setting. I want them to collaborate with me and my team, ask questions, use Google or any other assets at their disposal, and work together to come to a solution.
Of course I prefer that the candidate solve the problem entirely on their own, but even then, with my team not even sure of the solution themselves we can ask questions and engage in discussions and better assess our fit as a team.
Using this method - in addition to weeding out candidates who snuck through the initial technical assessment - we can better evaluate candidates on culture fit and soft skills while simultaneously evaluating technical ability.
I like this approach because it treats the candidate like a human. And by introducing a problem that no one on the team is prepared for it eliminates hubris, keeps everyone humble, forces everyone to pay attention and also provides the candidate an opportunity to actually teach the team something they may not have thought of.
If you are a technical leader and believe in building great teams I challenge you to work through an interview with a candidate on a problem you’re seeing for the first time. I believe you will be surprised and see unsuspecting candidates excel.
Top comments (0)