Coding interviews – rad or fad?

As a developer, you probably have gone through one or more coding interviews. When applying for a developer job, you are expected to demonstrate some level of programming chops by solving algorithmic problems on a whiteboard or in an online code editor. This practice is not new. My first coding interview took place more than 25 years ago sitting at a lovely green text terminal. However, it has recently proliferated and became an integral and often time-consuming part of the interview process. Especially big American tech companies like Amazon, Apple, Facebook, Google and Microsoft are pushing the envelope. To land a developer job at one of these companies, you are now expected to be able to recite the finer points of an algorithm manual and produce solutions with O log(n) time complexity in a trice.

Does that sound just slightly ridiculous to you? Perhaps it is. The question one must ask is whether having candidates produce algorithms is actually a good indicator for success in the software development profession. I have been sitting at both ends of the interviewer’s table many times, and I am quite ready to doubt this implication. There isn’t much empirical evidence to support the thesis that people who score high on coding interviews also do well in their jobs. Actually, there is none. Even Google’s own study concluded that interview scores don’t correlate with job performance. Gayle Laakmann Mc Dowell, the author of the book “Cracking the Coding Interview” says: “No one really knows, but it’s very reasonable to assume that there is a link,” and “Absence of evidence isn’t evidence of absence.”

Sorry, that’s not good enough for me. Let’s be a little more scientific.

Perhaps we begin by determining what is actually measured by solving an algorithmic problem. The coding interview is akin to a school exam. It measures how good you are at applying textbook solutions to a given task. Just as in an exam situation, you can improve your score by studying hard. The domain is broad enough to provide sufficient variation in different fields from number theory and graph theory to combinatorics and set theory. Yet, algorithms themselves are very narrow as they deal with a specific solution to a specific problem. A successful coding interview demonstrates three things: 1. the candidate can write code, 2. the candidate has a grasp of algorithms and can memorize textbook solutions, 3. the candidate can reproduce and explain these solutions.

At first glance, this seems useful. These traits are surely expedient in typical development work. They’re kind of expected from developers. But does the coding interview also measure how well pronounced these traits in a particular applicant are? Can standardised interviews establish a framework for comparison? The answer is sadly no. One applicant might receive a familiar problem that he can solve and pass with flying colours. Another more talented applicant might have never before encountered the same problem and fails to solve it. A third applicant may get bogged down by anxiety. Yet another applicant may solve the problem, but produces bugs because of using an unfamiliar language. The result is influenced by many factors and it is notoriously unreliable.

This is not the only problem. There is a more serious one: the coding interview only probes a very narrow set of skills. Being able to produce algorithms is not sufficient to become a successful developer. For example, a developer also has to read and interpret requirements, communicate within a team and with business people, have knowledge of technologies and best practices, perhaps also have an understanding of certain industries. In this light, being able to memorise textbook algorithms seems somewhat less relevant. After all, you can always look up a manual when in need of an optimised algorithm for a specific problem. This is probably what most developers would do in their day-to-day work.

I remember a peculiar coding interview that took place 10 years ago on the phone before shared online code editors became a thing. I was asked to spell out an algorithm that produces the series of prime numbers. “No problem,” I said, “just let me google the sieve of Eratosthenes.” “No no, let’s just improvise,” said the interviewer, “it doesn’t have to be perfect.” So I scribbled down some similar, yet doubtlessly inferior code that mimicked Eratosthenes’ idea and read it out loud (awkwardly) on the phone. Something I would never do in an actual work situation. Yet, I passed the interview and got the assignment.

Is this a good predictor of professional performance? No, it isn’t. It is way too arbitrary and readily produces false negatives as well as false positives. There is a considerable amount of HR management literature that has identified good and bad predictors for work performance. Among the worst predictors are first impressions, school grades, and brain teaser questions, such as “how many golf balls can you fit into a phone booth?” Finding the answer to that is a lot like devising an algorithm for a geometry problem. You get the clue. Case in point: Max Howell, the author of the popular “Homebrew” package manager for macOS was (infamously) rejected in a Google interview, because he was not able to produce an algorithm for inverting a binary tree. Howell’s software is used by millions of Mac users and is now maintained by a team of 21 people. Yet, he wasn’t good enough for Google.

One of the best predictors for future job performance is past performance. Duh. It’s kind of obvious and also backed up by evidence in the form of empirical studies in management. Had Google considered past performance instead of algorithms, the company would now be richer by one accomplished engineer, who according to his own words cares more about user experience than about computer science. People often have special talents that evade the standardised interview process. They will not escape an experienced interviewer, however. The only problem with past performance is that data is not always available. For example, what about grad students, career changers, and people with little work experience? Well, the second most reliable predictor for job performance is cognitive ability, also known as “g factor” or general intelligence. The literature is again quite solid on this point.

It stands to reason that a standardised and culturally neutral IQ test provides a much better predictor for future performance. And by “much better” I mean an order of magnitude better. It is also less time-consuming than going through a series of algorithm/coding problems. So why are companies not using them? One reason is that in certain countries, such as the USA, IQ tests are seen as potentially discriminatory and could therefore be legally contestable. This is obviously a matter of policy, and well idiocy. Encountering an IQ test in a job interview appears to raise more eyebrows than encountering a esoteric programming problems. Another reason is that high quality standardised and culturally neutral IQ tests are somewhat difficult to develop. And new ones would have to be developed all the time to ensure high quality results and to prevent abuse. Yet another predictor for career success was recently (2013) suggested by Angela Lee Duckworth in a TED talk. She called it “grit”, or the “power of passion and perseverance” and subsequently received a lot of attention from the tech industry. The problem with “grit” is that as of now no reliable way of measuring it has been devised.

So, the question that springs to mind is: why do companies use coding interviews in the selection process if they already know that the resulting score is a poor predictor for career success. Frankly, I don’t know. If you’re a big tech HR manager, please comment and enlighten us. I can only speculate. Companies like Facebook, Google or Apple are swamped with applications and might have to create artificial barriers to filter applications and reduce the number of candidates to a manageable amount for round two. What does this artificial barrier achieve? Perhaps it is about grit. Only the ambitious candidates will pass, namely the ones that are willing to learn and memorise algorithm textbooks just for the interview, and just for getting the chance to land a job with that big tech company. It is reasonable to assume that someone who has the motivation to put in three or four weeks of cramming for an interview, is also motivated to put in hard work into their job. In this case, developer interviews could just as well require candidates to conjugate Latin declinations and cite Roman philosophers. The effect would be the same, although it would certainly raise many eyebrows.

Another plausible explanation is that companies nowadays tend to put processes over people. The decision making process, especially in large enterprises, is highly formalised. Instead of leaving the hiring decision to an experienced HR manager who relies on their personal knowledge and skills, it is relegated to an impersonal procedure that produces data. On one hand, this frees decision makers from personal accountability. On the other hand it provides an instrument that top management can manipulate at will. For example, if management should want to steer their engineering staff into a new direction, it could replace algorithm questions with machine learning questions. Whatever the reasons may be, we can be sure that thousands of smaller tech companies will follow suit and imitate the example of Google, Microsoft and others, even if they don’t understand their reasons and even if the adopted procedures aren’t fitting their own true needs.

In the end, I believe coding interviews are not totally useless. They are an effective means to engage the candidate in his field and simulate a work situation. The coding interview gives the interviewer a chance to observe how a candidate approaches technical problems. For example, it may reveal whether the candidate’s course of action is methodical, or whether they have exaggerated their familiarity with a certain technology. Under ideal circumstances, it can reveal a lot about how a developer thinks. However, since an interview is a special situation these indicators need to be evaluated carefully. For the benefit of all involved parties, the coding interview is best conducted in a casual way. An expanded problem space leaves the candidate with more choices and is is likely to provide more information. I don’t see any good reason, why coding interviews should be conducted like a university exam, however. If you can think of any, please let us know.

Getting Linux rolling

A few weeks ago I upgraded my Ubuntu from 16.04 to 18.04.1. I wanted to do the upgrade earlier, but reports of compatibility issues kept me waiting for the first maintenance release. The upgrade went trouble-free as expected. I think Canonical did a great job on the installer and the Gnome customisations. However, as with previous Ubuntu upgrades, there were quite a few post-installation issues.

The problem I noticed first was that the update had somehow jumbled the hotkey mapping. OK, no problem to fix that manually. Next, I couldn’t connect to the MySQL server any longer as the update had replaced the config file. This was also not a big deal, because the update process saves all existing configs. I simply had to restore the relevant lines. A bit trickier was the PHP installation. It seems that the old 7.0 package was left intact and the 7.2 version was installed only partly by the upgrade. I am not able to add modules to the 7.0 package any longer, since the PPA repositories changed.

I also encountered a few UI problems with scrolling and text pasting. For a week, I could not scroll terminal output back until I found a fix for this problem. Copying and pasting text is very slow sometimes. Could have to do with the switch from Unity to the Gnome shell. I wasn’t able to figure it out yet. All in all, a fresh installation would have been cleaner and less troublesome. However, I don’t want to go through that, as it would force me to reinstall all applications and reconfigure my Docker-based development setup, which surely takes more than a day.

With Ubuntu, or Debian, or in fact any other non-rolling Linux distro, major updates are released at least once a year. Even with LTS releases, you have to update every two years. Most packages are quite outdated at that time. In software development, we are striving to shorten release cycles ideally to a continuous deployment model. Therefore, it becomes more important to keep libraries and tools up-to-date. Simultaneously, deployments and tool chains are increasing in complexity. Hence, reinstalling environments from scratch becomes more cumbersome.

For these reasons, I decided to migrate to a rolling Linux distribution. Ubuntu is great and I really like the ease of installation and the fact that it is stable and well supported. But perhaps it’s time to try out something new. The obvious choice for me would be Arch Linux, so I installed Arch and a few of its derivates in virtual machines to get a feel for it. I am going to pick one of them and maintain the Vbox for a while before installing it on bare metal. As of now, I am not sure whether Arch is stable enough to function as a primary environment for daily work.

The Arch Linux base distro is certainly special. Its installation process is entirely manual and the resulting image is quite Spartan. You have to bootstrap everything by hand and even for someone experienced it takes a few hours until everything, including a graphical desktop environment, is configured and running. The advantage is that the system is completely customisable and can be configured exactly to your needs. Kind of nice.

I’ve also tried Manjaro and Antergos, both Arch-based distributions. They are significantly easier to install and also provide more convenience for configuration. For example, Manjaro has a nice graphical tool for managing kernel versions and Antergos offers six or seven different desktop environments out of the box. Like Arch, they are based on the Pacman installer. Although there are only about 11,000 packages in the Arch repository, the AUR (Arch User Repository) adds another 47,000 packages which is on par with the biggest Linux distributions.

Pogoplugged

Everyone seems to agree that the outgoing year 2011 was the year of the cloud. Judging by how often the word “cloud” was thrown at us by computer vendors, hosting companies, and service providers, it sounds like the greatest innovation since sliced bread. Of course, nothing could be farther from the truth. Cloud computing is not new at all. It has been around since the days of Multics and the ARPANET, at least conceptually. It is neither an invention nor a product, but an application of existing computer technologies, no matter how many companies now try to productise it now. The fuzzy term includes everything from network storage, utility computing, virtual server hosting, to service oriented architectures, typically delivered via the Internet (i.e. the cloud). In fact, the term is so blurry, that even the vendors themselves often disagree what it means, as famously Larry Ellison, CEO of Oracle, before his company jumped on the bandwagon.

Pogoplug 2Most people associate the word cloud with file hosting services such as Dropbox, Windows Azure, or Apple’s iCloud. Today, I want to talk about a product that provides an alternative to these network storage services, which provides in my opinion a superior solution. It’s called Pogoplug and it is a box that comes in a flashy pink. The idea is simple enough. You connect this box with your Wifi router on one side and with your storage media on the other side, and voilà, you get networked storage, aka your own “personal cloud” which is accessible on your LAN as well as from outside via the Internet. Besides connecting the box, you have to get an account with pogoplug.com and register your device. Optionally, you can install software that makes the attached storage available on your LAN as an external mass storage device. There are also free apps for iOS and Android that that allow you to access Pogoplug-managed storage from your tablet and/or phone.

Why is this such a clever product? Well, for two reasons. First, the Pogoplug is low-cost and easy to use. Second, it provides solutions to multiple problems. Let’s start with the first. The basic Pogoplug device costs 50 USD, and the web account is free. You can plug up to four external hard disks or flash memory sticks into the four USB ports, so one could easily realise four or eight Terabyte total capacity. External hosting is expensive by comparison; for example, a 50 GB Dropbox account costs 10 USD per month; with Apple’s iCloud it’s 100 USD per year for the same size. There are cheaper alternatives, such as livedrive.com or justcloud.com, but the annual expense still exceeds the cost of a Pogoplug device. What’s the catch? The download speed via Internet is limited to the upload speed of your Internet connection, which for the average DSL user is typically lower than the access speed of an external file storage service. Filling the Pogoplug devices with data, on the other hand, is much faster, because you can access the drives locally.

Now, about the multiple solutions aspect. What I like about the Pogoplug device is that I can reuse my external backup disks as network storage. I work with redundant pairs of disks, whereas one disk is plugged into the Pogoplug at all times and the other disk is used to create backups from my computers. In the second step, I mount the Pogoplug to my Linux workstation and synchronise the online storage with the fresh backups via rsync. In addition, I use my Pogoplug as a household NAS and media server. This comes in very handy for viewing my photo library on a tablet, or for streaming audio from my music collection to my phone. As long as I stay within my house/garden’s Wifi range, the data transfer happens at Wifi speed. Streaming movies is a little trickier. Usually I download movies from the Pogoplug to the mobile device before viewing.

In summary, the product offers a miniature file server for local access via LAN/Wifi and remote access via Internet plus some streaming services. Authentication service is provided by the pogoplug.com web server. As of late, you also get 5GB free cloud storage space externally hosted by pogoplug.com, which is likewise accessible via mobile apps and can even be mounted into your local network. The pogoplug device itself consumes only 5W, less than most NAS or mini PC servers. Obviously, the power consumption increases when connected USB hard disks draw power from it, so the most energy-efficient solution is probably to use either flash memory sticks or USB-powered disks that stop spinning in idle mode. Additionally, the Pogoplug device can be deployed as a LAN print server. Those who are comfortable with Unix administration and scripting can program the Pogoplug device to do even more.

Website: www.pogoplug.com

Specifications:
1.2GHz ARM CPU with 256MB RAM plus 512MB Flash storage,
4 x USB2 ports, 1 x 10/100/1000Mbps Ethernet port, integrated DC power supply
Supported Filesystems: NTFS, FAT32, Mac OS, Extended Journaled and non-Journaled (HFS+), EXT-2/EXT-3
Supported Browsers: Safari, Firefox 3, IE7, IE8, Chrome
Supported AV File Formats: H.264, MP4, AVI with motion JPEG, MP3

The mighty paper UI

Supermarket

I went shopping last weekend, and since my capacity for remembering things is slowly degrading (sigh) I often make a shopping list when I have to buy more than 500 items. Okay, maybe that's a bit exaggerated. I mean 50 items. Alright, alright, still exaggerated. I begin to consider a shopping list when I have more than 5 items to buy and I definitely make one if there are more than 10. So, I'm on my way with my shopping list, which -befitting my rank as a software engineer- was stored on my smart phone. Just a few years ago, this might have been considered geeky or eccentric, but nowadays smart phones are so common that it hardly catches anyone's eye. I frequently take notes on my phone, for the simple reason that I have it always with me, and it's often closer than a notepad or a diary.

So there I was in the supermarket, having to check the contents of the shopping cart against my list. No problem, of course. Take phone out pocket and switch the display on to show the main screen (2 sec). Tap on main screen to show launcher window (1 sec). Drag launcher window contents with finger to scroll to memo pad application (1 sec). Open memo pad application (1 sec). Locate shopping list on application menu and tap on it (1 sec). Mind you, that's an optimistic estimation, because something might run more sluggishly than usual. For example, the phone might have discovered a Wifi hotspot and thinks it's a great idea to tell me about it. But I don't want Wifi. Now, six seconds doesn't sound too bad, until I noticed the guy next to me. He had a shopping list, too, one written on paper. He took it out of his shirt pocket in less than a second. Swish. Just like that. Han Dynasty technology beating the smart phone.

That's when I realised, there are situations when you can't trump a paper based UI.

Computing 2010

pc.jpgToday, I came across an interesting article in the Forbes Magazine entitled “Computing 2010”. The interesting part is that this article was written ten years ago. The author, Kip Crosby, imagined what computers would look like in 2010: optical circuits instead of silicon, with a CPU running at 100 GHz, holographic mass storage offering several TB capacity, 256 GB optoelectronic RAM, biometric authentication, voice control, completely wireless and shaped like a frisbee. Whew! Looks like Kip was just a tad too optimistic. Optoelectronics hasn’t caught on and most computers are still boxy rather than frisbee-ish. In fact, todays’s PC looks pretty much like that of 2000, except that its capacity has increased roughly following Moore’s law. The only accurate prediction is about mass storage capacity, although that didn’t require optical technology.

Personally, I’ve begun the new computing year with a major upgrade, though still far away from Kip’s 2010 vision. I have replaced my 32-bit Windows OS with a 64-bit Linux OS, doubled RAM from 4 GB to 8 GB and added another external USB hard drive for backups. The Ubuntu installation turned out a little difficult, because Linux did not want to cooperate with the BIOS RAID-1 configuration, so I had to switch to SATA mode and wipe out the Windows installation. The rest was easy, however. I used to worry about not being able to make my 3G USB modem work with Linux, but our maid has solved this problem for me. She obliterated the device by putting it into the washing machine. Can’t really blame her for that. I probably shouldn’t have carried the modem in the pockets of my shorts.

Back to the topic. What are the computing trends in 2010? Just off the top of my head: cloud computing is becoming a mainstream technology (or perhaps a mainstream buzz; time will tell). Along with that, virtualisation is now widely used. Supercomputers have broken the petaflop mark and now operate in the range of large clouds (> 1 PFlop). CRT monitors are quickly becoming relics of a past epoch. Single-core CPUs are headed the same way. Functional programming languages are beginning to catch on. 64-bit hardware and software are overtaking 32-bit systems in mainstream IT. Java 7 is announced for 2010. It surely looks like an interesting year.