I have been working for quite a while now, and as a software fellow my sector is perhaps one of the most innovative of our times.
There is some debate in the community about the hiring process front-line software companies adopt, and it happened to me to daydream an interesting analogy that I would like to share.
PID stands for "Proportional Integrative Derivative". It is a technical concept but it doesn't take much to understand the sense of it, so I am going to try and explain it in street-man language.
So, there is something you want and there is what you actually have. Let's call Set Point (SP) what you want, and Process Value (PV) what you have. With these concepts defined, we go further and define as Error (E) the difference between them. So, in mathematical terms, E = SP - PV.
Those who know control theory are probably already wandering around but let's try to stay generic and not necessarily see numbers and formulas. Now, in a business environment SP could be the company objectives and PV the current situation, so E is how far is the business from their objectives.
Now, a software company, at least until AI will be able to develop, need developers and software engineers to reach their objectives, so they usually hire, right? Hiring, then, is an action companies do to try to reduce E, the displacement between their current situation and their objectives.
Doing so, they sort of apply a closed loop controller to the process. Which is a technical jargon to say that they do something to try to reach their objectives.
Well, one of the (and the must popular) used control strategies ("what people do we hire to participate with their work in reaching the objectives?") is called PID. A PID controller acts by summing three sub actions:
Proportional (P): this action looks at E and kinda says "oh, the error is quite big, we need to hire people that can start right now writing a Lexicographic breadth-first search convoluted Dijkstra routine stateless implementation with CD/CI into Galaxy cloud in C++11 asynchronously marshaling R package JumpIntoTheVoid transpiled into javascript...".
Integrative (I): mr. I has a different reasoning and says "well there is an error and we need to hire people that understand our objectives, look at ways to reach them and build solutions for our best future; it's acceptable if they need a couple of days to review what a Dijkstra algorithm does or a week to learn the cloud API we use"
Derivative (D): this guy doesn't even bother looking at the error value, he's only interested in error changes, he says "The error is increasing, we need to give a push to P and I and hire someone that by tomorrow fixes problem 32 in application 54"
Well it turns out that neither P and D are able, alone, to reach E = 0. P needs to see an error to act, and its action is as powerful as the error itself, so when the error gets close to zero, P simply sits down and waits to see more error. D is a "spur of the moment" fellow, it will give some burst when things are deteriorating but it also does the opposite when things are improving, because he's simply happy with the status-quo, he's opposing to changes.
The only one that can reset the error is actually I. He is more reflective, has a more horizontal than vertical experience, he's the one that will take 1 month to make a great solution instead that 1 day to find one of the 100 different ways available to solve a small part of the greater picture perhaps not moving an inch toward the company objectives.
In control theory, depending on the particular situation, all three actions are useful, but to reset the error in a system with inertia, the only way is to include the integrative (I) action. Also, in the long term, the I term is the only that keeps the action active, P and D turn OFF when the error is zero.
So what has all of this to do with the hiring process of the software companies? Well, I have been involved in it, on both the candidate and the hiring side, and as a candidate I have found a pretty P-only approach.
I see very few jobs advertised that have the characteristic to attract I people. Finally I came to a classification for candidate researches that I call the-three-G (or 3G or GGG): Good, God, Gossip.
Good are those that actually make sense. They clarify what the job is, specify a context and identify what technologies are currently used by the company. The interview is more focused on the overall experience than on the thing you did yesterday. The hiring team tries to understand if you are really willing to work for the good of the business and not only if you know how to fizzbuzz in kotlin.
God are those which expect from the candidate a skill set that would make the Albert Einstein of software turn pale. Why the hell would everyone with that amount of skills and knowledge (if she exists) want to work for any company, ever? They would simply have their own company and put everyone else out of market in a few months.
Gossip is the kind of jobs where, clearly, those advertising have almost no idea of what they are doing, like for example asking 5 years of experience in a technology that has only been announced the previous week.
I might be wrong on the numbers, but think that many (possibly most) of software companies with 50 or more developers are organised as in :
10% of really productive (I) people
60% of really nerdy (P and D) people
30% of people that work to make sense of what the nerds do and reduce it to something that could be done by 10% additional productive people
But this is not the problem really, we all learn by experience. What I find strange (and frankly a little daunting) is that those companies seem to have recruiting processes very tailored to select "P&D" and failing to identify "I" people.