Why the coding interview is ineffective
The dreaded coding interview. Developers will spend hours practicing problems just to prepare for the software developer technical interview. Prospective applicants will practice countless problems on websites like LeetCode and HackerRank to avoid getting filtered by these widely disliked exams. The coding interview stands as one of the first barriers to getting a software developer role. It often takes place online, and will require applicants to solve difficult mind problems in a coding environment. But, do these exams really work to filter bad candidates and accept good ones? I argue that the coding interview is an archaic means of selecting software developers with very little evidence to suggest its efficacy. I have observed that the sentiment among developers is relatively settled, and is strongly against the coding interview. The sentiment among managers is, however, a mixed bag. Some managers have their reasons for supporting the coding interview, whereas others share a similar belief to developers in that the coding interview is archaic. I will also demonstrate how the coding interview can lead to the demographic underrepresentation of minorities in software development. This further exacerbates issues in software such as algorithmic bias and bias in artificial intelligence. I will shed light on some of the reasons that exist for the coding interview to be in place, but I will also highlight potentially better solutions that will benefit both the applicant and the employer.
Developers are largely in agreement that the coding interview is an ineffective means of selecting candidates for roles. A survey from North Carolina State University found that developers overwhelmingly feel as though their skill is not correlated to their proficiency at coding challenges. This same study also found that developers believed the coding challenge was heavily based on luck. Many of the questions encountered in coding interviews are variations of other questions, and this means that an applicant has a chance to see a question that is the same or similar to one they have seen before. Q. Larsen argued that coding interviews involve too much luck, as getting lucky with a question can make you stand out as an applicant, as you may know the perfect solution to the problem. Furthermore, many developers believe that the coding interview contributes to demographic issues in the software industry. The coding interview heavily rewards people who practice these kinds of questions. Smith argues in his symposium that people who are privileged will have significantly more time and resources to practice these questions. Smith further states that there are many others who could fill the role of software developer, but are seen as lesser candidates because they do not have the time or money to practice these questions. Without owning a personal computer, it may even be impossible to practice these questions at home. Safiya Noble noted that there was significant sexism and discrimination in the demographics at certain software development companies. Thus, the demographic issues we see in the software developer role are exacerbated by the filter of coding interviews. Surveyed developers also said that it is very possible that the demographic issues caused by the hiring process can lead to many negative outcomes in software, such as algorithmic bias and artificial intelligence catering only to certain subsets of the population.
While developer sentiments on coding interviews are largely settled, what are manager’s thoughts on the coding interview? According to the same survey conducted at North Carolina State University, managers are roughly evenly split between supporting and not supporting the technical interview. The managers who did not support the technical interview were found to be younger on average than their supportive counterparts. I found this to be quite interesting, as I believe younger managers may have recently also been developers. Having been through the coding interviews themselves, I bet these managers have a mindset similar to more developers. Managers in favor of the coding interview often cited that they rarely have had bad developers pass through the coding challenge. I argue, however, that this is not the issue with the coding interview. The coding interview may do a good job of only letting through good people; however, I believe it is evident that it also disqualifies a large number of good candidates. Dean Jackson from Google demonstrates that their interview process is designed to reduce the number of bad candidates coming through, and in the process, Google is fully willing to disqualify all good candidates in order to avoid one bad candidate slipping through the hiring process. I believe that this contributes to the demographics issues discussed earlier. According to Safiya Noble in Algorithms of Oppression, Google had hidden “antidiversity” policies and a persistent wage gap in their positions. The coding interview clearly has ramifications of creating demographic issues.
I found that the coding interview has contributed strongly to the underrepresentation of minorities in software development. It is no secret that there is a demographic issue in software development. African Americans and Hispanics are underrepresented, while Asians are proportionately represented and Whites are overrepresented. Similarly, women are underrepresented in the field of computer science. This is easily discoverable from the United States Equal Employment Opportunity Commission. Many developers believe that the coding interview specifically selects against underprivileged people, which is a logical explanation for why there are underrepresented minorities in software development. Preparing for these coding interviews requires time and a personal computer, which underprivileged applicants may not have. From the reading, Algorithms of Oppression, it is clear that modern algorithms highlight this lack of diversity in software engineering. I found one appalling example was that searching the N-word on Google Maps would direct a user to the White House while Obama was president. While this was not directly coded into Google Maps, the possibility for a racial slur to return a legitimate map value is a clear oversight. I would argue that more diversity in the software development workforce would lead to less oversights like this. For this reason, I believe the coding interview is a massive factor in software engineering demographics and algorithmic bias.
It is evident that algorithmic bias is present in software today. I argue that the coding interview is responsible for perpetuating algorithmic bias. Algorithms of Oppression demonstrated that Google search algorithms associated searches of Michelle Obama with the word, “ape.” This is clear algorithmic bias, and is a result of the lack of minority representation in software development. The coding interview is visibly effective at preventing underprivileged persons from getting jobs in software engineering, and the result is a software development workforce that does not have any diverse perspectives. While the issues that are seen in Algorithms of Oppression may not be the direct result of malice, they are the result of a workforce that has no experienced racism. Another issue was in Google image tagging software, where images of African Americans would be tagged with words such as “animal,” or “ape.” I believe that a more well representative workforce would result in software that can better mitigate racism. For many software developers, racism may not even be on their radar, and the result is algorithms that can be hijacked for racist purposes.
Although I am opposed to the coding interview, I concede there are reasons for its existence. The coding interview, at a bare minimum, proves that a person can at least write code. There are many institutions and bootcamps that certify anyone as a software developer, but do not truly teach a person how to code. Thus, the coding interview gives hiring managers the ability to at least see that someone can code. However, I would argue that there are significantly better ways to do this. You could have an applicant present a previous project that they have completed, and explain it. Ford argues in his IEEE workshop that you could also have an applicant work with a developer on a team problem, to get a sense for the applicant’s work ethic. Both of these scenarios more accurately represent coding in the industry. It is almost nonexistent to have a situation where a developer must know an efficient algorithmic solution to a brain teaser without the use of internet help. It is incredibly more common that developers solve problems in teams or pairs. Furthermore, developers spend a large amount of time researching solutions to problems. It is very common that a problem one developer will run into has been solved by many developers before. It is clearly more efficient to research your problems online, than to be a walking dictionary of algorithmic fixes. Another common argument for the coding interview is that it rarely lets poor developers through. I reject the notion that this is a positive, as it also rejects copious amounts of good developers. In fact, I believe the coding interview does not select the best fit for the job, but only finds the worst misfits to reject. The hiring process should be searching for the best fit, and not simply trying to reject people.
I believe that there are many stronger alternatives to the coding challenge. First off, coding in the real world often has you with a team of developers to bounce ideas off of. I think a more realistic challenge would be to code a small project together with another developer over the course of an hour or so. This more accurately simulates coding in the real world. Secondly, coding in the real world does not require you to have every historical algorithm memorized. This is such an unreasonable amount to ask of new developers. As Ford stated in his IEEE workshop, in reality, developers frequently look up solutions to their problems online. Oftentimes, code is reused from websites such as StackOverflow. Another reasonable solution is that experience should speak for itself. Older developers are often phased out because they have not practiced these types of coding interview problems in a while. Despite their long term experience in the industry, older software developers are being quizzed on the same concepts that are fresh in a newly graduated applicant’s mind. I believe that this contributes to the potentially ageist demographics in software development. I will concede that it can be difficult for developers to receive their first job without experience, but I believe that university education should be more highly valued as experience for first time applicants.
In conclusion, I believe that the coding interview is an ineffective means of hiring developers. Developers and some managers agree that the coding interview is a hated step to receiving a position. There are arguments in favor of the coding interview, but they mainly center around the fact that the coding interview is just designed to filter all applicants: even applicants that would be good fits. The coding interview perpetuates the demographic issues in software engineering. This, in turn, leads to significant issues in algorithmic bias. Google was one company that I researched, and found to have many issues of algorithmic bias. I believe there are significantly better alternatives to the coding interview that can be more accurate representations of real world software development. Experience should hold more weight, and past projects are more representative of an individual’s coding ability than a random question in a one hour time slot. The style of coding in coding interviews simply does not represent coding in the industry, and its ability to select for good candidates is correlation without causation at best. While the coding interview remains the dreaded first barrier to a coding job, I have hopes that the hiring process in software development will change as more developers speak out about the coding interview.
References:
Dean Jackson, “The Google Technical Interview: How to Get Your Dream Job,” Winter 2013, XRDS https://dijkstra.eecs.umich.edu/kleach/eecs481/w21/readings/googleinterview.pdf
D. Ford, T. Barik, L. Rand-Pickett, and C. Parnin, “The tech-talk balance: what technical interviewers expect from technical candidates,” in 2017 IEEE/ACM 10th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE, 2017, pp. 43–48.
D. Ford, J. Smith, P. J. Guo, and C. Parnin, “Paradise unplugged: Identifying barriers for female participation on stack overflow,” in Proceedings of the 24th International Symposium on Foundations of Software Engineering. ACM, 2016, pp. 846–857.
Mahnaz Behroozi, “Hiring is Broken: What do Developers Say About Technical Interviews?” 2019 https://chrisparnin.me/pdf/interviews-HN.pdf
Noble, Safiya Umoja. Algorithms of Oppression : How Search Engines Reinforce Racism, New York University Press, 2018.
ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/umichigan/detail.action?docID=4834260.
Q. Larson, “Why is hiring broken? It starts at the whiteboard,” Apr. 2016. [Online]. Available: https://medium.freecodecamp.org/why-ishiring-broken-it-starts-at-the-whiteboard-34b088e5a5db
U.S. Equal Employment Opportunity Commission, “Diversity in High Tech,” 2021 https://www.eeoc.gov/special-report/diversity-high-tech
Yin, Li. “What Do I Think about Coding Interviews?” Medium, Algorithms and Coding Interviews, 13 Nov. 2019, https://medium.com/algorithms-and-leetcode/what-do-i-think-about-coding-interviews-d6373da8f741.
