Month: August 2017

On programming

Programming, just like many other craftsmanship work, needs abundant guidance and tutoring. In today’s world there is an enormous amount of excellent open source projects out there and you could download them in just a few clicks. Theoretically, there are no hidden secret recipes and you can learn everything by studying the code, but very few people become experts in this way, probably just like no one becomes a surgeon by doing post mortem on his/her own, no matter how many corpses are available to him/her.

Programming, given its engineering nature, is finding the quickest, simplest and most efficient way to solve your problem. It is difficult to master some techniques if you don’t make mistakes and learn from failures, but more often than not, you would want somebody to tell you what is the correct way to do things, simply because life’s too short to repeat mistakes. It’s so much better when some engineering catastrophe happens, you are able to recall instantly that somebody ever told you a possible cause that can lead to it, than to guess and troubleshoot without any clue for days. This is why people are always emphasizing on “platform”, “team” and “projects” when advising for software engineering career selection.

Work hours do not translate into work experience equally in different environments. In a reputable corporation, you see projects that prove themselves by sustaining market pressure, so you know the architecture and implementation, especially after years of iterative development, is well thought and well designed. You see systems that handle millions of queries per second and what special treatment and care such a system needs. When you are asked to improve it, you need to first figure out all the internal wiring, how components interact with one another, and what functionality that snippet of fancy-looking code brings. Achieving this level of proficiency is impossible by sitting at home and studying alone. If you don’t have smart and expert level team members answer your questions, you would be stuck forever – for real practical problems, chances are very slim that you could find answers on StackOverflow.

Myth about Technological Hiring

Starting from many years ago I started to notice a very interesting trait in IT industry hiring (here by IT industry I mean positions that require extensive software coding) – the interviewer could potentially go straight into “let’s solve some coding challenges” without much exchange of greetings. The process of the entire interview could concentrate on a very concrete and thought-intensive problem and you are expected to solve it in an unambiguous way by writing down your compilable code and explain why and how it works. This is unimaginable in even neighboring industries like electrical engineering, not to mention finance, consulting and other fields that pay more attention to soft skills. I am not saying that doing code challenges is the only component of all technological hiring in the IT industry (though in many cases it is the sole part), yet everybody working in this realm knows that if you show any signs of weakness in this part companies do not bother moving forward to assess other (glittering) facets of you.

The style of this type of hiring has incurred much criticism, especially by some senior level professionals who argue that coding at toy scale, no matter how proficient you can do, does not necessarily reflect your true engineering capabilities. In 2015 there was news that Google turned down Max Howell, the author of Homebrew, because he was “unable to flip a binary search tree on whiteboard”, so ironic that someone who “created tools for Google engineers’ daily use is denied a position in the company”. From a logical point of view, it’s hard to believe that guy could not code flipping a binary tree with bare hands. I would rather guess that such a trivial coding challenge made the coding guru irritated that the whole interview process became an unpleasant journey from then on.

Yet, given the scale of Google, such hiring process is fully understandable and almost inevitable to a giant tech business. Simply put, companies at the scale Google can afford to lose any talent. An optimized hiring workflow is all about hiring best talents statistically, and we all know that if something is statistical, there is no guarantee anymore – you could be the false positive or false negative. Recruiters are told to hire the best 10% in the job market, not Person XYZ who ranked No. 1 (in fame) in the industry.

Now we can take a look at how these tech giants, bearing in mind the goal to hire the best talents statistically, settled with the interview schemes we see today. Why are they so obsessed with coding challenges, some of which are even so hard and obsolete that you rarely think about and make use of in your daily work. A plausible argument to this is – these coding challenges test your fundamental knowledge. For example, how can you expect someone to comprehend and improve a distributed database system if he/she has no idea about implementing an in-order traversal of a binary search tree? But this viewpoint becomes vulnerable as coding challenges are evolving to be unprecedentedly difficult as time goes by. Nowadays, even recruiters recommend professional interviewees using several weeks “sharpening coding skills” before embarking on a real interview. The funny thing is – as a programmer who exercises coding at work each day, why would I be advised to devote extra time to prepare for a coding challenge? Superficially, it says at least two things. First, the code challenge is a digression from your work routine; second, the code challenge is hard and if you don’t prepare well, you fail. This seemingly irrational coding challenge, I would argue, is actually quite effective in terms of being effectively selective. Remember the famous reasoning about a peacock’s ostentatious tail that has no survival advantage in nature? It’s all about show-off – if the peacock can live with such a useless drag without being preyed, it must have got incredible surviving skills. The same logic applies to here – if you are able to devote a couple of hours to interview preparation after work for several weeks (without being fired by your current employer), grasp so many coding gotchas and tricks, and perform well in 5 consecutive intensive interviews – wow, you are the smart, energetic guy we would want to hire! None the less, If you happen to belong to the fraction of people that do amazing things in big projects but perform awkwardly in coding challenges, sorry, life is too short (also too costly) to tailor our hiring process for you. In fact, a grueling hiring process not only filters down the most adaptive candidates (with regard to a fierce career competition) but also distills the group of people who are seriously considering a career move. After all, who would want to go through such daunting process if all they want is taking a random shot?

Back to Max Howell’s rejection by Google, the implicit message Google conveyed to Mr. Max Howell might contain another fold – if you are mad at being asked to flip a binary tree on the whiteboard, we have reasons to believe you might have problems in executing your superordinate’s instructions. Technology must be submissive to capital: this is called Capitalism.