Recall, Recital, and Reasoning, my issues with the “Coding Interview”. 1/2
Knowing is not understanding. There is a great difference between knowing and understanding: you can know a lot about something and not really understand it.
As a Software Developer with quite a few years (ahem!), behind me, I have partaken in several technical interviews and tests in search of a position. Some have been fun and insightful, some a rather dismal and soul-crushing experience, and some, just a fleeting “what was the point of that?” moment. Regardless, I have concluded, (at least personally) that the more focused “coding interviews” are essentially pointless, and place far too much emphasis on recall rather than reason, particularly when a potential employer is seeking a new potential employee. Don’t misunderstand me, technical ability is certainly something one needs to assess within a new candidate, but the pressure cooker test in a closed room, being force-fed a range of pre-written standard algorithms and “Code War" like problems is going to do little to filter out the best candidates aside from perhaps those who have a good memory; you know, those who can swot up on an exam with short notice and ace it? -- (I admit a small degree of jealousy, however!). I take umbrage with several facets with this approach, which I will now attempt to elucidate.
It’s mainly about ‘recall.
Ok, so perhaps not entirely, its more than likely most candidates have a wider understanding of the subject than just brushing up on matters beforehand, yet the number of blog posts, articles, videos, and suchlike offering to help get the candidate to “ace the #xyz coding interview”, does create the feeling that it’s all about the interview and nothing else. For me, my development process isn’t usually about an hour in a closed room attempting to recall the difference between
Pressure cooker testing vs Investigation skills.
More often than not, our software career, places us, developers, in quite many pressure situations. Timelines, Schedules, client needs, impostor syndrome, work-life balance, mentorship roles, and even trying to be an being a good developer. There are many radically opposing work ethics that range from the more Scandinavian “work when you want”, 4-day work week, family first, to the US inclined, “work your [ass] off, with little respite”. Most of us fall somewhere in the middle of this spectrum. However, all of these call for, at least some form of the best utilization of time, and for me one example of a “good developer” is how we attempt this in regards to our daily work. Therefore, the ability to manage problem-solving, is paramount, whether it be bug fixing, architecture design, refactoring, feature creation, appeasing that annoying client. Here recall is probably not a skillset one should rely on, here investigation skills, internet searching, filtering relevant information, finding the answer in a short space of time, reigns supreme. Getting the correct solution beyond a mere StackExchange cut and paste approach, is almost an art form in one’s software journey, and in my opinion, is something that should be tested in a candidate, more than any one-off pressure test of recall in a closed room, especially those offline, in this case, one may never know, how the candidate can use the internet as a tool in everyday work, or how they may fair in finding optimal information in the required timescale.
Stressful / Unrealistic situations can obfuscate talent.
In my academic and professional career, I’ve sat far too many exams, I wrote too many papers in under 2 hours and relied far too much on how I was feeling on the day, how much sleep I got the night before, and what I would do if I didn’t get a pass mark. All of this supermix of emotion, stress, and expectation, didn’t do much for allowing me time to think about the matter at hand, what I was writing and prevented me from illustrating my true ability fully. Now, this is not to say exams should be eradicated, we need benchmarks, but putting the greater weight on testing situations can obfuscate the true ability of a candidate. It’s more than likely a candidate would be an excellent fit for the project the employer is seeking, but they just don’t perform to the best of their abilities in such enclosed and pressured situations, situations which do not truly reflect the real pressures of the potential role.
Galmourous catalysts for the pressure approach
It’s certainly not easy for job seekers to ignore the pressure test approach. The big tech companies glamourize themselves to the extent that in some aspects getting that “dream job” is usually based on the goal of being employed by these corporate giants. For many potential coders, obtaining a role with, and working at Facebook, Google, Apple, etc, is the ultimate achievement, regardless of what this actually means. This results in a plethora of material about getting a job interview at #abc and passing the #abc coding test, many online firms and app makers have made a business out of this. Sadly, this does more to promote the recall approach to hiring, than anything else. Ok so this may be a generalization on my part, but, to me, this is merely planting more trees in the idiom, “you can’t see the wood for the trees”. Setting aside the realities of working in a 3000+ employee office (definitely a blog post for another day), this normalization of the big tech approach, merely exacerbates the pressure both on employees (and to a degree, the employers, as to remain competitive), to place more weight on coding interviews than ever before.
In the next part of this discussion, I’ll look into some alternative solutions and approaches for dealing with the issues of this approach. Feel free to add your feelings on this subject, am I way off, or do you agree with me? Let me know.