For over a decade, I have served regularly as an interviewer (specifically as a technical screener) for candidates that come through our doors. Of course, I’m expected to provide further insight as to their general compatibility with our teams, but the main priority is to gauge their prowess as a developer. It’s always imperative for me to be as transparent and considerate as possible, since I remember being on the other side of the table. In addition, it’s essential that I remain contextual while conducting my evaluation. When I was younger and pursued other opportunities, I remember attending various interviews and discovering a dearth of all three elements: transparency, consideration, and contextual evaluation. Even though the absence of the first two was somewhat annoying, I found the lack of the third to be maddening. Upon exiting an interview, my mind would be a cauldron of questions. “Why are you asking me to tell you about the quicksort algorithm, especially when it’s just memorization? How does this actually prove my more dynamic capabilities and get me better acquainted with your daily goals?” (Though, as I can tell you from personal experience, it’s probably best not to vocalize these thoughts to the interviewer, as constructive as this criticism may be intended.) Of course, the prospective candidate should be tested to ensure their command of a platform, a language, and all other important developer requisites. However, unless the position has a particular focus such as graphics optimization or a trading platform, a more general position (like within IT) should look for optimal employees by focusing on their overall problem-solving skills, especially in relation to the actual business at hand.
So, fulfilling a promise of long ago, I have made it a point to focus any tests on a potential employee’s problem-solving abilities, and apparently, there are others who think the same way. (Though, I’m not sure that I would entrust the DoE with understanding that same idea.) It’s important to recognize that all of computer science relies on the heavy-lifting work of algorithm creation done by our seminal predecessors, and all developers should have some foundation in that…but in this day and age, we should also recognize that the majority of software work today does not dwell in such deep, dangerous dungeons. So, when I prepare for an engagement with an interviewee, I always have work-relevant conundrums available for presentation. Some questions of this quiz only require a short audible answer, some of them exist as simple tests (i.e., condensed versions of work issues) that must be solved with some written code. If the interviewee feels comfortable while I watch and question the work, then it’s even better. In doing so, this interview becomes mutually beneficial to both parties. For the interviewee, this discourse provides a preview of the actual assignments and interactions to be expected upon employment. As for me, I get a better sense of the candidate’s ability to reason and of their general approach to development. For example, you can actually detect whether the developer has the ability to quickly infer whether certain functionality should be considered reusable or not. (You can’t realize such a quality of a person by asking them to recall the steps of the quicksort algorithm.) Consequently, I have found such a technique to be repeatedly favorable for all involved, and it’s my hope that more interviewers will also employ such a method in the near future.