The setup (part one)

Years ago I read about a linguist, one of the few people that could read ancient Chinese, who was able to speak casually 300 languages. There were many details like the above that were fascinating. But being a person that likes learning the way he learned a new language was something that back then I found remarkable: He would pick up a grammar book, read it front to back, and then start practicing. I can only speculate based on what I know but: a) Languages are divided in families, like Indo-European, Niger-Congo or Dravidian, and once you learn one from a specific family, switching to another one from the same family becomes easier (I expect rather than families is about the subdivisions); b) details change (OSV vs SVO, for example), but some fundamentals stay.

The setup (part two)

A good friend is having some issues finding a job. Some of the cases in which he was rejected was because he didn’t know the tech being used. The kicker: he was applying for a position as Software Development Manager. For reasons that I explain about below, asking for a specific tech, is not a great way of hiring. Furthermore, for the position that he is applying for, makes even less sense.

I am flabbergasted.

The setup (part three)

Simon Sinek is a speaker that talks about things that so far I seem to agree with. But in this blog I am going to point to a specific quote of him: You don’t hire for skills, you hire for attitude. You can always teach skills.

I do truly believe in that idea. But, sadly, doesn’t seem to be something that is followed up by most companies.

I have to mention that there are certain skills you would expect to be acquired based on seniority, otherwise they will not have shown the right attitude before (though how much that attitude is shaped by the environment?)

Tech

I mentioned in my previous post a belief of mine. Well, it was a belief some years back, now I have some personal experience to back it up with: Knowing a specific language is not important. Like the linguistic above, a experience developer can easily read a book or two about a language and start coding at a level high enough.

But we need people with high expertise because ... No, no you don’t. Maybe back in the day when there was no Internet, no mailing lists, forums, Slack, Discord or Stack Overflow, basically, when there was no access to information, having one person on the team with deep knowledge was required. But that is no longer the case. I have an issue, I communicate, the shared knowledge is bigger than of any particular individual. By the way, that is a massive advantage you get when hiring a consultancy: not only you get the hours of the specific people on the project, but the combined knowledge of the rest of the people within the consultancy.

Furthermore, if you are thinking about performance, first check the section fundamentals below, second, as I said on the last post, profiling/observability are your friends.

But we are looking for a Tech Lead. No, you are not. You are looking for a manager, a person with “power”. The tech lead, well any type of lead, for a team is the person to whom everyone goes to ask questions or get advise. Separate the idea of Leadership and Management.

But we don't have time to train. Oh, now we are getting somewhere. A) you don’t want to train people ( which always remind me of this conversation: X- What if we train people and they leave? Y- What if we don't and they stay?), B) you are misunderstanding what you are doing: the tech is not what you are trying to solve, you are hiring people to solve a business/social problem, and the tech can change if such is the need/desire.

But we currently have a very specific problem with this specific tech .... Get a contractor, and then make sure your employees learn.

Fundamentals

Recently came into contact with the idea of AOS vs SOA. My introduction to it came from the game development world, where performance and efficiency are critical in a lot of cases. The reason why you maybe want to switch from AOS to SOA is due to how memory is cached and accessed. Data structures are a fundamental. Knowledge of how hardware works is a fundamental (otherwise, people would not think that a network round trip somehow is the same ball park as a call within the same computer)

Understanding constant, linear, quadratic, … behaviour in either speed or space, and therefore knowing which data structure or algorithm is more appropriate is a fundamental (each language will have their differences, but hopefully they have documented that, right?)

Map/Reduce is a fundamental. Doesn’t matter if you are using C#, Python, Clojure or Haskell.

Network topology is a fundamental.

The fundamentals are used everywhere. The fact that a delegate in C# is declared like public delegate int PerformCalculation(int x, int y); doesn’t tell me much about what is the point of a delegate if I come from Clojure. But if I say a delegate is what allows higher order functions (a fundamental) on C#, then now you know when and how to use them.

A developer with full syntactic knowledge of a language but that doesn’t know the fundamentals is far less useful than a person that knows the fundamentals but not the language.

Culture and Attitude

Being in the wrong culture, or a place where the direction is going towards a place you don’t like is soul-crushing. Motivation decreases, happiness plummets and people are out of the door quickly (check next section)

Having a culture that allows people to improve, become better, and that want to make the system/product better is the best possible setup for a company (based on my own experience). The only way to keep that culture is that everyone involved is aligned with it. The individual attitude of each person is important to keep that culture. Therefore that becomes the most important trait that you need to look for in a prospective employee.

A ping pong table, a beer fridge, or bean bags are not indicators of a good culture. At best, they mean nothing, at worst it means that someone completely missed the point of what is important.

A good culture, in my view, revolves around individual empowerment, a learning culture, and transparency. Those allow for people to be at their best.

Finally, culture is difficult to maintain, you need constant care, consideration and pruning. Supervision is required at all times, even in places where their culture is strong, otherwise it becomes easily unraveled.

The London problem

I want to mention this briefly. I always call it the London problem, as this is where I work, though it seems that is not unique to this city. It feels to me that the average stay of people at a company in London is 1 year. The attrition rate of companies in London feels astonishingly high. In that environment, companies do end in a constant hiring process. Which is interesting as most of them still have bad hiring process, and also it becomes impossible to create a lasting culture.

Why does this happen? Is it because the way that you can only get a good improvement on compensation if you leave? Is it because people lack a sense of agency on companies, and therefore they see them as something transitory? Is it because the environments created are not conductive to people staying? Is it a failure of management? I know one thing for certain, people have a lot of inertia, and people don’t leave a position if they are happy (caveats abound, like massive improvements or going to a position that they think will make them even happier).

I have my ideas, but it is something that I need to investigate further.

Hiring

There is a default imbalance on the hiring process that is never acknowledged. For an interviewee to go to a new company is far riskier than to for a company to hire them. While getting the wrong person is something that you can deal within the probation period, with some money and time costs, for the interviewee going to the wrong company could have serious consequences in the life of the person (even with the awesome NHS and free healthcare, you don’t want to lose a job). That needs to be acknowledged before we even go into hiring practices. You want to sell your company, as much as you want to get the interviewee to sell themselves.

I’ve been involved for the last 8 to 10 years in hiring (on both sides) and modifying hiring practices. Technical interviews have been always part of the process. For a while now I say to the interviewee that finishing the exercise is not important, what I want to see is how they think, how they reason. But the more experience I have, the less I care about the technical interview. Spending a few hours with a person before hiring them, just talking, understanding them is, by far, more important than what they can do in the usual limited time involved in technical sessions.

The ones that are an absolute waste of time are the ones were the interviewee has to do a coding exercise at home. First, let’s go back to the imbalance issue, because now that person has to spend their own time on doing the exercise, while for the person reviewing the code just represents part of their normal working hours. But also it only shows some tech knowledge, but no information about how is to work with that person. Just don’t.

I am leaning towards a few hours of conversation as the best way to hire the right people. Maybe include some pair programming, but only after the interviewee is already comfortable. Because is during that conversation that both parts can understand better each other, and comprehend where each stands, if there is a fit on culture.