Hiring in software is broken, the internet reminds us on an hourly basis. Here’s an article, updated a few days ago, on the subject. It quotes a tweet from a month ago:
Technical Hiring is broken. We are hiring for a developer on my team and I have a chance to make this process better. Please let me know what and how you have made it better on your teams, I would love to learn from your experiences.
I found that with precisely 3 seconds of hard-hitting, investigative googling.
Of course, I’m hardly a neutral bystander in this conversation, having weighed in with my own “hiring is broken” post. And, I take it further than most, holding the opinion that the job interview itself is a highly questionable institution. (If you’re more interested in my rationale, check out this video segment).
But today I’d like to not only lay out the problem, but spend some serious time laying out my own stab at a grassroots solution. To do that, I’ll walk through what I perceive to be the core, underlying problem with the hiring process, and talk about what we’re doing differently, and how we can scale that out to more of the software industry.
You’re an Incompetent Liar
Let’s take off the gloves and be completely honest about the undertones of a job interview.
Come on in and sit down, please, candidate. Now, as you’re obviously aware, the majority of people who come through that door are incompetent liars, looking to trick us into hiring them so that they can goldbrick indefinitely.
Luckily, we’ve developed a series of riddles, questions, homework assignments, and snap judgments that will allow you the generous opportunity to prove that you aren’t human garbage, like the rest of the people in the lobby. Can I get you a bottled water or a coffee before we get started, %&$#er?
At its core, the job interview assumes some combination of incompetence and deceit.
Don’t believe me?
Ask yourself why, then, so much interview question wisdom involves self-congratulatory rhetorical chess games. Ask if they have any questions for you because, GOTCHA, the REAL purpose is not to answer their questions, but to see if they’ve prepared! Or, maybe ask them about their basic math skills. Not because you want to know, but because you want to trip them up and see if they’ll admit error.
This is, at its core, not really a dignified process. It doesn’t treat the company and candidate as two professional adults assessing mutual fit. Instead, it casts them as patient teacher and problem child, respectively.
Wow, what a week in world politics, huh? Well, let me tell you, if you’re looking to hear absolutely nothing more on that topic, then you’re in the right place, my friend.
The only partisanship here is over the music in my videos. In previous editions of the reader question round-up videos, such as this one, I I featured background music throughout the video. This week, I left that out, except in the intro and closing.
Early on when I was making videos, a few people suggested incorporating music. More recently, people have suggested, well, unincorporating it.
Now, I honestly don’t care one way or the other. I suppose it’s slightly less work to omit the music, but that really, honestly doesn’t matter much. So I’m turning it over to mob rule and asking you all to weigh in.
If you have any opinion whatsoever on the music in the videos, please head over to this one and leave a comment on it voting yay or nay.
Do you have a question you’d like to see me answer? Head to the “ask me” page and fire away!
Apologies for my absence last week from the tech pundit-o-sphere. I was, well, what I mostly am these days: busy. But today, I’m back with a premise that sounds suspiciously motivational-speakery.
Don’t worry, though, realpolitik fans. It’s not that. Not exactly.
Sure, don’t let anyone tell you that you aren’t a ‘real’ programmer because (1) that’s a crappy thing to say and (2) because you’re awesome and all of that. But I’ll leave those lines of argument to others. Instead, I’m going to talk about why letting this nonsense into your head is bad for your career and your positioning.
The No True Scotsman Fallacy
First, though, let’s wander down to the anthropology dime store and categorize what we’re dealing with here. When someone tells you, for whatever reason, that you’re not a ‘real’ programmer, they’re most likely indulging in something called the “no true Scotsman” fallacy.
The gist of this is to create a subjective, moving-goal-posts purity test for membership in some club. And people generally do this as a direct follow-up to painting with too broad a brush and having someone subsequently call them on it. For instance, here’s the eponymous example, quoted from the Wiki article:
Person A: “No Scotsman puts sugar on his porridge.” Person B: “But my uncle Angus is a Scotsman and he puts sugar on his porridge.” Person A: “But no true Scotsman puts sugar on his porridge.”
In my personal experience with purveyors of this fallacy, I generally see two principle motivations, often intermixed:
Zealous, subjective belief in the purity test itself.
Having made a strident claim before really thinking it through, accompanied by a personal tendency never to back down afterward. (Sound familiar?)
Now, take a dash of this part of human nature, mix it into a heaping bowl of the internet, bake it in the oven for 20 years, and get ready to enjoy a bottomless casserole of “why you’re never good enough.”
The Many Flavors of ‘Not-Real’ Programmers
By now, you might find yourself nodding along, imagining programming-oriented statements like this. Maybe people have painted you with a brush like this, or maybe you’ve just seen them do it to others.
No real programmer works heavily with CSS and markup.
Real programmers use the command line — not user interfaces.
In 2019 you’re not a real programmer if you’re using anything but git.
No real programmers just use their IDE out of the box, without customizing it. (Also, bonus for, “real programmers use VIM and not IDEs.”)
I imagine these statements sound quite familiar. There sure are a lot of armchair arbiters of ‘real’ programming, aren’t there?
So, having defined what this is and given examples of how to recognize it, I’d like to spend the rest of the post talking about why this type of seemingly-minor bloviating is actually insidiously pernicious for those exposed to it.
Well, going back like an archaeologist through old reader questions, I see that these two posts prompted a bunch of questions. So, in today’s video, I tackled four such inquiries. Always interesting fodder for me, personally, so thanks for asking.
By the way, if you have questions, please ask them. I’m letting this drive a lot of content for the blog these days. And, I’ve also settled on a more canonical way of asking people to submit them: a simple “ask” page.
So if you’d like to hear my take on something, head on over and submit a question.
This Week’s Picks
I spent some time visiting family over the weekend, and stayed in a hotel in my childhood hometown. Specifically, it was a Courtyard Marriott, and it was a stand-out in terms of the service, even among the countless Marriotts I’ve occupied over the last 6 years. If you’re ever in the vicinity-ish of O’Hare and run across this place in your search, it’s a gem.
Last Thursday, I did something that I now wish I’d done years ago. I un-synced all email from my phone. I can still get the emails on the device if I want them, but I have to actively pull them from the server, instead of having this pushed at me. I can’t tell you how great this is, both for avoiding distractions and for minimizing my hour-to-hour cognitive burden.
This Week’s Content Digest
Here’s one last live blog that I did on the Sonatype site, this one about table stakes for DevOps.