Things I learnt about tech recruitment in the last 1 year

Last one year has been a crazy ride. We have been working with Tech teams, recruitment teams and understanding their challenges. We have just gotten started and there is a ton of stuff I learned already.

A quick background

We built a product called TalFinder that helps teams hire software developers using full stack assessments which require candidates to code and build features or fix bugs. This is a better approach as opposed to solving an algorithm based question or writing snippets that generate an acceptable output. Our product uses a full stack IDE that works completely in your browser. This makes it very easy to simulate real work scenarios & use boilerplate code from your existing repositories.

When we began our customer discovery process, the things I saw customers doing, shocked me.

Hiring is the bane of everybody’s existence

Hiring managers need to hire for survival but it is the part of their job they hate the most. Recruiters look tired, haggard & sick of talking to candidates. The average conversion rate from Resume shortlisting to Offer is 2–4%*. Most companies complain that many candidates bailout a day before their joining date. When this happens, the whole process is a waste so they try to make more offers than there are positions. The time taken to close a position (depending on the role) can range from 2–8 weeks. All this makes everyone tired & ready to cut corners. Hiring is one of the most crucial activities and everyone hates it. Ever heard of anyone doing a great job at something he/she hates doing?

*based on our customer discovery interviews

Candidates will cheat the crap out of companies

This was a shocker. I found out about candidates cheating on coding tests and live video calls. In some cases, they get through several rounds of interviews before being caught.

A customer told me about this time he hired two engineers for critical positions. Turns out a startup was coaching them to ace the interviews and in some cases impersonating the candidate. This whole situation has made the landscape for remote interviewing fragile.

Too many rounds of interviews

Most companies seem to have 4 rounds of interviews. A lot of times, these rounds are a repetition of the last round by a different person. It can be avoided by letting people in the panel sync-up. Despite efforts from recruitment teams, this never happens. Nobody has the time for it. The only time I got a sensible explanation was from a big firm that made sure every candidate interviewed by a diverse panel to eliminate bias.

Scheduling is a huge problem

In-person interviews are hard to schedule. Almost all interviews get re-scheduled at least once & given the conversion percentage, most of the time is wasted. Both parties are responsible for re-scheduling.

In cities like Bangalore, travelling takes up a lot of time. Candidates usually have to take the day off to attend an interview. This means when you actively job seek, you risk tipping off your employer. Fun fact, someone in HR analytics told me that he’s written an algorithm that looks at swipe patterns, leave records of employees and predicts if they are likely to be job hunting. The manager gets an alert and can try to re-engage the employee if he/she is a valuable one. Combine this with the fact that Hiring managers tend to re-schedule interviews because of busy schedules, you have a recipe for disaster.

To prevent all of the above-mentioned issues, companies tend to reserve Saturdays for interviews. Since many companies do this, candidates are shuttling between interviews on Saturdays. This means a lot of times, Hiring managers are waiting to do the interviews but no one turns up until late afternoon.

Recruitment teams are ill-equipped to do what is expected of them

I once met a prospect whose recruiter was phone screening candidates. She was given a sheet with questions and keywords that she needs to look for in those answers. She wasn’t a technology person. These are questions on docker, Kubernetes, EC2, Linux Process management & how to choose storage on the cloud(S3 vs NFS vs Glacier). I couldn’t comprehend how she is supposed to do a good job at this.

Most recruitment teams have KPIs with little support to achieve those KPIs. It’s a flawed system. Recruitment teams seem to be performing 3 activities:

• Identifying resumes

• Scheduling & Managing Interviews

• Rolling out offers

Over time, recruiters see a lot of candidates getting rejected. With a high rate of rejection and their appraisals at stake, recruiters tend to use the machine gun technique. Spray everything in sight and hope something hits the target. Tech teams get frustrated and get tougher. The result sometimes is not amusing. Recruiters desist from using technology assessment software because they filter out too many candidates. They want the team to hire somebody & the more in the pipeline, the better.

In my humble opinion, more tech people need to run recruiting teams for software companies or run recruitment firms. This will enable the recruitment teams and prevent them from becoming postmen delivering messages.

Hiring for attitude not for skills

Attitude is definitely important but not a replacement for skills. If I need a developer with specific skills to hit the ground running for a delivery that is already delayed due to staffing, just attitude doesn’t do much. Skills have to match. I could hire a great JS developer & put him/her on angular, there will be a learning curve but he/she will get there provided the attitude. But to hire only for attitude is very tough and is very subjective to the opening in question.

I met a recruitment team that felt placing the initial bar high based on skills would mean they would never close the position. The hiring manager felt that the candidate would eventually get rejected down the funnel so why not prevent waste of time. The debate ended being about skills vs. attitude and went no where.

Writing code on paper

Many companies ask candidates to write code snippets on paper. Developers are uncomfortable writing code on paper without an IDE doing the work behind the scenes. Most of the new developers have written code only on IDEs, that means having intelli-sense, code completion etc. When you give them a paper, they blank out. White-boarding or paper tests are good for testing logical flow or asking them to draw out an architecture diagram, not for coding tests. This has got to go.

Candidates and compartmentalisation

Some candidates hate compartmentalisation while others want to be compartmentalised. If you are a front-end developer and your experience level is 3 years, I would argue that you should experiment with different frameworks. Often what we see is that an Angular developer doesn’t want to work with React or VueJS. Usually, working with a diverse set of technologies makes your view on what is good vs. bad very solid. I have met good developers who are ready to work with any framework, these are the guys who make great architects some day. They have solid insights on why I should choose one framework over another. Early on in your career, you should do all the experimentation to learn. Unfortunately, a majority of the candidates don’t do this and miss out on great job opportunities. If you are an open source contributor to a framework, ignore my advice. You are in a different league.

This is an opinion and more relevant in an Indian context. The services industry does development for companies in the West and whatever is trending there is echoed here. It is a demand-driven market. The danger of this is that homegrown product companies find it very tough to source talent on technology stacks that don’t end up outsourced. Sometimes, faster time to market means picking a less popular stack and getting things out of the door. While making this choice, companies don’t take into account how hard it is going to be to hire for those stacks. They end up losing the advantage over time.

Should coding assessments be open book tests?

The answer depends on your culture. I met customers that wanted phones in lockers during interviews. Somebody keeps walking around to check if candidates are looking up solutions on google. I don’t see the point. Unless you are asking the candidate to solve a problem which clearly has the code available on the web, looking up stack overflow is the most common thing a developer would do. The goal of a programmer today is to reuse and prevent reinventing the wheel as much as possible. How can you do this without using the web? Some practices need to go as they don’t make sense. Developer interviews cannot be treated like exams in your high school.

Final Thoughts

Tech Recruitment is a beast. It has many different aspects that need solving and often the products out there solve different parts of it well. The other parts remain unsolved causing grief elsewhere. There are many human factors that make solving this problem a huge challenge.

Things I learnt about tech recruitment in the last 1 year was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.