Culture fit means shared experience

Most things that we believe were “invented” by universities were actually discovered by tinkering and later legitimized by some type of formalization — N. Taleb, Incerto

You know, I never care to know random things. Like that life saver when you write your PHP scripts:

How is a PHP array implemented internally?

Who are we kidding here? How often do you wonder such a thing? Why would you learn by heart all these interview scripts?

Because people ask you before ever getting to know you.

These are the same companies that 10 years ago hired people who had the skill of “view source” and could hack a table exported by Macromedia Fireworks. This is so embarrassing.

I mean … who are you kidding?

There are maybe a handful of companies with products so complex AND written with PHP at their core that could really meet the question above in their day to day development operations. And they pay a premium in the salary market to have the clout required for such filter questions.

But I hear so many stories of people going to interview with all kinds of random mediocre businesses that crank out PHP pages, doing the same form and list detail views or at best handling some async JS calls on what they call an API, and being asked the most esoteric things.

And what bothers me is that they do it because it’s cool.

They don’t care about how a PHP array is implemented internally. This is 2016. Get real. Do they hire someone to churn out highly optimised code for billions of users because they have a billion user website somehow written with PHP? No, they do WordPress templates or forms for some soul sucking backends.

Why, I wonder, don’t people really talk at interviews, instead of firing up their trick question panel?

In my opinion there are a minimum of two steps involved in recruitment of developers or programmers: lure and fit.

The lure part is where you create a hiring brand. Yes, in this market you need a hiring brad. You need people to feel warm and fuzzy when they think of working with you at your place. After you get them warm and fuzzy with your exquisite presentation all over, the HR people step in.

HR should not interview anyone. Their role is to be screening, building interest and then welcoming. That’s about it.

Then comes the fit part. None of the steps are easier. It is a great challenge in some high density industries to get people to show up. And then there comes the next equally challenging attempt to gauge if you fit.

And this is where I want to bring your attention at, with this huge introduction:

Fit is determined based on shared experience

And to grasp that you need understanding of two things: the content of the experience and the personal interpretation of the experience.

Remember, we only understand what we experience and we only grasp what we’re taught. In this case it means, we need to let the person at the interview talk about what they did, what they used while doing, why they left companies, why are they developers and not sales people, how’s their life sorted in general and so on and so forth.

Sure, there is a way to poll for exact knowledge. Pepper the discussion with questions about specific things, but always try to ask about something which was or should have been in the scope of the experiences the person had.

Asking about things that the candidate never used is useless.

Who cares if you know? I know so many things and they’re completely useless, unless the proper context is set up in my mind to connect memories into meaning. And meaning comes from the ongoing experience.

Stack overflow is a form of social art, in that it expresses the core of computer software development: shared responsibility.

Developers don’t have singled out human lives in their hands like medical professionals. Developers don’t have large swaths of human lives in their hands like construction engineers. Developers don’t have huge budgets to destroy like many scientists. Developers don’t have hundreds of young people directly affected by their performance like teachers.

Developers are a highly privileged class of workers and we rely on each other because computer software development is a completely shared responsibility human activity.

Computer software development. There are areas, such as the NASA team of developers, where the responsibility is less shared, but at the same time the rate of change is abysmal compared to what a developer working for a commercial entity churning out e-commerce or AppStore one hit wonders has to tackle.

That’s what you hire: constant change juggles.

And for facing the constant change environment of developers making the whims of business into actually working things culture fit ensures the clicks and clacks that make the innate complete shared responsibility work.

Whenever teams of developers fail, in development terms, it is because the shared responsibility was not complete. Whenever a hire fails it is because we don’t get each other.

And asking a barrage of questions about all kinds of things, from design patterns to exotic library functions argument order will never allow you to get the person in front of you.

Mostly, the interview will tell you nothing about future performance.

The interview can only asses the probability of successfully share the responsibility which the projects will lay on developers. That’s it.

Other than that: people learn. You get books on how to answer correctly to interview questions. You get articles detailing how to hunt down best salary offers and how to order interviews to help yourself prepare for the ones you really want. People learn, but, like a famous fake doctors said: people never change.

And thats what that time spent interviewing should do: infer from their story who they will become by grasping who they are.

And, also, this is another reason why not every single developer, even if highly skilled, is ok to interview other developers, even if team leader, even if very senior, even if founder.

Interviewing without a question barrage involves a certain amount of specific experience, a kind of social experience. Someone who owns a personal open source project where hundreds ask for pull requests and bash his or her freely volunteered time will begin to grasp humans and be a possible good interviewer, but one who codes blind extraordinary features might be less inclined to have the patience required to find out about the interviewed.

This manner of understanding how to accrue colleagues would also help the tech’s diversity issue.

A hash. Point taken, now what?