After thinking about it for some time I decided henceforth to be clear to the interviewers that I’m willing to solve and then discuss an exercise for some hours but not to attend White Board interviews.
Indeed, there is the subject of the low quality interviewers that exist out there, many of them are coders that recently left the college. A bad interviewer is easy to identify, since now I’m a senior developer in several languages I like to know the guy that is on the other side of Zoom, and I do it simply asking him a question. A job interview elapses inside a social structure in which the interviewer can feel (wrongly) entitled to brandish some control, but asking him a simple question changes the whole scenario, immediately he feels threatened, unrespected and uncomfortable, even his voice changes to a more serious tone. Such people should never be allowed to do interviews, they aren’t bad people, in most cases they never received the minimal training from their companies, so they just don’t know what they are doing. And even so they are the norm. But this is secondary.
As a personal side note, the WBI are worst in my case because I noticed since some years ago (when I taught coding for a semester) that I’m “blind to syntax”. Since the nineties I’ve written thousands of INNER JOINS, loops, each, and “for (i = 0; i < array.length; i++)” stuff but if you ask me to write one of them on a piece of paper I can’t remember the exact syntax. I didn’t choose to be like that, but I believe this a mental strategy that emerged to deal with the daily cognitive load, to solve software issues is burdensome and let the “details” outside make things more lithe. Anyhow this not worrisome, to be blind to syntax is not a problem in my day-to-day coding tasks, in the already dozen of companies that I’ve worked for, not only I’ve never been fired but most of the times I leave with new mates and a recommendation. I’m aware that my personal situation is not the interviewers responsibility but that is not the point that I’d like to discuss here.
Through the years I interviewed software developers on several occasions in order to integrate them into different projects, some of those interviews took place in the company where at the time I was working and others, the least, were made when a small government office hired me as a freelancer to develop a large Health-care related web site. So I know, hiring people is a scary thing, a single toxic/inefficient person can wreck or swamp a whole project and costs a lot of money. The most valuable thing in a software company is the Team of Developers, a group of people that enjoys working together and has good communication will deliver better software than a group with better developers but where communication and sharing are constantly obstructed for a couple of smart jerks that demand constant and neurotic recognition. So it’s understandable that companies set filters to avoid the arrive of those bad and rotten apple. But white board interviews are not the way, when a company is using them as a way to select a new developer is just hurting itself because the truth is that such method delivers recurrent false negatives and false positives.
Programming is hard, in fact a know a bunch of people who were all well paid developers fifteen years ago and now they are middle managers in an airline, have an small hardware business and even some of them sell food and grooming for dogs. When you are a developer you are always to weeks away from the dreaded burn out, and recover for a burn out is really expensive because the recover process takes weeks, at least two. Software is hard in part because it involves three different scopes or levels, first the code inside the functions, then the level of the application as a whole and finally the application interacting with the world, sometimes through the operating system, sometimes through the Internet.
The first layer (the function level) is the most basic, relatively speaking is also the easier. If we are using Ruby here will have a lot “each”, “map”, “filter” and “do |obj, elm|” and things like that. In this level, many times the developer must decide between a beautiful but cryptic one-line option or an ugly but more easy to understand four lines function. But whatever he or she chooses, the future refactoring will be relatively easy because most of the time the code’s scope is very local, nearly all the action happens inside a one or two ten lines functions.
From those three layers the one in the middle is the most toilsome because you need to understand, retain and improve a dynamic structural model in your mind for many hours meanwhile you type in the editor and drink tea or coffee, that’s why you don’t talk to a developer when she is in “The Zone”. Likewise, the application model is built using a bunch of entities that constantly change, the scope is complex and sprawled among five or six files. But this part is not only the most tiring, is also the most important: by far the most relevant skill that a programmer could have is to be able to create this collection of abstractions that connects the Domain with the concrete model that sustains the final application. The real hard and expensive technical debt will be there, hidden and undetected in the bad isolated layers and components that lies in the delivered product.
And then we are back to the White Board interview, where a well-educated and young interviewer asks me: “We have these two vectors of hashes, one with capitals and other with countries, the countries hashes have a capital_id that matches the capital’s id hash, how can I mix both of them and obtain one vector of hashes with the correspondent capital and country?”
What is the point of asking something like that? What is the intention?, not only the aim of the interviewer but the company that apparently is looking for a new developer? Some interviewers would answer that they want to know “how the candidate thinks”. But that clearly is BS, I don’t know how my brother or my wife think, and I know them since many years ago. To talk — specifically and broadly — about some technologies, deploy techniques and frameworks looks like a more straightforward way to know how I think than try to decipher it through the sharpie.
The truth is that the objective of a WBI is not to find a competent programmer, the underlay intention is to fight against the feel of social anxiety. Hiring developers creates anxiety, so people want to believe that doing such questions will conduce to separate the bad developers from the good ones, even when there is not any empiric evidence that supports such belief. Some people believe that 5G towers cause Coronavirus, some people believe that asking little puzzles revels a good programmer. There is no knowledge in such beliefs, but the crowds feel more relaxed holding faith for those “truths”.
Some years ago I failed not two but three WB interviews in a row. Sad, disappointed (and slightly humiliated) I was determined to not fail again, so I registered myself in several Ruby Katas sites. A Kata is an exercise where one must solve a WB kind of problem as fast as one can. In some of those sites other developers gave me feedback about the code that I used to solve the problem.
After twelve days of solving those small puzzles for many hours I noticed that I was more agile and confident facing those tiny and decontextualized challenges, also I had learned a couple of new tricks for the Ruby enumerable. In general, it was a fun experience — even when I can’t say that I learned significant new things doing them — , a couple of weeks later I got a job. Since I was hired as a senior developer I was assigned many Github issues to update the company’s REST API, including refactoring the TDD. Between the tickets of my new job one included the task to filter products’ offers according to the level of the customer. I had no clue how to solve the problem so I leashed my dogs and we walked forty minutes to the coffee shop, I sit down in the park for half hour, and then we walked back. One block before reach home I had an idea and quickly sketched it in my laptop. I discussed the solution with my boss and after some changes all worked fine. Some weeks later I had lost all my Katas agility, why? Well because to solve small WB challenges is not related to developing software at all, actually I read a study that founded that people who are good solving WB problems are not so good as real-life developers. In a surprising and totally unexpected twist of nuts, it turns out that being able to mix two vectors of hashes in a WB and mentally decompose and integrate software in a sustainable way are two very different things.
But then how can I prove in an interview that I know how to solve complex problems? Well, there is a very valuable and underused resource: Gitlab/Github. Being able to browse the candidate code through the years sounds like a gold mine to discover personal and professional traits, how he or she uses the interfaces?, how the TDD was made?, why is that old library there? But nevertheless the reality is that almost non interviewer checks the candidate’ repositories. This is understandable because to see and review all that code would take too much time and the company only assigns some minutes to evaluate each candidate. So this great source of knowledge is doomed to remain irrelevant forever. Then the focus should be in the assigned exercise and the talking about the exercise.
Hiring people is an art, not a science, and we all most work for better ways to know each other.
