In part 1 of this discussion, we looked at the issues that can arise from the so-called “technical or coding interview”. It’s over-reliance on recall, and the opportunity to allow a smart candidate to swat up for the interview, aided in part by a myriad of online material that has evolved to “aid” in this approach to more technical employment processes. I argued that this is essentially a redundant process, it’s one that favours memory-savvy candidates and misses out on probing their wider knowledge understanding on the subject, thus perhaps letting much better[?] candidates through the net, which I argue is far more important. In this section, I provide some solutions to this approach which have been adopted successfully here in Finland, and to which I have been a participant. I suggest these are better for the intended purpose and rely more on the wider skills and understanding of the candidate and less on their ability to merely ‘pass tests’.

Some potential alternate solutions:

+ The technical challenge.

Perhaps it is a tad too bold of me to brush away with the coding interview altogether, I would advocate a test or two, but as I have been given in the past, a task, to take away home with me and undertake over a few days with the comfort of one’s own surroundings and the internet. Then I return for what we here call a “technical interview” whereby we spend a few hours discussing the solution, the what and why we took the approach to solve the challenge as it we did. This probes not only the technical ability but a greater understanding by the candidate of the task.

+ The Technical interview.

In fact, I’d go even further and suggest for more experienced candidates, the need for a specific challenge can be bypassed in favour of an in-depth 2-hour (ish) discussion on all aspects of the technology to which the candidate is being interviewed for. This, in my opinion, will truly uncover the “fitness for duty” of the candidate, their wider skills, and to an extent. Their social character. This itself provides ample opportunity to investigate (under slight duress) how well a candidate understands the subject to which he is allegedly familiar and paints a clear picture to the employer on the future ability for the candidate to operate in the role under which they are being interviewed for.

+ Trial Period.

It seems pretty obvious but is often overlooked. The true test of a candidate is in how they actually operate in the reality of the role, so a contractual period of time or a honeymoon period is a good way for both the employer and the candidate to get a feel for what they are in for! Certainly, for candidates who are far more experienced and well versed, these can be mere necessities based in employment law and contract, and mean nothing in practice, this too for some employers who have far more sound recruitment and screening processes, the trial period is just something that has to be applied for all candidates regardless. In some circumstances, there are conditions attached, such as a slightly less salary as agreed for the full role, or a different title until a successful period has been undertaken (more common with more experienced candidates). At the very least, it’s a time whereby an employer may terminate a candidate’s employment without notice, or a candidate may leave without notice, should the role not suit either way. Here this is perhaps a more comforting position for both and provides a better impetus for candidates to focus on long-term skills for which they will need, and experience the reality of the role in which they will be partaking, this and also devoid of any financial or other non-role-incentives. Time periods for trial periods (koeaika) vary, here in Finland, it’s usual for them to range between 3 and 6 months.

Conclusions and thoughts.

If you have ever heard about Uncle Bob Martin, a sort of iconic tech guru on everything from tech and agile management to coding to being a better programmer, he talks about “code kata” which essentially is undertaking small repetitive coding tasks focusing on a particular area until the idea is “known” to you, here I refer to “known” as understood, yet here, it is also a possibility to rely purely on recall rather than understanding. However, in the context of personal development, I agree, as developers we are continually learning, and evolving, and must always be open to new ideas and concepts, but to “understand them in the wider context, not merely to recall them. However, this kata approach is often reflected in coding tests, here the problem lies with the abnormal context in which they are applied. It disallows for any wider understanding, as unlike doing them in one’s own time with the full extent of the internet at hand, they revert to merely items of recall. Think “Code Wars” in a single room with no internet. For me, a large part of getting through a code Wars kata challenge is trying to decipher the often obtuse and poorly explained challenge/example or tests to pass. At least during normal code-wars, kata one can spend time assessing and understanding the problem, whilst in an interview situation, time is rare, and asking the interviewer for clarity may be seen as a weakness.

Thus, if you are a candidate embarking on the tough journey of job seeking and are faced with a “coding interview” be wary, that merely revising for only this interview, will put you in a difficult situation going forward should you pass the interview and be offered a job. Rarely do our daily development tasks rely on the sort of challenges put forward in a tech test, far from it, in the daily rigours of software development, we need a far greater understanding of technology, all the bits and pieces, and how they fit together, dealing with integrations, with clients, with teams and various skill levels. You may know tail recursion inside out, be able to write a Bubble Sort algorithm, Fibonacci sequence, or solve a project Euler challenge, but in my experience, in most cases, they will rarely come up, in fact, you will probably try to avoid most of them if you can. That said, do not give up on learning these ideas, as they will aid in your future understanding, but they will not get you much further than a coding test if it’s all you rely on. Don’t fall for the hype, coding challenges set by Google and others, certainly, they, may provide good practice for you, but they are not the entire universe of employment screening, you will need to know more, seek to understand not just to know.

How have your experiences been, have you attempted (and failed) coding interviews, or gone on to gain employment and discovered all your swotting up was merely an irrelevant step to filter out the more technical candidates? I’d be interested to know.