Hiring process is inherently wrong

Reg­u­lar­ly, man­agers ask me ques­tions about the hir­ing process. All of them com­plain about three things:

• They have a lot of bad can­di­dates—can­di­dates who clear­ly don't qual­i­fy for the job.
• They have few good can­di­dates.
• They of­ten hire per­sons who end up be­ing av­er­age or be­low av­er­age.

Many of those man­agers com­plain that they've read all my ar­ti­cles on the sub­ject, but while it did im­prove their un­der­stand­ing of the hir­ing process and the out­come, the change wasn't that rad­i­cal. This up­sets me a lot. Years ago, I thought that slight changes to the fo­cus dur­ing the in­ter­view, mi­nor mod­i­fi­ca­tions of the process, would lead to dras­tic im­prove­ments in terms of the qual­i­ty of the hires. The prac­tice shows that I couldn't be more wrong.

Back in 2014, I write the ar­ti­cle about the tags shown on Stack Over­flow Jobs. My point was that the rel­e­vance of those tags to a pro­file of a giv­en per­son is ex­treme­ly low. In Feb­ru­ary 2021, my pro­file shows that I'm top 1 for html and php. If a re­cruiter con­tacts me for a job of an HTML coder with a bit of PHP, this would be a rare case where I won't even take an ef­fort to an­swer.

The same year, I start writ­ing a se­ries of four ar­ti­cles (1, 2, 3, and 4) about the hir­ing process. In the se­ries, I ex­plain how to for­mal­ize the need, how to stop writ­ing fluff in the job post­ings, what's the ac­tu­al goal of a job post­ing and how to write one, when to take ini­tia­tives, who should be in­ter­act­ing with the can­di­dates, how to per­form an in­ter­view, how long should be an in­ter­view, and how to be­have af­ter the in­ter­view.

Still in 2014, I also write a sec­tion about the dumb­est hir­ing prac­tice of self-eval­u­a­tion, that is, when the can­di­dates are asked to rate them­selves on a scale of zero to five for a giv­en skill. From the feed­back I re­ceived in re­la­tion to this ar­ti­cle, I con­tributed to make a few dozen com­pa­nies a bit less dumb about the ques­tions they ask. That's a good thing.

Fi­nal­ly, the year ends with an­oth­er ar­ti­cle about the low qual­i­ty of the web­sites which list the in­ter­view ques­tions.

In 2017, I wrote about the key er­ror of the hir­ing process: the fo­cus on tech­nolo­gies, as well as about the fo­cus on some­thing which looks like met­rics, but is just ir­rel­e­vant fluff.

The next year, things start­ed to get dif­fer­ent. A dis­cus­sion with a man­ag­er showed that my vi­sion of the hir­ing process was ex­treme­ly op­ti­mistic and un­re­al­is­tic. Most com­pa­nies are not look­ing for skill­ful peo­ple, be­cause the ac­tu­al skills are not the qual­i­ties which are val­ued in a cor­po­rate world. What mat­ters more is a per­son who's good at pol­i­tics, who is able to work de­spite crap­py work­ing con­di­tions, and who gives an im­pres­sion of mak­ing progress.

This ar­ti­cle was fol­lowed in 2019 by an­oth­er, ex­plain­ing the rea­sons why a com­pa­ny can't test can­di­dates based on the things that ac­tu­al­ly mat­ter: self-de­cep­tion and mis­in­for­ma­tion.

While those ar­ti­cles show that the hir­ing process cur­rent­ly used by most com­pa­nies is prim­i­tive, the lat­est ones—as well as the ac­tu­al ex­pe­ri­ence of the man­agers that I was men­tion­ing above—also give a hint that im­prov­ing the process is not that easy. In ret­ro­spec­tive, I would be in­clined to be­lieve that the process is un­re­cov­er­able: that it is ei­ther so flawed, that no sin­gle change could make it work, or that my ap­proach of the prob­lem it­self is com­plete­ly wrong.

What's the goal of the hir­ing process, any­way?

There is not one, but two goals. The first one is to at­tract the ones that are qual­i­fied. The sec­ond one is to fil­ter out the per­sons who are not qual­i­fied.

Find­ing qual­i­fied per­sons

There are com­pa­nies which are great. Well-known. Pop­u­lar. Rep­utable. Many per­sons want to work for them.

And then there are oth­ers. Those ones are maybe not pop­u­lar. Or maybe they are just not that great. Still, they have to com­pete with oth­ers in or­der to be able to find peo­ple who will go work for them rather than for their com­peti­tors.

This is not very dif­fer­ent from sell­ing prod­ucts or ser­vices to cus­tomers. Here, the cus­tomer is the can­di­date, and the ser­vice is the month­ly wages and the op­por­tu­ni­ty to work for a giv­en com­pa­ny, with the ac­tu­al work and per­son's time as a coun­ter­part (while it's usu­al­ly about mon­ey and per­son's time when it comes to prod­ucts and ser­vices sold to a cus­tomer).

The prac­tices are there­fore quite sim­i­lar too. It may in­clude ad­ver­tise­ment, di­rect so­lic­i­ta­tion, or just a guy telling to an­oth­er guy that his work­place is not so bad, and the oth­er guy should con­sid­er a po­si­tion in his com­pa­ny. That's not par­tic­u­lar­ly in­ter­est­ing; let's talk in­stead about the sec­ond goal of a hir­ing process.

Fil­ter­ing out non-qual­i­fied per­sons

If there were no hir­ing process­es, what could be the al­ter­na­tives? Let's imag­ine a com­pa­ny where any­one could get in and de­cide that he will work here. You don't have to ask per­mis­sion: you just come, and tell: “hey, I'm an em­ploy­ee now.”

It looks fan­cy, but there is a prac­ti­cal ex­am­ple of such a sys­tem ac­tu­al­ly work­ing: open source pro­jects. If I want to con­tribute to the source code of Lin­ux, or go and fix an is­sue in Vi­su­al Stu­dio Code, I don't have to call a hu­man re­sources de­part­ment and fol­low a sev­er­al hours in­ter­view to check that I have the nec­es­sary skills and mind­set to work on those pro­jects.

And it works.

Open source pro­jects, how­ev­er, are dif­fer­ent. If I'm an em­ploy­ee of a giv­en com­pa­ny, I want this com­pa­ny to pay me on reg­u­lar ba­sis. More­over, if I want to work on a new sys­tem used by to help land­ing F-16 on an air­craft car­ri­er, I pos­si­bly need a few clear­ances to ac­cess the in­for­ma­tion that oth­er per­sons shouldn't be able to ac­cess. In oth­er words, the hir­ing process is a gate to a month­ly salary and a se­ries of clear­ances. Or, in oth­er words, it's a safe­ty mech­a­nism which pro­tects the com­pa­ny from hav­ing to share se­crets and mon­ey with any­one who wants to gain ac­cess to their se­crets and mon­ey.

In­ter­est­ing.

How eval­u­at­ing my C++ skills or ask­ing how good am I at com­mu­ni­cat­ing with oth­er peo­ple helps this pur­pose? Why wouldn't a bank ask me ques­tions about Python string for­mat­ting or the ba­sics of HTTPS en­cryp­tion be­fore lend­ing me some mon­ey?

You can't know what you are look­ing for

One of the things which is both­er­ing me since 2014 is the num­ber of com­pa­nies who live in a self-in­flict­ed fal­la­cy that they know they need in terms of peo­ple. I'm not even talk­ing about those dumb post­ings look­ing for a PHP pro­gram­mer—I'm talk­ing more about com­pa­nies which are a bit less prim­i­tive, but still look for a soft­ware de­vel­op­er, or a pro­ject man­ag­er, or a data sci­en­tist. They are miss­ing the point.

When peo­ple ask me what's my job, I don't know what to tell. I re­al­ly don't know. There is no of­fi­cial name for it. My ex­per­tise is qual­i­ty and pro­duc­tiv­i­ty—that is, what a giv­en team needs to do in or­der to achieve bet­ter qual­i­ty, while be­ing more pro­duc­tive. But I also do pro­gram­ming and soft­ware de­vel­op­ment, in­ter­ac­tion de­sign, data pre­sen­ta­tion, sys­tem ad­min­is­tra­tion, process au­toma­tion, se­cu­ri­ty, train­ing, and dozen oth­er things. Heck, my pho­tog­ra­phy skills and the things I've learnt when study­ing psy­chol­o­gy are cru­cial in many of the pro­jects I do, and they can bring a very con­crete val­ue to a com­pa­ny hir­ing me. But the last time I was in­ter­viewed about my pho­tog­ra­phy skills dur­ing an in­ter­view was in my oth­er life.

One com­pa­ny ben­e­fit­ed from the fact that I'm flu­ent in Russ­ian to un­der­stand how their sys­tem should be in­ter­na­tion­al­ized. Did they look for this par­tic­u­lar skill when hir­ing me? Nope, they didn't. They didn't even know they need it, be­fore I stepped in and ex­plained that the way they do in­ter­na­tion­al­iza­tion is all wrong.

In an­oth­er com­pa­ny, I had to de­vel­op a piece of soft­ware from scratch. It's a piece of Python soft­ware, if you ask, but this is not im­por­tant. While my Python skills were valu­able, much more valu­able was my pro­fes­sion­al ex­pe­ri­ence in in­ter­ac­tion de­sign (the com­pa­ny has a lega­cy of mak­ing soft­ware which is par­tic­u­lar­ly un­us­able, and the thing I made may con­vince them that it may be about time to start in­vest­ing more in the de­sign if they want all oth­er soft­ware to look as the one I cre­at­ed), my skills in re­quire­ments elu­ci­da­tion, my or­ga­ni­za­tion­al skills. Fun­ny thing, dur­ing the in­ter­view, I had to an­swer ques­tions about... C# and SQL.

Every job had a name. Some­times I was a pro­ject man­ag­er, while I brought the most val­ue in unit test­ing, soft­ware qual­i­ty, and pro­gram­ming. Some­times I was called an an­a­lyst in an R&D de­part­ment: no­body did any de­vel­op­ment here, nor re­search, and there was no analy­sis in­volved ei­ther. Some­times I was an ar­chi­tect, but the ac­tu­al job didn't in­volve ar­chi­tec­ture; my val­ue there was in terms of soft­ware de­sign, com­mu­ni­ca­tion, train­ing, in­ter­ac­tion de­sign, se­cu­ri­ty, ap­pli­ca­tion de­sign, and a few oth­er things.

Now, what val­ue has a sys­tem of la­bel­ing, where la­bels are com­plete­ly use­less? Why would any­one cre­ate an ar­ti­fi­cial cat­e­go­riza­tion sys­tem which serves no pur­pose, and which is, by its na­ture, mean­ing­less at best, and of­ten even mis­lead­ing?

One may say that I may have an ex­cep­tion­al pro­file, ten years ex­pe­ri­ence, bla-bla. I'm not. Every­one work­ing in IT is in ex­act same sit­u­a­tion. That's a char­ac­ter­is­tic of a hu­man be­ing: no one is in­ter­est­ed by one and one only thing. No one is born to be a pro­ject man­ag­er, or a Ruby pro­gram­mer. You can't look for peo­ple like you look for a new fridge.

The core prob­lem is that it's the sys­tem it­self which cat­e­go­rizes IT per­sons. He's a web de­vel­op­er. She's a se­cu­ri­ty ex­pert. Out from col­lege, you're look­ing at the job of­fer­ings, and all you see are cat­e­gories. Here's a bunch of com­pa­nies look­ing for a Python pro­gram­mer. And there, they look for Node.js guys. And here's a post­ing for a vi­su­al de­sign­er.

CVs fol­low the same cat­e­go­riza­tion. If you've been a PHP pro­gram­mer for the last decade, there is a strong chance that you'll have to an­swer to the post­ings look­ing for PHP pro­gram­mers. Switch­ing from one cat­e­go­ry to an­oth­er is pos­si­ble, but dif­fi­cult.

More im­por­tant­ly, cat­e­gories are for stuff no­body should care about. I don't care that a guy worked on Java pro­jects for the past ten years if I'm us­ing ex­clu­sive­ly Ruby in my com­pa­ny. If the per­son is able to learn, and if he's will­ing to learn, the lack of any pri­or ex­per­tise in Ruby would be my least con­cern. On the oth­er hand, there are out­stand­ing qual­i­ties that don't have any cat­e­go­ry. Be­ing a good guy is one of them. You know, a per­son who is a so­cial cat­a­lyst of a team—when he's here, every­body is hap­py and things get done. As pro­duc­tiv­i­ty con­sul­tant, I can en­sure you that peo­ple like that are in­valu­able: they are some­times one of the most valu­able as­set you can have in your team. But I've nev­er seen any job post­ing telling that a com­pa­ny is look­ing for a good guy.

Try to re­mem­ber peo­ple you were work­ing with five years ago. Do you re­mem­ber what tech­nolo­gies they were putting on their CVs? Or maybe in­stead, you re­mem­ber that this guy was the one who could make progress no mat­ter what—and who dealt with the most prob­lem­at­ic is­sues in the com­pa­ny, sav­ing a huge amount of mon­ey, or this gal who thrived for ex­cel­lence in every­thing she was do­ing, or this one, who had an amaz­ing cre­ativ­i­ty, imag­in­ing so­lu­tions no one else was think­ing of?

When you de­cide to read a book, do you de­cide to have an in­ter­view with the au­thor of the book, to know if it match­es your ex­pec­ta­tions in terms of what you'll learn from the book? Do you know what you need to learn in the first place? When you meet some­one, do you do a hir­ing in­ter­view to de­cide if the per­son can be your friend, and if it match­es your ex­pec­ta­tions in terms of what the per­son will bring to your vi­sion of friend­ship and your cur­rent needs?

Pos­si­ble al­ter­na­tives

I ex­plained why the hir­ing process is in­her­ent­ly wrong, be­yond re­pair, but haven't sug­gest­ed any­thing else. In­deed, I don't have a mag­i­cal so­lu­tion now, al­though I'm think­ing about the al­ter­na­tives.

For jobs in­volv­ing a lot of pro­gram­ming, I would imag­ine that a com­pa­ny could go open source, and de­cide to hire (that is, start pay­ing) per­sons who con­tribute a lot. I wouldn't be sur­prised if I learn that Mi­crosoft ends up by hir­ing those de­vel­op­ers who have made sol­id con­tri­bu­tions to .NET Core or oth­er Mi­crosoft's open source prod­ucts. The prob­lem with this ap­proach is that while a per­son can be a great con­trib­u­tor to an open source pro­ject, it doesn't tell any­thing about his qual­i­ties if he needs to work in the of­fice.

Or maybe some­where in the fu­ture, a com­pa­ny would sim­ply take a per­son in when­ev­er he wants to be part of the com­pa­ny, and post­pone the de­ci­sion of keep­ing him or not for a few weeks. Dur­ing those weeks, the progress of the per­son would grant him clear­ances that a new­com­er don't have, as well as a bet­ter fi­nan­cial re­ward—if the per­son has to leave on his first day of work, he doesn't get any mon­ey; if he leaves a week lat­er, he gets a small re­ward; if he leaves af­ter a month, he gets a much larg­er re­ward; if he stays for longer than that, he could ex­pect a usu­al salary.

Nat­u­ral­ly, such sys­tem would be sub­ject­ed to some con­trol: first, the com­pa­ny needs to have enough mon­ey to pay the new­com­ers, lim­it­ing the num­ber of per­sons who can join at a giv­en mo­ment. Sec­ond, while the new­com­er can de­fine by him­self what val­ue can he bring to the com­pa­ny, it's up to his pairs—the per­sons who are al­ready part of the com­pa­ny—to eval­u­ate his ac­tu­al im­pact. How to make such sys­tem and pre­vent fraud while fos­ter­ing in­no­va­tion is a com­plex sub­ject.

I'm not at all sure how such or­ga­ni­za­tion can be im­ple­ment­ed, nor would it work or not. Any­way, this can serve as in­spi­ra­tion for peo­ple who own com­pa­nies, if they want to try some­thing new in­stead of the bro­ken hir­ing process we have now. And if you do try some­thing new, let me know where it got you.

For the oth­ers, con­sid­er that you're work­ing with a ter­ri­bly flawed process, and try to min­i­mize its im­pact. Yes, the hir­ing process will lead to bad re­sults, be­cause it is it­self bad. By ap­ply­ing a few prac­tices I've de­scribed in my pre­vi­ous ar­ti­cles on the sub­ject, you can make it less bad than it is in most com­pa­nies, which is by it­self a rather pos­i­tive thing. One day, hir­ing as we know it to­day will be over, and that would be great.