Are you also looking for common hiring mistakes and how to avoid them?
“We’re a three-month-old startup that is low on budget, of course, we’re struggling to hire a decent developer, we probably don’t check a single thing on the developer’s dream list.”
I couldn’t disagree with the statement when an acquaintance shared his hiring experience. He had a tough time finding the right people, an up and coming startup doesn’t have awesome talent lining up at their doors.
But then startups find great talent too. I’ve been privileged to work with some terrific developers and I didn’t have to move heaven and earth to find them.
Competition for talent and the uncertainty of startups doesn’t make it an appealing choice. Startups have to compete with tech giants for good talent and they can win it too! It’s not impossible to find and hire good developers.
Digging a little deeper to understand what the root of the problem turned out to be an eye-opener really.
Tech is the base for most of the startups today. The development has become the way of implementation because we’re living digital and working towards automation. Technology is the means to scale ideas too. So every startup out there needs a tech team at some point or the other.
But thousands of startups are repelling developers.
Non-techies have no idea how to hire techies!
I’m sure they all get the general picture of hiring, a screening, a few assessments or challenges, one or two interviews and you take a call and pick your guy or gal. Except the tech version of this process had so many holes, it’s a stretch to call it a process. The nitty-gritty of tech hiring is lost on them.
This sends bad signals
The hiring process is designed for you to evaluate and assess your candidates. What most people fail to realize is that it is a two-way street. There’s a lot your hiring process reveals about your company.
And this really matters.
I’ve met so many recruiters who think that if a candidate really wants to work for their company, they have to go through their process, no matter how messy and useless it is. That’s just a bad case of attitude.
You have to ask yourself, is that what you want your employees to think about your company. They are working for you, so you expect them to run through the hoops you want. Is this the culture and environment you want to create? Because it sounds a lot like you want to lord over your people instead of working together with them.
How your candidates are treated through your hiring process is a direct reflection of how they can expect to be treated as a part of your company. It is a preview of how the rest of your processes are functioning. If your hiring process is disjointed, unorganized, and discourteous, that’s what the candidate knows exactly what to expect from the company.
Here’s how you are repelling your potential developers into not joining you
Don’t you felt like you’re doing something wrong with your hiring?
Sending irrelevant assessments
Assessment is one of those things you have to do before you hire right? So obviously, you have to somehow create and send one out.
I had a call with one such recruiter a while ago. He had to test 23 developers. That summed up his total knowledge of the situation. He didn’t know what stacks he wanted to test, the experience level of the candidates he was testing, or even what the assessment had to entail.
Unfortunately, this happens all the time.
Don’t send a basic level assessment to test for a senior position. Just like you can’t send a complicated test beyond the comprehension of a junior candidate. You should preferably find one that doesn’t involve too much of anyone’s time. You’re assuming that the candidate follows through and invests time in their time in it.
You have to find a task that properly assesses the candidate depending on their skill level and experience. Personally, I believe skill tests have run their course and project-based assessments are taking over. I find live coding sessions far more relevant than skill tests too.
Setting excessively difficult standards
Test your candidates for the job they are taking up, not to beat Einstein’s IQ. It doesn’t make sense to set tests that are too difficult for your candidates.
Again, it’s all too common an occurrence. Some see the difficulty level of the test to be some kind of rigid standard that they have to adhere to. Some tend to think it’s a reflection of the company’s expectations too. A few hiring managers feel like sending out complicated assessments is correlated to being intelligent people themselves.
Task levels are subjective. For some, it is simply about filtering weaker candidates too. Avoid tasks that are knowingly too difficult for your candidate. Focus on relevance. For example, it makes more sense to ask senior developers about real-life problems in a collaborative environment. Look for a contextual understanding of the person’s strengths to help with your decision.
Skill tests that do nothing for anyone
Skill tests are the go-to means to test how proficient your candidate is at a certain skill or language. Just because your candidate has his or her concepts right, you cannot guarantee problem-solving though.
Skill tests cannot test the approach and perspective of your candidate. They might be necessary if you need to quickly filter out a lot of junior developers but they are not sufficient to evaluate senior ones.
They fail to mirror reality and the work environment too. It often comes down to a candidate’s memory rather than experience and skill. A skill test is a bad way to screen experienced developers, they lose touch with the basics, it’s kind of demeaning to take a low-level test for a role that requires some experience.
More about the merits and demerits of skill tests here.
Whiteboards giving you wrong feedback
This is one of the longest standings but most flawed approaches to testing talent.
Whiteboards are immensely pressurizing. Interviews are pressurizing enough as is without adding unnecessary heat. ‘Is my handwriting legible, am I making spelling mistakes, am I writing in straight lines..’ They might not even be conscious of it too.
A lot of good developers flunk whiteboards. They feel like fish out of water when you cast aside laptops for a marker. People don’t think and by extension code linearly, they often put together blocks and move them around to best fit the logic. This is not possible on the board.
By introducing a whiteboard you are blinding yourself to the developer’s ability to do the actual job you’re trying to hire them for.
Having non-tech folks taking tech interviews
Please stop doing this.
It’s surprising how not enough developers don’t see this as a red flag. It totally is. If I have to convince a person who has no knowledge about development that I’m a good developer, I know there is something fundamentally wrong with the approach or the expectations of the company. Sure, you can and will collaborate with them at work, but don’t have them evaluate your tech skills.
A complete turn off is to have these non-techies pretending to be well-versed in the field. Candidates see right through these too. It’s one thing to have to explain it to someone who doesn’t know, you could still avoid the jargon and find ways to communicate your skills or knowledge. But there’s no thinking further if your interviewer thinks he or she can pull it off.
If you’re needing to have non-technical recruiters hire technical roles, make sure they are equipped with the right tools that they need to be successful. Otherwise, it’s not easy to distinguish between good and great candidates.
Does your hiring process involve any of the above?
Are you repelling your potential developers? Share your thoughts on why that might be the case, I’d love to hear about it!
