Hiring for any company is a critical task, and a wrong hire costs much more in the long term. Over the course of my career I have hired close to a 100 people for various software engineering positions, and I have had my share of challenges. It has taken me a  lot of hit & trials to get to the right approach.

Below is how I approach hiring for my software engineering teams.

Resumes are a waste of time !!

Resumes are good way to summarize someones experience but there is no way to objectively judge any person by their resumes. I have tried bunch of tools to filter candidates based on resumes, but eventually I have realized that resumes are not something anyone should be looking at. It's just a waste of time !!

So, now I don't look at them in most cases. Even when I do, I don't judge anyone's skills by the resume. At most the resume tells me how good the written communication of the person is. I much rather prefer candidates send me the link to their GitHub public repository, where I can look at the actual code they have written.

Judge people on practical skills they have

At the end of the day the primary goal of a good software engineer, is that they should be able to write code, and have an aptitude for problem solving.

If a candidate has  a repository, where I can look at samples of their codes, they go on the top of my pile for people I would like to talk to. I will go ahead and look at all the code that is in their repository, and judge them on the quality of that code.

Next step is talking to them, my first conversation is generally 30 mins, just to understand the candidates communication skills, and their ability to solve problems. I would generally use an example from any of the projects they have worked on, change some requirements and see if they can think of how they would approach that change from a solution perspective. I don't look for right answers, just an ability to think and not be stumped by a change.

Why is this important ? Because I am big believer in the fact that the best output for any software product comes when everyone involved can bring some ideas to the table.

Show me the code !!

Once I want to move forward with a candidate, I would typically give them a problem statement for which they have to write code.

For interns, freshers, and junior developers I prefer using my online testing platform QuodeIT. It is simple to use, and gives me quick results of how many test cases were passed for each code submission. That is all I want from a junior developer, I don't expect them to know architecture or tons of technologies. I expect them to know 1 language, and be able to write code in that language to solve a simple problem, thinking through all the scenarios from a unit testing perspective.

For senior developers, I would give them a bigger problem for which they would have to think about different aspects like architecture, logging, interaction between layers etc. I expect senior developers to be someone who can independently take day to day architecture decision, and help junior members of the team with their issues. I would ask them to first give me an estimate of when they would be able to submit the code. This tells me if they are good at planning, and can they stick to the deadlines they commit to. I don't reject people if they are delayed, as long as they let me know. Also, I ask them to create a README file for the project, which should cover how to setup the project and run it. This tells me about their communication skills, and the ability to articulate their thoughts. This is an important skills for people you would want to groom as leaders in your engineering org.

Code review

Then I do an interactive code review over a call. Where I would go through their code and ask questions about why did somethings. Also, challenge them on their decisions and hear what they have to say about it.

For senior developers this process goes further to challenge them on their choice of tech stack, frameworks etc. It's important for me to know their opinions and thought processes. I don't mind people having strong opinions about technologies, as long as they are patient listeners about conflicting opinion. This becomes a good thing when the team is making decisions.

The code review process is the longest of my whole hiring process, because this is the time where I can accurately judge the person. Sometimes, I would ask the person to change some small feature,  just to again make sure their ability to think and problem solve.

Culture

I always say that you should not hire a person who is not a cultural fit, no matter how good they are. A wrong cultural fit will do more harm to your team, than the value they can add. I have seen this in many organizations, where people who do not fit the culture are hired which ends up costing more to the team.

Earlier I used to do a detailed face to face interview, to try to judge the person culturally. But as technology has evolved, I was able to productize this as part of our QuodeIT platform. It also makes my decision making very objective, as opposed to just depending on my gut feel.

This seems to be a lot work !!

Yes, hiring right is a lot of work. It's not easy, and you should spend that time to make sure you build a team that can deliver for you. The idea for me is simple I spend time hiring the right person, in the longer run I will not spend time/money in trying to get the best work out of them.

Hirings should never be a quantity game, its about quality. 1 right hire, is worth much more than hiring 10 wrong employees.

As the world changed a few months back, and organizations had to adapt to a new completely remote work environment, I saw a lot of organizations buying remote employee monitoring software. The spend on those softwares is actually one of the long term costs of wrong hirings. As, I said when I started this post cost of a wrong hiring is much more in the long term !!