pre·car·i·ous (priˈke(ə)rēəs) adj – dependent on chance; uncertain.
The Inspiration for this Series
I recently spent an evening with an exceptional group of techie friends. After some food and drink, the conversation landed on the topic of technical interviewing and interview styles. At this point in our careers, most of us have logged a number of hours on both sides of the table, so it was sure to be an insightful conversation. As expected, each one of us had very strong opinions on what worked, what didn’t, and how to interviews could be conducted to better expose the talents of candidates. What surprised me is how closely our opinions and grievances were almost completely in sync. This is a group of folks that thrive on debate and tearing apart every angle of a topic. On this rare occasion we almost completely in agreement: We’re doing it wrong. Our chorus of the outrageousness and deficiencies of modern interviewing tactics, shows me there’s a definite need for change.
The Basics of the Technical Interview
Just to make sure everyone’s on the same page, here are my goals for any interview I conduct:
- Vet the documented experience of the candidate.
- Determine the candidate’s ability to positively contribute to the team and available projects.
- Assess the range and drive of the candidate to work on current and future projects.
- To determine if and where the candidate will fit within the organization.
Here are some of the interview styles I’ve encountered through personal experience and research:
Trivia Questions (ex: Explain the basic features of OOP.)
Technical Conversation (ex: Explain why you chose to use JSON as the content type for your API.)
Coding Puzzles (ex: Write a function to reverse an array in place and remove all odd numbers.)
Cognitive Questions (ex: How much would you charge to wash all of the windows in Seattle?)
Offline Code Review (ex: Submit sample code for review without an interactive review.)
Interactive Code Review (ex: An interactive review of provided sample code.)
Interactive Logic Puzzles (ex: Whiteboard a basic database structure to store all players in the NFL by team and division.)
Tradition and Fad Combine
The traditional technical interview consists of a table, the interviewer(s) on one side and the candidate on the other. Roughly an hour of back and forth covering history and capabilities and the candidate is released. It really wasn’t much different than the interview process for any other line of work. Find out if their experience is valid and their skills are sufficient. Not flashy, but effective.
With the rise of the internet, a new media for creativity was spawned. As such, companies extended that creativity to the interviewing process. Google and a few other big name companies went public with their “alternative interview styles” and it quickly became the rage. It was new, it sounded more fun, and Google was doing it so it must be good… right? There’s been enough time now that independent agencies can gather metrics on different styles and their effectiveness. This research is showing that many of these fad interviews are no better at selecting quality candidates than random chance.
“In an interview with the New York Times, Google Executive VP of People Operations Laszlo Bock said the company tracked the exit scores recruiters gave to new hires and then determined how well they correlated with actual on-the-job performance. The answer: Not very well. With a few exceptions, Google’s hiring managers weren’t much better than random chance at picking out good employees.” ~ Silicon Valley Business Journal “Google’s tricky interview questions were ‘a complete waste of time’“
In addition to the wide array of interview styles and tactics, the challenge for today’s technical candidate is the vast array of questions, skills, and technologies the interviewer(s) have to choose from. A typical .Net Web Developer can be asked to prove proficiency in nearly a dozen languages, a variety of coding styles and concepts, multiple server architectures and frameworks, and so forth. Proficiency tests may come in a variety of different manners from trivia to sitting in front of a computer and writing code. It’s near impossible to memorize answers to every of question one might be asked in an interview and it’s almost impossible to predict the type of coding challenges the interviewer could present.
As an employed developer, I’ve never been placed into a room with no interaction with colleagues and asked to code a solution from start to finish. I’ve also never faced a panel of developers asking me to recite answers to programmer trivia. Yet these are the tactics used in every interview to determine if the candidate is going to be a contributing employee. Even if the candidate aces the interview, is there any test that exposes their ability to work well with a team, both contributing and accepting suggestion? So it seems that the new fads aren’t producing results as expected, and the traditional way is boring and scary. Is there a better way?
It’s no surprise, there are few people in the work force who enjoy the interview process. Whether you’re the interviewer or the candidate, it’s doesn’t always seem like the most productive use of your time, nor is it usually the most pleasant. However, it is a necessary evil. But, why does it have to be such a painful process all around? Why does the opportunity to meet and chat with brilliant developers have to be an arduous process? Is there a way to make it less painful while still properly screening the candidate?
Each one of these interview styles has positive and a negative side for the interviewer. A large number of tactics strive to make it less painful for the interviewer, at the risk of providing a “standardized test” to the candidate. Understanding that, I’m interested to learn which of these interview styles the candidate found most exposed their talents. How well did the test assess and prepare them for the job after the interview? Could it be that the standardized coding puzzles are were most developers feel they can shine? Trivia questions are easier to memorize, but do the developers feel this is a positive way to express their abilities?
When many of these interview tactics going outside relevant experience, how can a candidate prepare to give the best interview possible? Are we giving the candidate the opportunity to put their best foot forward? These are all questions to which I hope to find answers with the help of the community at large.
With the help and input from a few friends and colleagues, we’ve assembled a survey designed to collect information about interviewing experience from the perspective of the candidate. Knowledge is power. By first understanding the current state of affairs, we can seek to improve the climate for everyone.
The goal of the survey is to gather feedback from the technical community on the perception of the interview process. I hope to get feedback from developer on how they feel their talents could be better exposed through this process. “Which interview styles do you (the developer) feel allow you to best represent of your skill and experience?” This is the most valuable question on the survey from my perspective. Let the candidates evaluate the interview and give the interviewers tips on identifying the best candidate.
This is not a professionally designed survey and the “science” involved in processing and interpreting the results will be amateur at best. I’m hoping that the survey results can show a representative trend at minimum. This combined with written feedback to this and other discussion forums can help to determine next steps. Whatever the outcome, I’m excited to see the results!
Thanks for reading and please share with your friends.