A future post will detail specific suggestions to aide one in preparing for software interviews

This post will detail my opinions regarding the interview process at many software departments (or companies)

I am uniquely qualified to give a (1) valid (2) opinion regarding the matter given that I initiated a "mini-job singularity" (hehe) and have been interviewing with hundreds of companies for some time

Tracking company productivity and outcomes gives some measurement, albeit fuzzy and imprecise, regarding how effective the interview process is at screening unqualified candidates and bringing on candidates who actually add value

Interview - Biases

Many companies place undue emphasis on one of the following:

(1) Using a specific tool set - 'tool' meaning a specific text editor, OS platform, or integrated development environment.
(2) Esoteric questions that have little, practical, day-to-day application.
(3) An emphasis on productivity (understood as raw typing speed) rather than on best practices, stability, and technical debt reduction.
(4) Emphasis on questions pertaining to boiler-plate code.


Regarding (1), abstraction platforms such as Docker and various hypervisors enable cross-platform development environments to be deployed easily and at zero monetary cost. Hence, insisting on a particular OS is unwise. A comprehensive mobile solution usually requires having many different OS's or machines anyway (at least for the dedicated mobile team if there is one).

Furthermore, requiring developers to use a particular OS, machine, or integrated development environment can be counter-productive - if they can do something in 5 minutes on the OS, machine, or integrated development environment that would take 15 minutes to do on the required option, you've lost time. Best practices insist that deployment should be cross-platform anyway. You avoid vendor lock-in and, in the case of integrated development environments, have access to smarter and more robust tools (which often exist for different integrated development environments - JetBrains products have comprehensive integration plugins, Sublime Text 3 is incredibly lightweight and can be used for minor coding changes, etc.). Streamlining security compliance is an important consideration but many tools exist to accomplish just that... and across platforms.

Regarding (2), testing for breadth of knowledge is important but wasting mind-space by requiring recitation of esoteric knowledge is counter-productive. Research should always accompany any major new functionality anyway (given the increasing speed of software innovation - new specs, new tools, new libraries are coming out with increasing regularity every week). Most esoteric concepts in software are subject to change and hence, it's almost irrelevant to ask all but the lead developers to waste their time on such things. If they're interested out of curiosity or passion, rock on. Mandating this as part of a standard interview is ill-advised. This also breeds a petty culture whereby knowledge of irrelevant or esoteric things is used to jockey for position rather than creating a collaborative team environment.

Regarding (3), cowboy programmers are still quite popular among non-technical types. This conforms, I suppose, to the media's portrayal of programming on TV and in movies. These programmers hammer out code without consideration of best practices and technical debt reduction or absence. It's oft-quoted that 60% of a software company's cost stems from technical debt. Technical debt means mistakes, bugs, ill thought-out architecture, lack of best practices (like extensibility), etc. This results in high turnover, the nightmare of migrating entire code-bases, extensive and painful job searches, etc. Many bad developers openly encourage making mistakes in code, shunning net-positive developers, etc. because by creating problems they (the bad developer) ensure that they and they alone (meaning that their job security or position isn't threatened by net-positive or good developers) have job security.

Regarding (4), demonstrating basic proficiency with code is very important but many employers skip over available or submitted portfolio repositories (like GitHub) - if your development team knows what they're doing, they can tell whether the code is forked, correctly infer what the commits say about the developer, etc. If someone has a proven track-record working on a technology, the focus should be on how to do something new, rather than on rote memorization and recitation of boiler plate concepts. I've been in several interviews where such a question was asked and I was told that I was wrong (though the specification had changed matters significantly). For example, I was told in one interview that, "JavaScript is client-side only with no OOD capabilities". Dead wrong.


Review submitted portfolio samples, particularly if they're available on GitHub or other such hosted portfolio platforms.

Give a coding assignment. Tell the developer that they will not be judged on how they actually approach coding it, only on the end result. Such tests do need to have a reasonable time expectation attached. Ask the developer if it's OK to record or watch them as they code and to explain their reasoning. Demonstration of how they learn is far more important than what they currently know. Speed at finding answers is far more important than recitation of basic or esoteric concepts. Furthermore, if you interview a genius programmer, you'll probably learn a lot. That's knowledge that your company can implement as part of a superior junior mentoring program.

Review a candidate in a holistic way rather than focusing on programming (which is usually the least important part of what a developer actually does - setting up unit tests, solving problems, reasoning through situations, finding the best way to implement something, etc. are far more important than just recalling specific syntax or functions).

Paid trials are a useful way to really test how someone codes or what they can do. A paid trial is not contract-to-hire but something like "we have this functionality x we'd like to build and we have this senior developer who's working on it - why don't you work with them for a week and we'll see where you're at" - this can be cheaper than the traditional hiring process which at most companies involves expensive recruiting and time-consuming meetings. This is how it works at many high-growth early-stage startups.

You'll notice that companies like Google and Facebook have 7-10 lines of job expectations and requirements. Years of experience matters a lot less now. Get a bigger pool of candidates and you have your pick of the litter. Make sure your salaries are actually competitive. Be open to intrapraneurs who get an equity-stake in zero-cost projects that enable you to grow out a services ecology or launch startups at little risk - this incentivizes robust innovation in a manner similar to how Google and Virgin expanded in their early days, reduces risk and cost, and provides mentoring and business experience opportunities between senior management and people who would otherwise run off to start their own external startup (bad for PR).