Just like many other people, I was following news from the last week’s BUILD conference with piqued interest. The ability to run Linux userland programs on Windows — including, of course, bash — is something to be excited about. If nothing else, it should dramatically improve Windows support of new programming languages that seem to pop up all the time.

There was something else, however, that I couldn’t help but notice. The reactions of tech communities to this and similar developments focused very frequently on Microsoft itself.

The beloved “new Microsoft”, as some call it, embraces open source, supports Linux, and generally does almost a full 180 with their stance on proprietary vs. free software. The circumstances fit this narrative rather snuggly, too: a new CEO makes a clean break with the past to pivot the company in this new world ruled by mobile and cloud.

Still… love? Even considering how Internet comments are grotesquely exaggerated most of the time, that’s quite a declaration. The sentiment is nowhere near isolated either. But it’s not a question whether this infatuation has a rational merit, or whether those feelings will eventually turn out to be misplaced.

The question is: why does it exist at all? We are talking about a company here, a for-profit organization. How can such a language even enter the picture?

Then I realized this is not really a new phenomenon. Quite the opposite: the broad developer community seems to always need a company to champion its core values. Nowadays, we’re simply trying to find someone new to carry the standard.

Why? Because we feel that our old heroes have forsaken us.

Hall of past fame

Take GitHub for example. Once a darling of the open source community, it’s been suffering sharp criticism for many months now. Rightfully or not, many people aren’t exactly excited — to put it mildly — about changes to the policy and atmosphere at GitHub, typified by the ill-fated meritocracy rug. The widely backed and long standing plea for a few critical features has only recently stopped falling on deaf ears. And in the background, there are always concerns about GitHub simply becoming too big, and exterting too much control over the open source ecosystem.

Nota bene, the very same ecosystem it had once been lauded for nurturing.

Among the other flagship tech companies, Apple or Facebook have never garnered much good will. Sure, they are recognized for the pure utilitarian value of hardware they produce; or convenience, broad applicability, and stability of APIs they offer. Facebook may be scoring some additional points for trying to sort out the mess of frontend development, but many say it’s not doing anybody any favors. Neither company is easy to portray as a paragon of openness, though, and it’s probably easier to argue the exact opposite.

And then there is Google, of course¹. Some time in the past few years, a palpable shift occurred in how the company is perceived by the techie crowd. It’s difficult to pinpoint the exact pivotal moment, and the one event that leaps to attention doesn’t seem sufficient to explain it. But the tone has been set, allowing news to be molded to fit it. Add this to the usual backdrop of complaints about the onerous interview process and general fearmongering, and the picture doesn’t look very bright.

Shades of grey

No similar woes seem to have been plaguing Microsoft as of late, even though their record of recent “unwholesome” deeds isn’t exactly clean either. Does it mean they are indeed the most fitting candidate for a (new) enterprise ally of the hacker community?…

Or maybe we can finally recognize the whole notion as the utterly silly concept it actually is. Hard to shake though it be, this quasi-Manicheic mentality of assigning labels of virtue or sin is, at best, a naive idealism. At worst, it’s a peculiar kind of harmful partisanship that technologists are particularly susceptible to. You may recognize it as something that has a very long tradition in the hacker community.

But it doesn’t mean it’s a tradition worth keeping.

Continue reading

If you look at discussion forums for people in the CS industry — like /r/cscareequestions or even just Hacker News — you’ll find lots of talk about the so called Big Four companies.

This is mostly in the context of applying to them, or going through their interview process. Which of the large software corporations are discussed here tends to fluctuate a little bit, but both Google and Microsoft are invariably included, with Facebook popping up more often than not.

Because of their privileged positions as very desirable places to work, these companies tend to be taken as models for others to mimic¹. Probably the most apparent and direct outcome is the increasing prevalence of “Google-style” interviews, which are now utilized by countless software shops around the world.

Whiteboard coding is how they are often called. It is a subject of an intense debate, whether or not they “work”, and adequately assess the engineering aptitude of candidates. If some high profile anecdotes are of any indication, the most common complaint is that they fail to recognize competence by ignoring previous professional work, open source contributions, conference talks, and so on.

Instead, the whiteboard interview requires demand showing a “pure” problem solving ability within a relatively short time window, all without some broader context or even the usual tools of the trade: laptop, editor, and a search engine.

As a Googler who had gone through this process and has now conducted a few of those interviews himself, I find those complaints mostly valid albeit misdirected.

The problem isn’t really that Google interviews like it does.

What’s really the issue is other companies implementing the same process, and not realizing it cannot possibly work for them.

Somewhat special

It is important to understand that Google’s stance on interviewing is influenced by some unique circumstances:

• very high and steady influx of potential candidates

• comparatively long tenure of the average engineer and the general focus on employee retention

• huge and mostly proprietary software stack working at a scale that almost no others do

From this perspective, it makes sense to utilize cautious hiring strategies that may result in a high ratio of false negatives². When rejections are cheap but the new hires are supposed to be here for the long run — partially because of the long ramp-up time necessary to become productive — it can be costly to give candidates the benefit of the doubt.

The last point also explains why proficiency with specific technologies is less useful than general flexibility grounded in strong fundamentals. To put it shortly, Google prefers you know CS rather than CSS.

Finally, whiteboard coding is just one input to the evaluation process, but it tends to be the most trustworthy one. Besides programming aptitude, the ideal candidate would show a proven track record of technical leadership while tackling complex problems that span a broad scope.
Unfortunately, those qualities are difficult to convey efficiently and reliably through the usual industry channels: a resume, references from previous jobs, GitHub profile, etc.

Different conditions

Given the above reasoning as to why “Google-style” interviews seem to work well for Google, I hope it’s evident why they are likely a poor choice for companies that don’t share the same characteristics as the Big 4.

For one, it is highly unusual for a software shop in today’s market to command a sizeable pool for qualified candidates. Software engineering vacancies often go unfilled for weeks and months, even if the company isn’t exactly looking for “rockstars”, “ninjas”, “gunslingers”, or whatever the silly term du jour is. Those who meet the requirements usually have their pick at many different offers, too.

The reality for many companies (especially startups) is also one where they are unable or unwilling to invest much in the retention of their employees. Because the employment relationship in this industry tends to be quite volatile (which isn’t necessarily a bad thing), it often makes sense for companies to look for a near-immediate payoff when hiring.

We owe it to the prevalent open source technologies that this isn’t entirely unreasonable. If your software stack is composed entirely of components that are available in the open, you can probably find engineers who are familiar with most of them. They can be productive members of your team almost literally from day one!

Right tool for the job

The most important observation is that every company is different, and following the One True Best Practice™ will likely prevent you from utilizing the best qualities of your work place. Smaller shops, for example, could take a more personalized approach to hiring: let candidates actually sit with engineers, solve real-life problems, and have deep technical conversations.

Of course, you may still find whiteboard coding valuable in its own right. Indeed, a simple test for at least the basic programming skill appears to be a necessary sanity check.

But a full suite of difficult technical interviews with tough algorithmic problems that last a better part of the day? Most likely not.

Continue reading