Interviewing bad practices
Library knowledge
Probably this is the most common one that candidates face during interview. Questions like “What is the difference between X class and Y class in Z framework” are totally meaningless. They can help you to see if the candidate worked some with the technology but apart from that every question has its exact answer on the first hit on Google – probably a Stackoverflow thread. It all does not matter – the question is: can the candidate solve a problem I throw at him/her? Library knowledge is not problem solving.
Language knowledge
Unless you try to find someone to start your new thing in a specific technology, focusing too much on a single language is a mistake. What if tomorrow someone releases a brand new language that is much better and you decide to use that one? Will you let go everyone and start from scratch? You need people who can learn and adapt. Java or C#? Python or Ruby? Doesn’t matter that much!
Obsessed with previous role
Another pointless question is to try to dig deep what the candidate did exactly during his/her last role and extrapolate that to the rest of his/her career. Try to remember that your goal is to find talents; people with great minds, outstanding problem solving skills and not the ones who had the exact job description at his/her previous role that you are looking for.
Developer role but no coding during interview
This is a bit embarrassing. During hours of interviewing people throw random questions at the candidate: What do you think about X? How many people had you in your team? Although the most important thing for the role is never actually checked. Can you write code? Here is a problem, write code for it. All the rest is just for the show.
Giving hard brain teasers
Some of the really “new thinking” companies throw brain teasers at the candidate right after the library knowledge questions. Now, the problem is that they are great at testing how hard the question is but tell almost nothing about a candidate. Try to keep the interesting “Why are manhole covers round?” questions for Friday beerfests and test the candidates real skills – the ones he/she will use during work! Calibrating these esoteric questions is much harder than programming questions. Focus on what you need!
Hiring by price
Let’s say you can buy an excellent service for X and an average service for 20% less. Which one would you buy? The average service? Great, deal with factory workers and leave the hiring of highly skilled professionals for someone else. Even though on paper most companies acknowledge that some people are way more productive than others they rarely acknowledge that by paying the real talents well. Even if it’s only a negligible 20%. Talents will get you somewhere, mediocre people never will.
Not meeting the team with the candidate
On paper anyone can work with anyone. Reality always tells otherwise. Before dropping someone in a team, make sure they met at least once and there were some resonation. The productivity of a team is incomparably worse if they don’t like working with each other. Make sure they want to!
Too long process, too long feedback cycle
Some companies think if the process is longer they engage the candidates even more. It is true for some extent, but let’s face it, most small/average sized companies make their decisions in a very small group – often a single person decides. If you have seen someone, you already know whether you want him or not. Don’t bother with the “he might be a good fit on the long run with some of the teams” type of people. Yes or no? Give the feedback fast!
Not replying no
No, it is not nice and not humane and not business-like to ignore a candidate. He/she is a human being with values, family, and friends. If you don’t want to do business with him/her that’s perfectly fine, just let the candidate know. Don’t have to explain but a closure really helps most people.
Giving too much feedback
Explaining how bad the candidate performed is quite a bad idea. He/she won’t have the closure and will always hold the grudge. Taking sharp criticism is extremely hard for most of us. If you really need to give somewhat detailed feedback, try to address larger areas he/she can improve on: “You performed excellent in our tests and maybe you can find some place for improvement on responsive web design”. Be very sure that the feedback is correct and cannot be questioned at all. If it’s a borderline, don’t even mention it.
Wasting time on-site
Some people are so bad at managing their time that the only way to force them to talk to candidates is to bring the applicant on site for a personal interview. Try doing a decent phone/skype interview beforehand, don’t waste your and the candidate’s time. Make sure you focus on things that matter (can you code?) and not the usual chitchat about previous roles and reasons for leaving.
Not asking to build something
You quickly tested the candidate’s coding ability but ultimately the question is whether he/she can build something on her own. It does not have to be big, but a reasonable sized assignment before making an offer is not unreasonable. Just because someone can write 15 lines of code does not mean that he/she can build a well structured system!
Too specific job ads
“We need someone with ASP.Net - MVC 4 - WCF - SQL Server - Git - C# - MVVM – Linq skills”*. These types of ads will attract the ones who match the Dunning–Kruger effect nicely: the ones who do not even know what they don’t know. Should I apply if I only heard about MVVM? What if I only used Git for my weekend projects? You will easily scare away people who know that they simply cannot know everything. But at least they know it while your applicants won’t…
* - actual ad.
Job hopper - out
"As a company, we don’t do any of the followings to really make our people happy and want to work for us: Regular trainings, Interesting work, Nice working environment, Frequent company paid getaways, Real career opportunities, New roles within the company, Free beer, Ping-pong table, Reasonable working hours, Fair bonus system… Still, we are amazed why people would ever leave any company – and we decided not to take anyone who has ever had a job for less than two years." First of all, in IT two years can change everything. On top of that, anyone who stays long for a bad company is worse than a job hopper. Make sure you cannot be criticized for anything before you blame your ex-employees or fresh candidates.
Using bad recruiters
Finding good recruiter is as hard as finding good candidates. Working with bad ones on the other hand will not just demolish your reputation but will fail to recognize real talents. It’s not unheard of that some recruiters were in hospitality or personal fitness training business before becoming recruiter in hope for higher salaries. All they can do is try to keyword match the job description with the candidate’s resume. This causes two things: the honest candidates who list only technologies they know well won’t even be considered. The other issue is that candidates –as a countermeasure- will start to “exaggerate” about their skills, making the shy talents disappear in the noise of impostors. If you really need to use recruiters, make absolutely sure they are more than keyword matchers. Ask them to hand out your first exercise and collect the results then have a look at all submissions yourself. It’s your company, your candidate and your decision. Don’t get lazy about it!
What do you think? What else can go wrong?
I wish places followed this. I've seen many places that try to use statistics to hire people and shy away from job-hoppers (I have no clue when this became taboo, or why. Far too often, the only way to maintain a good salary and good benefits is to do this.)
ReplyDelete