Hiring is Broken In the Software World

 

Meticulous.  Well-dressed.  And fit enough to help you dispose of that obsolete mainframe.  A 10x engineer.

Oh, I have some thoughts on the Tech interview process.

The current standard for tech hiring is so byzantine, there's a whole industry built around helping people succeed with tech industry interviews that rivals SAT prep courses.  The target demographic is the set of engineers hoping to score jobs at what used to be labeled the FAANG companies (at the time - Facebook, Apple, Amazon, Netflix, and Google).  The expectation is that if you can land a job there, you're set for your career.

I can't say I'm convinced.  I have no problems with people working for those companies (indeed, many of my friends and ex-coworkers either worked in those places or are still working there to varying degrees of happiness), but I've never worked for any of them and find myself a competent engineer and manager and satisfied with the arc of my career.  Then again, I'm unemployed and communicating primarily through a medium that was last popular in 2008, so maybe I need to raise my standards.

Most of the technical interviews we put potential engineers through follow a script similar to "Implement this type of sort," or "Implement this algorithm and discuss its computational complexity.  Now find another implementation that's less complex."  

Regardless of whether or not you're striving to work at the companies above or somewhere else in the Tech space, the interviews all follow similar patterns:

• You will be asked several variations of the algorithm question above.  It won't matter if you've got no experience or 10 years of experience.
• Not only will you get these with one interviewer, you will probably get them with several interviewers.
• If you're lucky, you will go through several rounds over several days of this to prove yourself to your prospective employer that you're worthy.
• Before doing all of the above, you will likely be given a coding exercise that is expected to take several hours to complete and has a relatively tight deadline.  I mean, you should eat, breathe, sleep, and shit code, right?  If not, you're not a software engineer and probably don't deserve to take up space on this planet.
• You may also be asked to show your GitHub portfolio, because, again, being a professional isn't enough.  You must show that you think of nothing else but software, because a singular focus in life is healthy.
• If you're even luckier, you may be interviewing with a company employing the "try before you buy" model of interviewing where you get to work for the company from 1-5 days.  Sometimes for free!

As a friend once told me when I asked why we, as an industry, follow this pattern, his response was "Because quality across the industry is so variable and we need a baseline to measure against."

I agree with that statement, but I agree with that statement regardless of what industry you're talking about.  I've had a hunch for a while that this pedantic style of interviewing is more pervasive in software because software isn't directly coupled to the real world (in most cases - unless you're writing software for controlling jets - and given recent news cycles, I'm not even sure about that).  In theory, you can write the perfect application with enough time and effort.

Except you can't.  That software is built on physical hardware that must obey the laws of physics and as Bitcoin and GenAI show, there are real-world constraints to running massive computing at scale.

But software engineers still indulge in platonic ideals, including around hiring, so here we are.

As a counter-argument, I was a Mechanical Engineer before I got into software, and none of my prospective employers asked me to walk through the calculus for black body radiation.  They asked me about my classes and my previous experience.  Granted, it's been a couple of decades since I interviewed for any ME positions, but I don't believe the experience has changed much (if any of my ME friends are reading this and want to correct me, feel free).  If other engineering disciplines don't need to have the candidate jump through hoops, what's so special about software engineering?

I will grudgingly accept that you can ask new college hires questions like "implement bubble sort and tell me what the computational complexity of it is.  What are the complexity bounds of search and sort?"  College hires rarely have enough of a body of work to distinguish them from other candidates, so you're generally evaluating them on potential.  But, even then, I believe you can use basic questions to probe their potential that aren't essentially tech trivia quizzes.

The other trend that drives me nuts is "write an algorithm that does X" knowing that the initial solution for the algorithm can be "optimized," and that, if the candidate can't optimize the algorithm appropriately, they lose valuable interviewing points (those things are gold.  You can often trade them in for sea monkies or x-ray specs).

Often, the initial solution involves a nested for loop (OMG the complexity is O(n)^2 - everyone brace yourselves for performance impact!) that you're supposed to improve.  Except that, if you're working on a web app, the network is likely to be far more latent than any code you're writing.  And that double for loop is probably much more readable than whatever clever one-liner you've been asked to produce.  And the compiler/interpreter and CPU you're likely running on will optimize your inefficient code.

How is pointing out any of the things above any less demonstrable of someone's competency than writing some code that will never run in O(n)?  It's probably because people tend to equate complexity with genius, when, often, simplicity is much more indicative of creativity and a well-built system.

Simplicity is often taken for granted because it seems obvious after the fact.  But don't confuse the outcome with the effort needed to construct the obvious outcome.  Creating a genuinely simple system is extremely hard work.

So, how do you interview software engineers?  Use behavioral questions.

I can hear a collective groan rise up as people think of rotely reciting things like "Tell me about a time that you wanted to beat a co-worker senseless but instead assumed positive intent and bottled your frustration up in accordance with the corporate code of conduct" to some poor sap across the table.

But they don't need to be so tedious.

The simple prompt "Describe a project that you enjoyed working on.  Why did you enjoy that project?" can open up a goldmine:

• It helps gauge the interviewee's enthusiasm.  They're focused on their own tangible experiences, so even if they tend to be more introverted, you have a better chance of getting them to open up.
• Because it's an open-ended question, it forces them to show their thinking process.  They can't struggle in silence getting more and more nervous and more and more defeated as the minutes tick by.
• It can easily be extended to probe technical details.  If the answer to "Why did you enjoy that project?" is something as benign as "It introduced me to highly scalable systems" it leads to other prompts like:
• What applications did you use to manage the systems?  Why?
• What did you find difficult about scalability?
• When you say scalability, do you mean distributed systems or concurrency on a single machine?
• If it's a distributed systems problem, you can ask them if they're familiar with the seven fallacies of distributed computing.  If you've already got them talking, they're less likely to freeze up if they're not familiar with the list or can't recall it.
• ...and so on.
• People feel more comfortable talking about things they like, and your interview should be about making people feel comfortable.  Software engineering is a cushy job.  Trying to put people under artificial stress that they're likely never going to face is sadistic.  Even if the job is stressful, you can't test that response ahead of time (the ethics of doing so notwithstanding), because stress responses are highly variable to specific environment and temporal cues.

Finally, when hiring, hire across the spectrum of experience.  Netflix historically only hired senior engineers and it seemed to work for them (although they've apparently changed their strategy recently, so there must've been some gaps).  I don't see the value in it.  I know they explicitly stated that they'd prefer to let someone else train their talent, but that misses a huge part of what makes a compelling corporate culture.  Doe-eyed college hires give your engineers chances to mentor and result in a constant influx of new perspectives - both technically and culturally.  You need those new perspectives if you want your business to thrive.  It also makes you a better person.

Until next time my human and robot friends.