Hiring is Broken: How we fix it?

So this is a very Flammable topic, I really thought a lot and like all good and complex things, I got mixed feelings about it. After careful considerations, I decided to blog about it. Seriously I was thinking about writing this blog since 2015. So now I think to write down my experiences and thoughts about the subject. Maybe now during the COVID-19 because there are layoffs and hiring freezes things will change and hire might get fixed but let me talk about these experiences before march 2020(COVID-19 Strikes). The technology was always about people, talent people are hard to get and there always was and there always will be a fight for talent. So you might be thinking id there are a lot of companies hiring and lots of people doing hiring process things must be smooth right? Repeatable/Scalable, Clear, and really no issues right? Well, we are not quite there yet. So the first issue when you are talking about the subject could sound a lot of bad things like OH: you are doing the hiring process right now or OH: You did not pass the interview process on company X so you are complaining or OH:  You want to impress HR. For me, that was not the reason I want to write about this subject. Hiring is broken if you do not want to take my word, read this paper.

Why Write About Hiring?

First of all, because I always write about all sorts of things like Agile, Lean, DevOps, Architecture, Design, SOA, Java, Rust, Scala, Discovery, or whatever I please like dealing with the COVID-19. Secondly, because I know how engineers feel and guys you are not alone. I get it. I also had bad experiences. Another reason is that at some point you might be part of the hiring committee in your company so you might have a chance to do things differently. Around 2002/2003 I remember doing an interview and failing and I remember the HR person telling me: " I will give this feedback for you too improve because in the future you might be someone calling the shoots so you can help others'. So that happens and I never forget that advice. The advice was "Answer the questions".  Do not deviate, whatever you do Answer the question. 

Hiring Context and Dynamics

We need to understand the context and hiring dynamics in order to understand why is broken. So for the engineering perspective, you might be looking for a new job for several reasons like:
1. You are sick and tired of your manager
2. You feel de-valued and believe could be earning more money and have more appreciation. 
3. You want to change career path. From manager to engineer or from the backend to frontend. 
4. You might want to change the country(very common nowadays) for political/security/economical reasons. 
5. You might want a new challenge or are demotivated by the current job/project.  

I'm sure they might be other reasons but I believe this one is very common. Now let's talk about the company who is hiring perspective which could:

1. You lost a person(so you are losing money).
2. You got a new project and expand your employee headcount(you are losing money). 
3. You want to expand your offers. i.g Data Science (you are losing money).

No Matter what you do, if you are a service provider company, it's almost sure you are losing money.  If you are an HR consultancy you need to get people HIRED to received so you are losing money too. There is also another issue here. Often companies have more than 1 service provider. Meaning whoever hires first takes it. So the positions are limited and as the time pass, multiple companies are losing money so the is a natural RUSH for it.  These is the scenarios for Technology Service companies. However, for product companies, they are a bit different.  Although they are losing money too they can afford to wait a bit more and often do a more "Long" hiring process. So with these 2 scenarios we often get 2 different but equally broken hiring outcomes:

1) You are hiring too Fast - so you rest are very weak. (Poor Candidates VS Money)
2) You are hiring to slow - You are losing lots of google people. (Stream of People VS Money).  

Both scenarios money is on the trade-off like I said before for service companies the money part is much higher. For product, companies are less complex because often they have huge marketing and everybody knows them and want to work for them so might have a huge stream of the candidates. However, I dont believe this will work forever as companies change the culture and get acquired/sold. 

Why Hiring is Borken?

So there are 2 scenarios of broken hiring, let's go to ug ht them.

Services Scenario is broken because:

1. There is a push to hire with a simple "manager interview". 
2. There is a huge pressure to get the process working as fast as possible (1-2 days if possible).
3. Often Managers are hiring not engineers or people who are technical enough. 
4. There is a huge cap between Company Values and day-by-day Lean/Agile work. 
5. People do not communicate with each other very well. 
6. Recruiters do not spend much time with each candidate so the whole thing is very "mechanical".
7. There is no look for cultural FIT what-so-ever.

I'm sure you know people who make lots of money and can't do a bubble sort or for loop without using Streams right? ...OR a case you need a fight with management every week to not hire people just because they know them from the industry or events. 

Product Scenario is broken because:

1. The process is too long (5-10 interviews).
2. The process of Cultural FIT is biased and judge too fast. 
3. There are too many people asking the same things and is like people only know 5% of the whole. 
4. There is no Clear preparation path - just say "Algorithms and Data Structures". 
5. There are no clear and repeatable fair criteria that everybody follows. 
6. There is lots of pressure when you are doing coding interviews with obscure algorithms. 
7. Your resume, experiences are completely ignored or badly weighted. 

I'm sure you read on the internet cases where people wrote entire oss frameworks and did not pass the Google interview process. ...OR crazy complex algorithms nobody uses day by day and interview block you because you did not know to remember up-to-front. 

How hiring is affecting engineers?

In the past easily an engineer could be just doing engineer, right now that's not possible anymore. Do not think that's is something for small company only, big tech companies are doing the same, there a lot of good reasons why engineering need to be around for hiring and even hunting. Let's go there:

1. Engineer respect and follow other engineers so this is huge for talent attraction.
2. At the end of the day, you will be working with that person is much better to have a say right? 
3. Engineers can evaluate things that HR cannot like technical level, lean/agile skills, problem-solving skills, troubleshooting skills, and so on and on.

So engineers need to adapt and deal with this new reality. IMHO the solution is to throw engineers everywhere, sales, marketing, HR, and so on and on. 

How can we fix it?

So here comes the interesting part. So let me share with you guys how I',m doing the hiring in the last +10 years. I would not say is perfect but I think like any model there are pros and cons. So let's get there: 

1. If you multiple tools, basically there are 5 tools I mix and score from: Long Test, Short Test, Team, HR, and My Take. 
2. Long Test is a 48h hardcore test the person need to code. You do it from home and you can use the internet. 
3. Short Test is a 45min-1h very very simple algorithm test like Revert a String. 
4. The team is a 1h team meeting where the team can ask questions - no code asked. 1 single vote cast. Yes, or No from the whole time, the majority wins. 
5. HR is the classic HR evaluation, you know so see if someone is too crazy :-) 
6. My Take is my evaluation: Lots of Gut feeling and cross-people talk conversations. 

How the technical part is evaluated? I already look to some dimensions like:

1. Clean Code: Is the Code readable? Can other people maintain it? 
2. Extensibility: Is the solution extensible? Can you add new concerns easily? Do we have extension points? interfaces?
3. Testability: Do we have tests? Do we have a Stress Test? Chaos Engineering? Observability?
4. Performance / Scalability: Does this code scale? It's Time and Space-efficient? Does the solution scale as a whole? Is architecture Good?
5. Logic: Has the solution well thought? Or we use relation DB for everything? Do we have optimizations? Do we have good and proper error handling? 
6. Automation: Do we have a build script? Are we using a maven/gradle? Do we have deploy scripts like Terraform/Ansible? 

You might say Diego this is crazy. Well, this is real guys. A real/proper solution should have this aspect. Even if you did not finish or went trought all these aspects you are giving a real scenario with a real problem with a real stack and dimensions people need to worry or should worry at the day-by-day job. 

For me is all about complementary tools like the Long and Short coding with my view + team view + HR view. Doing badly in one does not necessarily mean the candidate is bad. We need to keep in mind that looking for raw talent is more important to them someone 100% ready. You might not find someone 100% ready and with all Sharpe's elbows. For me, the real question is, can we develop this person? Does this person can self-thought and learn fast? Does this person show it can be trusted and will FIT well on the culture? 

In regards to team culture or company FIT, I'm always looking for someone who can receive and give real feedback all the time, is committed and is hardworking, who really want to make things happen and is looking for challenges, not power, not building empires but building awesome products and kick-ass solutions. In other words, lots of potential for the future but humble. 

Accepting reality - Preparation Tips

First, you need to adapt to reality before changing it. This means, no matter if is a service or product company hiring method both potentially will have flaws and you need to pass it, so get prepared. Once you are growing up on the ladder you can propose changes and introduce more fair or complementary ideas to make the process better.  

Video


Cheers,
Diego Pacheco

Popular posts from this blog

C Unit Testing with Check

Having fun with Zig Language

HMAC in Java