“The only problem worth solving is that of talent.” – Startup founder

 

The hiring process – it’s state of being broken or not – has been widely discussed. Right from big technology corporations to small, growing startups, there seems to be a huge division in opinions, processes and biases. A recruitment process, after all is the fundamental building block on which a company is built.

In the little over 1 year of our existence, we’ve witnesses over 300 interview rounds for our candidates. And the one thing that this has taught us, is that a tech interview is extremely unpredictable. Unfair, broken, prejudiced or biased – call an interview process what you may, the only thing that we’re certain of is its unpredictability.

 

A few reasons why:

 

Organisation as a structure

One of the biggest factors why the interview processes and experiences differ so widely is because no two organisations are built the same. Nor do they function the same. The way teams are structured, the way decision making flows – the general setup of an organisation is something that influences hiring processes a lot.

 

Experience, Exposure and Skill sets

The rise of the startups has given a whole new meaning to the relation between experience, maturity and skill sets. There used to be a time when more experience with software directly related to better maturity and skillset. (when we say maturity, we mean the ability to understand organisational level requirements, to be able to see the big picture). But the team dynamics and structures have now changed.

The experience and the exposure of the person conducting the interview plays a big role in it’s whole interview process.

 

The Likeability Factor

This is one of the most common biases we’ve come across. The person conducting the interview is more likely of choosing a person that they like (have a personality match) over a more qualified candidate.

And this factor is really closely related to the next point.

 

Lack of Preparation (not having the requirements chalked out)

During a software development cycle, not having the requirements clearly chalked out is a surefire sign of impending disaster. Similarly, if the requirements, roles and responsibilities expected out of a new joinee is not crystal clear – the interview process is bound to run into problems. This translates into the interviewer not being well prepared. This results in two types of interviews – a) problem solving for the wrong kind of questions, for example a frontend engineer being asked to solve for Dijkstra’s algorithm. Or b) ‘Only the fly’ interviews where the interviewers see how the conversation goes.

 

Having clarity in the exact role requirement has been a key factor in smooth interview process. And we’ve seen it trump every other bias that exists. The more clarity you have in the new role requirement, the better prepared you can be to ascertain the skills required. The more clarity you have as to where the person will work, immediate co-workers, managers, the better you’d be able to measure the all important culture fit.

 

Being better prepared needs time. A lot of it. And, that is an entirely different problem to solve.

 

    

 

Leave a Reply

Your email address will not be published. Required fields are marked *