Some thought about hiring in IT

1. Summary
   
2. Background
3. What's wrong with the current IT hiring
4. An idea to better IT hiring
5. Conclusions
    

Summary

The following article describe my current way to engage developers. It's proven over 15 years that it works. It's a fair, simple and efficent way to hire new software developers. 

 

Also I try to show why coding challenges are a bad idea for hiring.

Background

Thanks to Robert Niestrój to trigger me to finally write this article after so many years.

 

First, a few insights from me.

• I'm a big enthusiast of agile software development since many years. And I mean agile software development in the Agile Manifesto way and not in AGIL(TM) Way or how I call it WAT-JIRA aka Waterfall process with misused JIRA.
  
• I was hired
• positive: 11
• negative: 6
• I hiring
• positive: 6 (FTE) and many more students
• negative:8

But be careful with this data, the are only the cases I can remember. The real numbers may be higher. IMHO I have some experiences from both sides of the table. So let's start.

What is wrong with the current IT hiring

The code snippet is part from a coding challenges which are popular since some years. I can't remember when I first saw it.

 

Robert's question reflects a typical IT hiring process and show also why this way doesn't work. In my following words, I exclude all special things like hiring a 10X for Rocket Science or so, that's adifferent stotr. For now, I assume that you try to hire one new developer to get more development power or to replacing someone.

First an first most important, you are hiring people. Yes, yes I'm a agile software guy. Please read the first line of Agile Manifesto under the viewpoint of hiring. Before you process reading this, you should wait 5 minutes and think about it, you hiring people. Speak with them, ask them interesting things, not this standard phrases like weaknesses, strength, where do you see you in 5 years bullshit. These question does not work anymore. Predictable questions produces predictable answers with no information. Remember you try to hire a coder and not a manager. These kind of questions are a waste of time, for both sides.

 

All psychologiacal games cast a bad light on your company.

Coding Challenges missed the smart guys

Coding challenges are pointless waste of time. Imagine following scenario, I'm going to a job application in a IT company. On the other side of the table is a team lead or a software architect, god forbid, remember I'm a very experienced Java Native, my counterparts often stops developing 5+ years ago, so my challenge is to meet the lower technical level of my counterparts. An believe me, if I come with some latest edge case programming ideas, I will not get the job. People tend to engage people that are not smarter them them self (Well done ESA). Coding challenges are for me like rolling dices.

 

At this point if I should do a coding challenge, I will stand up and say polite "Thank you. My time is to valuable." and leave the building.

Coding Challenges missing the shooting star

Most coding challenges are overwhelming for newbies like graduates or career changers. They won't make it. You wasting potential.

Interpreting the coding challenge results

Let's go back to the coding challenge example. There is the Lombok data annotation. It's very popular because it make it run. On the other hand it adds some often not used code for equal and toString. This means you generated more code then needed and this maybe increase the properbility of side effects. One of these side effect could be that you log sensible data via toString. So how rate it in the coding challenge.

1. The data annotation is right because it make it run, it's only one annotation instead of two or three. In 95% of all cases is equal to high sophisticated multi annotation apprach. Form the development time perspective it's faster.
2. The seond mult annotation approach don't generate unused code. It makes it more side effect unlikly. But on the other hand in 95% of all cases it's waste of time because the outcome it the same.
   

So what is right, it's in the eye of the reviewer. Is one appraoch better then the other, it depends on the context of your application. It's not a developer skill. The developer skill is knowing the differences between booth solution. And by the way, there are many more soltions. Speak with the guy.

Should you hire the first or the second one. It doesn't matter. But anyway, you have to realize that you and all your developers learning new things. And if he doesn't know the difference makes him not a bad developer. Or how I call it, develop your developers, develop your team.

Some simple ideas to a better IT hiring or what works well

This is a fair, simple, working an very effective way to make a job interview. Only preconditions are a good kind of common sense and hot tea or coffee. Instruct all your interviewers how it works.

1. Interview format (2024): Only 1:1, simple talking, no tricks, no traps, no games, 10 to 30 minutes, two interviews with the candidate in a row, at least one with a team member. As preparation read the CV carefully, better more then one time and make some tea or coffee and bring some cookies and be on time.
   
2. Decision making: No discussions, every participant take a Postit and write secretly yes or no, a maybe is a no. Reveal. Hire the developer only if booth noted YES.

If you make a negative decision, tell the candidate, no delays needed. Do not justify your decision, no discussion, the result is final (like my method parameter). And if you decline him and you know a company that fits better to the candidate, give him a hint.

Conclusions

1. Always remember: You hire people. People are the real value of an IT company but can also the biggest risk. 
2. Hiring people is the biggest investment you make.
3. Try to hire smarter people. 
4. Treat applicants as human beings, be honest, do without psychological games.
5. Coding challenges are in most cases a pointless waste of time.
6. It's better to miss a good one then to hire the wrong one.
7. It's better to hire no-one then to hire the wrong one.
   
8. Have a good conversation with the applicant and use your common sense. Your common sense is a strong tool. Or how I say: "If it looks strange then it is strange".
   
9. Develop your developers
   
10. Company HR Departments are 95% use-less.
11. Recruiting agencies are a little better but expensive.