Are you having problems finding the right people? Or are the right people too expensive? How about culture fit? Well, I have some news.

You don't have a skills problem. At all. You have a management problem, a leadership problem, a culture problem. I've been on both ends of it and I think its way past time to write about it.

I'll get to why in a bit and this will be a 2 3 4 part series. This topic has come up a lot recently and someone at a group I talk with suggested I write out my thoughts on it. So here we go.

Hiring practices in general

are so very broken in most places

First let me talk about hiring practices. Most are so out of touch, it's cringeworthy. A hilarious write-up from Adrianne Jeffries a while back outlined the painfully out of date "whiteboard interview". I can speak from first hand that I've been subjected to the almighty whitewall compiler ...and found the fastest way to leave the interview I could. I'm not joking, I thanked them for their time and ended the interview. There are others that are equally horrible, and worse, but companies continue to use them and cry "how do we get good candidates?!”. Usually it goes something like this...

• We're behind so we should hire more people
• Those candidates wanted too much money
• Let’s keep looking
• Let’s just hire 3 and see how they work out.
• Hire consultants.

...and I have a few thoughts why this terrible processes exist and yet it's still used. Every day. The hiring practices used in a lot of organizations are carried over from ~30 years ago and we just added a whiteboard. As someone who still writes code, my day job has never involved writing code on a whiteboard with "problems" I can look up in 5 minutes. Let's get to more interesting problems, like that one that I can’t find on the internet.

My personal favorite is when a company (or recruiter) asks for X years of experience when a technology has only really been around for X-2. Worse, those whiteboard / memorization / gotcha interviews show zero skill in finding a solution to a problem, much less how day to day dev works. So of course there's a "skills gap" -- skills are not the thing being sought during the interview process. It's "can we stump you and feel smart about ourselves". That's your culture. If this is your company practice, please, cancel your interviews and start over.

Something that Jeffries article doesn't touch on are the ever-dreaded statistics which I'll bring up a number of times. Before you close this window and dismiss this, hear me out. A while back, I watched a SXSW panel stated 11% of businesses strongly agree that graduates were ready for working in dev. Eleven. Percent. I really do believe that is misguided and I'd like to know WHY they think they're unprepared but I'll ignore that for the sake of argument. What bothered me the most was they begin to touch on the real problem so briefly it seems like an afterthought, a footnote: Most companies hire for a checklist. These checklists are simply technologies or tools and not skills and capabilities. We'll talk more about that later, but the checklist thing is completely crippling for all the wrong reasons. Think about this for a minute. If I know how to weld steel but a job calls for ...titanium welding, is the skill in the steel or in the welding? It's welding, not the material. So when a client asks me "we need more developers" I ask what is the skill they're looking for and that isn't happening.

What about a "take home" test? I did 3 of these a while back with various computer science related answers (which, again, useless for interviews) and I started asking why? Why is this the first step? This is barely a step up from the whiteboard compiler. All 3 told me I had "missed a requirement", "wasn't what they were looking for" and my personal favorite, no response at all. How is that reflective of someone you want in your organization? It isn't, and if it is, I suspect it’s a symptom.

Speaking of "skills"... and how they don't matter

Take a look at the stackoverflow survey and the wild shifts away from some technologies that were so important last year have dropped quite a bit this year alone. Does that mean anything learned from those "dying" technologies mean it was wasted? Absolutely not. It's just. another. tool. And yet, I talked to someone yesterday that said because they don't "know" React, they were told they weren't qualified. .............What? He's got 5 years experience in javascript-y languages and based on that alone, I'm sure he'd be able to pick it up, no problem. Since it was a checkbox that he couldn't check, he got passed over. (I told him this was ok, because I'm sure it was a crappy company anyway)

I really think this is a carry over of Taylorism. If you've never heard of it, it's certainly worth looking at it and understanding its wonderful purpose. Taylorism was revolutionary at the time -- turning the need for skilled workers, automating and simplifying their jobs to the point that anyone off the street could do a job and produce a lot more than ever before. "Read this card, push this button". Well, those days are dead and over - but we're still feeling the fallout and trying to repurpose it, even in the agile world.

I've talked with a lot of businesses and they're convinced it's impossible to find good developers -- they're right. Me, I prefer to call them team members, because the real spoiler is : it really doesn't matter if it's a tester, "business analysis", developer etc. It really doesn't. Ask a startup who their "developer" is, then ask if they have a development background. Out of the 8 teams I see right now ... 2 have actual "real developers". That's all. This doesn't surprise me -- according to the Stackoverflow 2019 survey, 86.8% of all professional devs have taught themselves! I'm one of them. I came from electrical and network and began by automating my job -- so what? As a community, no one cares if you are self taught or writing a thesis. It doesn't. matter. Businesses try so hard and insist otherwise and that's exactly why they can't find "talent".

We all suck at predicting good candidates. I think it’s worse in the tech world.

Take a look at your last 5, 10, 25 hires. How many have been great? No, really, truly great? How many have been terrible? After someone is hired all too often it goes into the abyss, the unknown hole of data where things go and are left forgotten. I beg the question, is it possible that it’s purely random and luck? It it purely randomness? Hopefully, probably, not but there’s a lot of data that say otherwise as of now. The promise of AI and such hasn’t reached a point where it’s reliable and I seriously doubt it will anytime soon. Surveys are largely flawed and unreliable too. It’s not for a lack of trying - companies spend a boatload of time finding candidates. So what’s a hiring person to do?

Some ideas on how to fix it

The real key for a damn good team member is how they find answers and solve a problem that you can't find on the internet. The only way you do that is to present one to them during the interview process and focus on how they work, NOT if they get the same answer you came up with the last 10 times you did the interview. Yep, shots fired. The practices I see, right now, does one thing very well and that's telling teams and potentials "if I haven't learned it, I can't learn it here". These are people that can easily be taught, easily learn and be very effective and truly contribute. Stop me if you've heard this : "We want to hire the smartest people" blah blah blah. Existing staff simply cannot be taught? Really? When’s the last time you’ve hired from within? Can your people not grow, move into another position completely? I call bullshit. The skill companies should be looking for is problem solving, plain and simple.

So how does this get fixed? What steps need to be taken to fill that "gap"? First, I give top priority to the ability to learn. If 10 years writing code has taught me anything, it's that ability to learn, and unlearn is more important than anything. The catch is companies want this new shiny technology that just came out, but would rather hire to fill it, instead of asking "anyone want to do this? What will we use it for? Is this just an excuse to rewrite something?". It's impractical to keep up with every single new thing that comes out, so hire for the skill of learning and let those "smart people" learn.

So let's recap, and since people LOVE lists... no checkboxes though!

DON'Ts

Hire for a certain "checkbox" skill or experience levels.
Ask parrot questions
Do interviews without the tools of the job.
Expect someone to come up with the same answer, or worse, assume it's wrong since it didn't match.

DOs

What language do you like?
What's a cool thing you made? Is any of your code public? Can I see? Walk me through it!
Where do you think you could've designed something better after you wrote it?
What do you want/like to work on?
What kind of problem/technology really interests you?
Have the person actually write code, with someone on the team, maybe even something you're having a problem with (!)

I'll be starting a github repo with questions and reasons why to ask those questions.

Developers talk, and they know what companies suck

Here's the final thing I want to bring up. If I see a business, company, whatever having problems finding people I’ll ask some developers what they think of them. Guess what? Developers talk, a LOT. So imagine those same "smart people" knowing the real culture inside of an organization, who’s running what, and how problems are really handled. They know what company is doing and how the teams are treated. They also know if they're a cog in the wheel or a real contributing member. Most of the "smart" people hate being cogs. They like building the whole machine with cogs off the shelf and cogs they have to make.

In Part 2, I'll lay out some thoughts on making a job posting for any position and things I used to get the right candidates.