Stories about Software


Hiring is Broken… And It Isn’t Worth Fixing

Usually I fly home from client sites late in the day, but the whims of fate had me driving home instead, early (for me, anyway) this morning.  The end result was a pocket of uncommon free time this evening, before resuming long days and seemingly non-stop travel on the morrow.  Naturally, I wasted this free time poking around the internet.

My travels led me, via Twitter, to this blog post entitled, “F*** You, I Quit — Hiring Is Broken.”  Apparently, this led to some heated, sometimes-angsty debate on Hacker News, where the original piece earned a good number of points.  And, why wouldn’t it?  “Hiring is broken” would serve as a rallying cry for those who don’t play the interview game well, while seeming a shot across the bow of those who do and are now on the other side of it.

Read the article, please.  You need to for context, because when I reference it further, it’ll just be a reductionist tl;dr.  I’ll come back to that.  First, I’d like to address one of the few points that almost everyone seems to agree on, before they get down to armchair dissection of Sahat’s character and market worth.

The hiring process is imperfect deeply flawed (if not broken), but no one knows how to fix it.

Except, that’s not actually true, because I know how to fix the interview/hiring process.  It’s actually pretty easy.  Just stop doing it.  If the value proposition you’re offering to prospective laborers is so weak that you have to solicit and subsequently torture strangers, you should prioritize fixing your organizational mess above making the mess larger (or, in the case of attrition, before doing the same thing again).


I’m honestly not kidding, but let me come back to the mindless growth point later.

A Sort of Impedance Mismatch

Let’s return now to the post and the tl;dr.  Here’s my summary of Sahat’s essential complaint.

I’ve built some open source tools, shared some tutorials, and built a following in the programmer community, all of which constitute a form of social proof and demonstrated value to the industry.  But when I go to apply for jobs at a lot of organizations, particularly large ones (only Google is mentioned by name), none of this seems to matter.  They could learn about me if they looked at any of this, but they don’t.  My experience interviewing across the board has been so depressing — so assembly-line and bureaucratic — that I’m ready to give up.  I don’t think that I’m all that great a programmer, necessarily, but clearly people out there value what I do, and there’s clearly a programming shortage, so something doesn’t add up.

The conclusion here is that the hiring process is broken.  Companies need talent, he has talent (which he feels is at least somewhat demonstrable by his community presence), and there’s a recruiter-driven, bureaucratic mass in the middle preventing a happy match.

I’m going to post part of the first comment that shows up in response to Sahat’s post, from Erick, a software engineer at Google.

I don’t have time to read your github projects, or your blog, or your existing code, or your meticulous attention detail in your commit messages. I get a resume in, I look at it for 10 minutes, if it’s sane I set up a phone screen. ONLY to prove that you can pass the most basic coding test. You need[sic]

Once we meet in person, you need to show me that you can code and articulate a design to a problem. The format sucks, sure. But you need to be prepared. I’m not going to spend 2 hours reading your blog for every candidate that I interview. I don’t have time for that.

(As an aside, this is an example of a defender of the hiring process conceding that it’s not actually all that great — in this case, “the format sucks.”)

This comment got 64 hearts on Medium, whatever that means.  I’ll assume it’s upvotes, and so I’ll assume that this is a popular counter-point to Sahat’s popular post.  And it sort of encapsulates a basic valuation of the process.  Sahat (having been spurned) says, “your hiring process is broken because it didn’t select me.”  Erick of Google says, “now wait just a minute — it’s obviously not broken because it did select me.”  I get that they’re not actually saying this consciously, but there’s clearly skin in the game on either side.

But let’s look a little beyond that at the personas and see that they’re both right.  Sahat has poured a lot of work into open source and community contributions, and people around him have expressed that they derive benefit from this.  At the very least this means that Sahat can ship software and mentor newbies.  That’s what companies are looking for, but instead of spending half an hour looking at his body of work, they spend half an hour peppering him with trivia.  It wastes his time.

Erick is busy and he’s being saddled with dozens of resumes to sift through on top of his job writing software.  And, you can bet that happens in his nominal free time — Google doesn’t hire chefs and masseuses and jugglers and whatnot out of the goodness of its heart, but because it wants employees to spend lots and lots of hours at the office.  Google is a megacorp that probably needs to feed 1,000 newbies a day to the internal machinery, so his job isn’t to look for unique snowflakes but to thumbs up a handful of these things and go home.  Google jobs are in high enough demand that, even if some recruiter does initially reach out to you, the onus is on you to prove yourself, since there are 200 people just like you, competing for this role.  Read your github profile?  You’re wasting his time.


And herein lies the impedance mismatch.  Interviewees want to be evaluated and match-made as individual humans while interviewing organizations (large ones, anyway) want to evaluate people as livestock commodities.  Who’s right?  Well, I dunno — it depends whether you’re looking for a meaningful connection or for a serviceable burger.

Handling Interview Bureaucracy

This is shaping up to be a long post, as mine often are, but I do promise to come back to my opening concept of not hiring.  But first, I want to talk about the trouble I have with Sahat’s perspective.  It has nothing to do with him thinking these interviews are stupid — he’s absolutely right about that.  It has more to do with his choices, such as knowing about Google’s process and doing it anyway.  Why do that at all?  And why do it again and again at other large orgs and at startups imitating large orgs with their hiring processes.

So if you’re in Sahat’s position, here’s my advice for you, and I’ve blogged about this before.  Don’t take interviews with Google and other megcorps with this style of interview.  Seriously, just don’t do it.  At one time, these companies were scrappy, little startups with game-changing innovations.  Now they’re more like government agencies than world-beating innovators.

I mean, seriously, listen to Erick’s description of Google’s hiring process.  When I’m hiring programmers, I don’t have time to look at your background and see if you’re good at programming — I just get resumes, scan them for keywords, set up a phone screen and administer the trivia.  Is it just me, or are you half expecting him to tack on, “look, buddy, I don’t care about your ‘civil liberties’ — there’s a lot of people behind you, so just take off your shoes and belt and go through the metal detector.”  But instead of asking you to put all of your liquids in 3 ounce containers, he just concedes that the process sucks.


And that’s where you want to work?  At an organization so innovative that the best they can do when it comes to hiring developers is to act and talk like a government-sponsored bureaucracy?  Yup, everyone knows it’s stupid, but the process is the process and that’s that.  Good grief.  If you want to work at Google, forget the DMV out front — keep working on the open source stuff until they buy you out, and then negotiate form a position of strength.

But, even if you know enough to avoid silly interview processes by preceding reputation, that doesn’t insulate you against all of it.  Start by telling recruiters, up front, that you don’t do trivia interviews and the like.  Be firm and explicit about this, as in, “if they start asking me to describe merge sort, I’m going to thank them for their time and tell them I need to go.”  You need to make it clear to the recruiters that it will be embarrassing for them if they don’t facilitate this requirement of yours.  If you want to see this in action, here’s a page to which I refer recruiters, which contains a list of requirements for me to consider agreeing to an interview or a gig with a company.  On of the requirements is as follows.

For interviews, no brain-teaser-oriented interviews or algorithm-centric interviews (see “The Riddler” and the “Knuth Fanatic” from this excellent video about interviewing anti-patterns).  I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago.

Finally, if you’re already in the interview and this stuff starts flying at you, then excuse yourself.  A lot of people say this, and I think they’re mustering some bravado and creating the impression that they would stand up, harrumph, and declare, “this is beneath me, and I say good day to you, sir!”  That’s silly — it’s just bridge burning.  Don’t do that.  But don’t keep going.  Instead, be apologetic, diplomatic, and earnest, and do it all while subtly shifting the power balance.

“Alright, why don’t you head on up to the board and show me how you’d balance a binary search tree.”

“Hmm… you know what?  I’m really sorry, but I think maybe we got our wires crossed somewhere here.  I’ve had experience on the hiring side of this sort of interview style in the past, and I’ve seen it result in some really sub-optimal matches, so I’ve adopted a policy of having certain deal breaker cues in the interviewing process.  So at this point I can safely say I’d be unlikely to accept an offer, and I really wouldn’t want to waste any more of your time.  To make up for the time I have wasted, I’d be happy to put you in touch with people in my network that I think would be a better fit for this style of organization.”

Let’s review.  What you’re really saying (very nicely) is “you need to work on your hiring process, so I’m not interested in working here, but I can probably scrounge up a few of the kind of C players that would be a better fit for you.”  You’d be amazed at how quickly people reassess you and alter the narrative of what’s happening to save face.  It’s unlikely that they’ll reverse course and make you an offer, but you’re turning an impression of “meh, that loser didn’t make the cut” into “crap, I’m going to run to do some research on hiring best practices… just to prove that guy wrong, of course, but, seriously, ohmygod, are we doing it all wrong?”  (If you’re a regular reader, what’s actually just happened is that you’ve refused to play the sucker’s/idealist’s game of “trivia contest” and offered an assessment of the organization that’s above the interviewer’s paygrade, which is some opportunist-fu that will blow the idealist’s mind).

Stop Hiring

Hopefully, if enough people stop lining up for the airport security screening process that is hiring at big tech companies, the emerging labor shortage will cause them to grow up and innovate when it comes to staffing developer talent.  But, I wouldn’t count on it.  The interview in its current incarnation has as much momentum as it does ineffectiveness, and I don’t expect it to die the death it should anytime soon.

So let me instead, put on my organizational hat and be philosophical.  As I said in the beginning, I think the solution to broken hiring isn’t to fix it, but to stop it.  And, by “it” I don’t mean to stop bringing on new people, but rather to stop asking strangers to submit pieces of paper full of exaggerations for your review so that you can bring them in cold, grill them for a few hours, and then welcome them to the family.  Wow, it sounds almost… stupid.. when you describe it as exactly what it is.

Rather, what if you simply placed a creative constraint on the organization that it could not grow by hiring strangers or unknown commodities?  I’ll grant you that this is an incredibly tall order, and the easiest thing in the world would be to list all the ways it could never work or all the concessions that would be needed.  You’d have to grow a lot slower!  Yes, probably, but I don’t know that growing like an out of control virus is the only way to succeed.  You’d lose out on entry level talent!  Maybe, or maybe part of your operations would be getting to know college kids.  You’d be hiring based on nothing more than someone’s word!  Well, you’re already doing that, but with someone that no one knows.  And the list goes on.

I think of this in the same way that I think you’d have seen the Tesla a lot sooner if someone had waved a wand and said, “starting in the year 2000, cars can no longer be powered by gasoline.”  When the status quo isn’t causing an international panic or creating an obvious and massive market opportunity, people are pretty comfortable with it.  But if you imposed a constraint on yourself (ala Tesla), you might be amazed at what you could accomplish.

As I’ve started to explain in detail in my book, I’m more and more convinced that the next decade will show us a massive drop in the numbers of software developers working for megacorps and for non-software companies.  The fact that the hiring process for developers, at scale, is garbage is just one reason, but it’s an important one.  It’s so important, in fact, that let’s stop trying to fix the hiring process and start trying to figure out how to replace it.


Please Stop “Geeking Out”

Mostly, I try to stay away from semantic quibbling and I almost always try to stay away from anything sensational, so please forgive me in advance.  I’m taking a hard line of sorts with a blog post entitled, “stop geeking out.” and I’m somewhat doing so for effect.  But this is coming from a place of earnestness.

I don’t really care too much about the term “geek” in and of itself; it’s the concept of “geeking out” that frustrates me.  And it truly is the concept — I’m not interested in term policing.  It’s not like I’d blow a gasket and be insufferable toward someone saying this in front of me; rather saying it in front of me inspires sort of a vague sadness in me, upon which I wouldn’t bother to comment.

But before I get to the reasons for my objection and my sadness, let’s take a look at the origins of the term “geek” as we know it today, originating from the idea of a “geek show.

The Online Etymology Dictionary give the following for “geek”: “sideshow freak,” 1916, U.S. carnival and circus slang, perhaps a variant of geck “a fool, dupe, simpleton” (1510s), apparently from Low Ger. geck, from an imitative verb found in North Sea Germanic and Scandinavian meaning “to croak, cackle,” and also “to mock, cheat.” The modern form and the popular use with reference to circus sideshow “wild men” is from 1946, in William Lindsay Gresham‘s novel Nightmare Alley (made into a film in 1947 starring Tyrone Power).

The billed performer’s act consisted of a single geek, who stood in center ring to chase live chickens. It ended with the performer biting the chickens’ heads off and swallowing them.[1] The geek shows were often used as openers for what are commonly known as freak shows. It was a matter of pride among circus and carnival professionals not to have traveled with a troupe that included geeks. Geeks were sometimes alcoholics or drug addicts, and could be paid with liquor – especially during Prohibition – or with narcotics.

Okay, so quick recap.  Before the term meant “technology enthusiast” it meant, “idiot substance-abuser that earns a living performing unspeakable acts to amuse mobs.”  That’s quite the transition!


The Historical Connection

Let’s examine that transition a bit.  When I was a kid in the 1980s, I remember “geek” being an insult, but it was sort of interchangeable among a bevvy of insulting synonyms: dork, dweeb, nerd, etc.  You can go looking for meaning in a taxonomy if you’re so inclined, but I don’t remember much distinction.

But, as I’d learn later, “geek” had a special and unique flavor of implication.  It conveyed obsession and interest in technology.  Interesting.  But how do you get from “slow-witted alcoholic that will eat chicken heads for free booze” to “guy that really, really likes computers?”

Read More


Why You Should Do Periodic Reviews of Legacy Code

Editorial Note: I originally wrote this post for the SmartBear blog.  Go take a look at the original here, at their site.  If you like posts about collaboration, code review, and other topics, take a look around while you’re there.

Legacy code is sort of like your house’s storage crawlspace.  It tends to be a repository for things that mattered to you in days past or on special occasions.  The code sits there, largely unnoticed, until such time as an odd change or a production bug causes you to dig it up, dust it off, and revisit it.  Barring extraordinary circumstances, it tends to sit, largely forgotten, and possibly rotting or getting riddled with moth holes.

By and large, this considered an acceptable and even desirable state of affairs in our industry.  A lot of folks that manage software development efforts and hold the purse strings think of software construction the way they think of building construction.  Once you’ve built a house, it’s done.  Why would you go back and revisit it unless there was some kind of problem that had cropped up?  The problem with this well-intentioned, bottom-line thinking is that building software isn’t much like building houses.

When you build software, you stack the new atop the old and everything comes along for the ride.  Sure, there may be the occasional new module that stands all by itself or plugs in with the rest, but that’s the exception.  The new code interacts with the old stuff, calling into it, relying on it, and running beside it in production.  If housing construction worked this way, a short circuit in the house across the street might cause your shower to stop working.

The result is that, however well-intentioned someone encouraging you not to focus on legacy code might be, the edict is often misguided.  If the short circuit across the street meant you couldn’t shower, would you listen to someone who told you their wiring was none of your business?  Clearly, you wouldn’t go storming over there out of nowhere, remodeling that house, but you wouldn’t just ignore it either.


This is the approach required with legacy code in your code base.  The fact that someone typed it out years ago doesn’t mean that it doesn’t have a very real, current impact on your team every time you deploy your code.  Because of this, it behooves you to review it occasionally, when time permits.

Let’s examine some specifics as to why it makes sense to audit your legacy code from time to time.  Having your finger on the pulse of everything going into production is a compelling but abstract argument.  So, let’s get more concrete.

Read More


A Taxonomy of Software Consultants

The conversation that follows this paragraph is a dramatization.  But it’s a composite of actual conversations that I’ve held, distilled and focused.  And I think it will illustrate why I believe we need a taxonomy of software consultants.

“What do you do?”

“Oh, I’m a software consultant.”

“Oh, nice.  So, what, you like, go out to client sites and help them with their projects?”

“No, I work for a software consulting firm and I just go there.  My company writes apps for other companies, and I’m on a team working on something for one of those companies.”

“Ah, okay.  Do you interact with your client over the phone or via chat or something?”

“No, that’s mainly the project manager — I just code up requirements.”

“Oh, gotcha.  So no one really consults with you, per se.”

“Yeah, huh, I guess not.  I guess I’m more like a contractor or something.”

The surface problem here is that the definition of consultant has been somewhat watered down.  But I’d say the deeper-seated problem is one rooted in history.

In a world (of, say, 30 years ago) where software was mainly a maintenance concern for line of business automation and hardware-based products, the people that wrote code were employed by the companies that consumed the code they wrote.  Someone without domain knowledge that went around writing software would rightly have been considered a consultant, since specialized knowledge of software was uncommon.  But as the balance of the world shifted to software being ubiquitous, someone unmoored from a particular domain, writing code for a living, is no longer highly specialized nor is that person likely to be consulted for their unique expertise.


As the world evolved, however, the terminology did not.  A software consultant continues to be defined as “anyone who writes software for a company other than the one direct depositing pay into their bank accounts.”  This can be the ‘consultant’ described above, an agency staff augmentation, a CRM specialist installing a CRM installation, or a person advising the dev manager on a migration strategy.  To gain some clarity, I propose some clarity around terms.

Read More


How to Get People to Review Your Code

Editorial Note: I originally wrote this post for the SmartBear blog.  Go check out the original here, at their site.  If you like this content, there’s a lot more over there, by numerous authors, to check out.

On the bus ride of my career, the stops have been numerous and eclectic, much like a line that runs through an entire city.  On the subject of code review alone, I’ve seen the gamut.  I’ve worked in an environment that prided itself on mandating that every line of code, written anywhere, be reviewed by several people.  Because HIPAA or ISO or something.  I don’t recall.  I’ve also been in a situation where my instructions were “here’s a bunch of C code on a hard drive, and if anyone else ever looks at what you do with it, that will be because you’ve done something terribly wrong.  Oh, and you should probably backup the C code from time to time.”

I mention this because I’m anticipating varied reactions to the title of this post, which is very much “what you see is what you get.”  I’m going to offer you advice on how to convince people to review your code.

A lot of you reading are probably thinking, “that’s crazy — what kind of shop doesn’t do code reviews?”  Some of you are probably thinking, “I wish I had that problem because I’m sick of micromanagement.”   But, even if it seems improbable to these two groups, there’s a cross section of folks reading and thinking, “Yes!  I’d love to get some feedback for once.”

Believe me when I tell you that there are legions of folks out there, particularly less experienced developers, that would love more feedback.  They’d love to understand the tricks of the trade from grizzled veterans.  They’d love to learn to anticipate mistakes and pitfalls before getting calls outside of working errors because they’ve dumped some avoidable bug into production.  They’d love to improve their craft in ways more interactive than online training videos and books.  But, they don’t have much luck.


It might be that they’re lone developers in their small companies, and, if that’s the case, there’s not all that much to be done as long as their solo labor remains the status quo.  But, more likely, they just work in a group where the development labor is heavily siloed and/or where all of the experienced developers are extremely busy.  In this scenario, there is plenty that can be done to secure meaningful feedback.

Read More