I haven’t done interviews in a while, but the idea of interviews is constantly present in my mind. The #1 question almost no company seems to get right is “What would a perfect interview look like?” I suggest that a good approximation for software positions would be to evaluate three general skills: problem-solving, communication, and flexibility. Although the skills are pair-wise intertwined, a candidate should be visibly good in each of them to easily integrate into an existing team. The generality should not be a concern, as the employer still has the liberty to tailor the process to their domain by presenting domain-specific problems. This achieves a balance between abstractness and concreteness while also satisfying both the employer and the potential employee. The process goes as follows.

After filtering out candidates to get to a manageable number, two coding challenges are presented: one based on algorithms and the other based on APIs. The interviews are conducted by inviting the candidates to explain their thoughts while working out the solution. Both sides are encouraged to ask questions either to clarify or to help. Thus, interviewers can determine how easy it is to communicate with the interviewees and how good a teammate they would be. At the same time, interviewees can gauge whether the style of their future colleagues is to their liking. For best results, the most obvious choice for the interviewers are members of the actively recruiting team.

The first one of the two challenges revolves around algorithms. Not the coursebook version, but rather a custom set of pseudo-algorithms that resemble the team’s daily work. For example, front-end web designer candidates need not instantly recall the complexity of the topological sorting algorithm from memory. A more appropriate task would be to write a piece of asynchronous code. The main incentive here is to test the candidate on familiar territory and skills from the advertised position. Arguably, it is still necessary to analyse the complexity and the running time of lines of code (possibly even unrelated to the job), but with an emphasis on the job-specific part. As a side note, the usual skills checked for by companies involving random textbook algorithms can be made more relevant and more fun with an appropriate setting.

The second challenge focuses primarily on the interaction with team-specific APIs (or ones that resemble them). Every job out there deals with abstractions of some sort, and APIs are the ubiquitous way of abstracting away information and/or functionality. The gist of this part is a domain-specific context and a well-documented list of functions to act on that context. One example would be a booking application with functions such as getUser(), getProperties(location), getPrice(property), placeBooking(user, property) and so on. The possibilities for the actual programming task are endless. The common denominator is that the candidate needs to explore the documentation, understand the logic behind the various structures, and integrate them into a new flow. One caveat is that the candidates would be tested on how easily they remember and interact with the API.

Because the challenges have a real-world basis, they let both the interviewers and the interviewees learn something about each other. The former understand how comfortable the participants are with the “required” material. Simultaneously, the latter can showcase their suitability while also checking that the job description and the tasks match their expectations. In the end, even though it would be laborious to design an interview process like the one presented here, the outcome would be rewarding and worthwhile.