About that Tech Interview…

Its Wednesday afternoon, around 2PM, and I’m interviewer number 5. The poor candidate on the other side of the table from me looks pretty tired. I offer the cursory bathroom break and a drink of water. The candidate takes me up on the offer and we proceed with the customary chatter as we walk back and forth to the bathroom.

“How has your day been so far?”

“Good”

“How was lunch?”

“Very good, nice food”

“Hope you don’t live too far”

“No, not too far, just on the other side of the river”.

Its a very polite role play that you get really good at after doing a large number of interviews. In some sense it is an awkward form of foreplay until you get back to the room, close the door, and really dive in. I run through the routine

“We’re going to be focusing on a technical problem today, if something isn’t clear, don’t hesitate and ask, I’m here to help. I’ll make sure to leave some time at the end for you to ask any questions you might have about the role, the company, and anything else that’s on your mind. Lets start.”

I proceed to write the technical problem on the board. Python, Java, C++, really doesn’t matter, I’ve developed my technical problems over many years to work in any language and have it focus on algorithms and data structures that work in all of them. If you know the language that you are conducting the interview in, and you’ve got your fundamental down, my problem shouldn’t be too difficult, if you don’t, you won’t get very far. To be honest, I know that it will take a very good candidate about 30 minutes to work through the problem, a mediocre one, 35, and a bad one won’t get there in 45 minutes.

I have a confession. I’ve done this enough times that I don’t really need to pay too close attention to what you are doing. I know the areas where you are going to get stuck, I know the first 2–3 questions I’m going to ask because almost everyone hits the same roadblocks. So I can just ever so gently peek up at the whiteboard from reading my e-mails or scrolling through Facebook. I’m exaggerating here, I take meticulous notes, but on occasion I will do one of those activities without much fear that I would have lost focus on your approach to the problem.

At the 40 minute mark I’m going to try and start wrapping things up if you haven’t gotten to the answer yet and proceed to the informal questions part. I turn on my charm face, close my laptop, I’m 100% attention on you. Phone turned over, light smile, I’m trying to close the deal here! I do this with everyone, whether you’ve done a great job or completely failed the interview. I already know what my recommendation is, but I need to play it safe. I need to sell you on the company, how great we are, how awesome it is to work here, how wonderful everything is, how unique we are. I need you to leave thinking that you are worth a million dollars. I need to get you to want, no, need to take the offer if it ever comes. When I’m in sales mode, I rarely get told no. It happens, but pretty rarely.

This is where we part ways. According to my internal interview statistics, the likelihood is less than 10% that I’ll actually see you as an employee, such is life. Courtship is over.

Now the real hard question begins.

What exactly was this whole song and dance about? What in the world was I trying to learn about you? What was I trying to convince you about me? And here is the real kicker, considering the fact that the previous 4 interviewers roughly went through the same song and dance, what exactly were we all trying to accomplish as a collective?

I hope I’m not going to divulge some great secret here, but I’m of the opinion that our technical hiring process is absolutely broken.

The sequence of four or five interviews, all consisting of some variation of solving a technical programming problem that is loosely based on some algorithm outlined in some textbook that you, the candidate, may have last seen in your Junior year of college and will never actually have to deal with in real life or your day-to-day job tell us, the interviewers, nothing about you or your ability to actually get real work done. (breath). Yet this is precisely what the technical interview process looks like today. It shouldn’t be a surprise then that it is such a crapshoot to actually hire a good candidate that is productive, contributes to your team, and gets things done. Our interview process tests for the wrong things.

To use Stephen Covey’s term for what we should be doing is “Begin with the end in Mind”. In order to do that we actually have to go back (or forward) and try to understand what is it that a Software Engineer does in their day-to-day job and what makes a good Software Engineer. Once we can answer that question we’ll be able to better structure the interview process that selects for those traits.

So, what does a Software Engineer do on a day to day basis?

Sitting in a corner and solving esoteric coding puzzles is certainly not it.

What it is though is a highly collaborative and iterative process of trying to solve complex business needs and objectives. The key here is collaborative and iterative. As a Software Engineer you rarely work alone, you are part of a team with a cross function of players. You’ll have a manager, software engineering peers, a project or program manager, perhaps a product manager or two, and if you are more on the front-end as opposed to the backend of the stack then a UX designer or engineer as well. Depending on the size of the company or product that you work on you may also be interacting with the sales, marketing, and support organizations as well. This is a very broad and varied set of individuals that you need to be engaged with, yet the interview process outlined above tests for a condition that will only happen once a year and involve only one of the individuals above, the Software Engineering peer.

We need to re-imagine what our Software Engineering interview process looks like to more accurately reflect what the desired end result is, an individual capable of working in this type of an environment.

I’d like to therefore propose a new model for an interview.

Lets keep the five interviewers panel as a given. We want an odd number so that you never have a tie when it comes to making a decision. Its either a yes, or a no, that simple. Also, lets start with the end state, namely, the desired cross functional skill set that our ideal candidate should posses. We are going to simulate through the interview process, the experience of building and delivering a feature.

Your day will start with an interview with a technical Product Manager where they’ll describe the problem you’ll be working on during the course of the day. You’ll engage in a back-and-forth discussion, consider a number of high level designs, some alternatives, and by the end of the 45 minute session you’ll arrive at what will be your working base template for the day.

The next interview will be with a technical lead, you’ll have to present the problem back to the interviewer and then do a much deeper design deep dive on the problem. You are going to be exploring the deep reaches of the technical problem at hand, solving the various edge cases, and trying to come up with a well worked out technical design by the end of this second 45 minute session. You are now ready to move on to demonstrating the core technical skills, namely can you write code. In the third interview you’ll engage in pair programming on trying to implement the feature. You’ll start off writing some code, the interviewer will engage with the problem you are working on, you’ll work through the challenges collaboratively. By the end of this session you should have something working, either on the whiteboard, or preferably in an IDE or a text editor. Maybe even building and running.

Now comes the fun part, lunch!

Its time to join the entire team as a whole, meet your future peers, chat with them, ask them questions, maybe even discuss the problem you are working on with them. See how you get along with the group. Can you see yourself being part of this team? Can they see you being part of their team? This won’t be a deciding factor at all but you should feel, by the end of lunch, not only physically nourished but also psychologically and emotionally nourished as well. You are going to be spending a lot of time with this group over the course of your time here, are you comfortable with that?

The post lunch session will resume with another coding interview. A different interviewer will now pick up the problem where you left off before lunch and work with you on trying to get the feature as finished and functional as possible. You should be writing code, lots of it. The lunch break would have helped you think about the problem some more, realize where your initial approach might not be working or better yet allow you to have a new perspective on the original problem. Allowing for what is in essence a 1.5 hour long coding session also provides interviewers with the opportunity to tackle a problem in complexity and depth far exceeding what is possible in a typical 45 minute slot.

At this point, the interview panel should have a fairly good sense of your technical abilities. The final interviewer is the manager. Their job is to focus on debriefing; what worked? what didn’t? what would you do differently? what would be your feature launch process? how were your interactions with the team? who was challenging to work with? why? how did you overcome that challenge? This provides a very real world engagement to see how the candidate will be like in a more realistic professional work environment, without fake scenarios or facades.

By the end of this day, not only would the candidate have received a great insight into their future team members, the company, and the work dynamic, more importantly you, the hiring manager, would have gathered enough signal to ascertain how well this candidate would do on this team. You would have tested their cultural fit, technical ability, collaboration skills, and ability to execute on a concrete problem. What would potentially take you many months to uncover as challenges and deficiencies, would have been surfaced within a span of a few hours.

Building and creating this type of an interview is no easy feat. It takes a team effort from beginning to end to plan the day all the way through. The outcome though, would be a much more engaging interview process with a much more assertive hiring signal.