Many companies in this current employee-driven market have a technical interviewing process that many find too cumbersome and take way too long. Many are spanning over three weeks long, including likely far too many rounds. This issue is especially evident with the more prominent technical organizations. As a hiring manager myself, I understand that there are no silver bullet hiring process that fulfills every organization's technical goals.
"Let's cut to the chase: At best, whiteboard coding tests for developer job candidates are useless. At worst, they're a hazing ritual that fuels hiring bias." - https://www.forbes.com/sites/forbestechcouncil/2018/05/08/hiring-bias-starts-at-the-whiteboard/?sh=2c286bddb85f
I know I don't speak for all developers, but at least in my bubble, it seems like whiteboarding interviews are a thing of the past. Or at the very minimum it seems like other developers I know will refuse the interview if those coding puzzles via a whiteboard are part of the process. What then, is the right process? I will speak to two processes, one that I personally use and one that I have heard worked well.
The first I will go over is from talking with colleagues. Consider a senior software engineering interview for a product development team. The tech stack was a modern react and node ecosystem with various backend and data-streaming technologies. The process included a take home with a base git project created. Candidates are all given the same base project. The candidates are provided a feature story to add to this project. If the interviewee passes this portion of the interview, the next round will include expanding said project with a developer at the hiring team. This paired programming exercise replaces the traditional whiteboarding with modern practices of actually writing code in an IDE that the interviewee is already used to. This concludes the technical aspects of the interview.
One particular issue that might already exclude some candidates is the take-home portion. What if the absolutely perfect candidate is a parent who refuses a take-home project? What of said perfect candidate is simply too busy to do the take-home? Couple the take home with the necessity to take another half-day off from their current work schedule to join in on the second round of technical assessment. If the interviewee is interviewing with many companies, this may be the Nth paired programming session and take home.
Next is the process that I've come to respect at my current company. While not perfect, it really only requires at most 3/4ths of a day of an interviewee's time for the complete interview process. We phone screen candidates with a slightly technical but not challenging and requiring no prep. This phone screen is used to gauge interest in the problem the organization is solving and the interviewee's passion in what they would like to work in next to ensure the goals of the interviewee line up with the hiring team. We have the recruiter then prep the interviewee with requirements that we'd like to see for a technical round table.
The interviewee presents one of the following; an in-depth problem they have solved, an open-source project they would like to share, or anything technical that they can speak to for about a half-hour. Leaving another half hour of the round table for the team to ask questions and gauge technical capability. We then split off into one on one questions with different facets of the organization. Their peers may go more in-depth into technical questions regarding the presentation.
This process is far from perfect. I find this process returns better results than a take-home for a few reasons. If the candidate was highly involved in the technical aspect of their presentation, it shows in the speaking ability of their project. Secondly, it is not a surprise. As a candidate coming into the process, they know what they'll be doing and will be comfortable on the topic. When doing paired programming or a take-home, the candidate typically has no idea what problem they'll be solving. Coding in an interview is also exhausting. I find it way more exhausting than typical day-to-day coding. One particular common criticism is the worry and fear of public speaking before the interview. This alone is another avenue where a candidate might avoid the interview altogether if they do not want to put up with a presentation.
I think these processes may be a significant first step in providing a more inclusive technical organization. Does either of these processes speak to you as a candidate? Are there inherent biases that I might have missed?
We still have much work to do outside of simply changing our hiring practices, but we become more inclusive if we self-reflect on the interview process first. Things to consider next is our internal biases. Consider this article on standardizing an organization-wide strategy to remove objectivity and compare each candidate based on answers given previously. "Here's the shocking result: The performance of initially accepted and initially rejected students turned out to be the same. Digging deeper, the researchers found that about three-quarters of the difference in ratings between initially accepted and initially rejected students was due not to more-objective measures, such as grades, but rather to the interviewers' perceptions of the candidates in unstructured interviews." - https://hbr.org/2016/04/how-to-take-the-bias-out-of-interviews
Top comments (0)