Bad Interviews can shoo away good developers.
This is Why you Never End up Hiring Good Developers.
Hiring the right developer takes time, the right questions and a healthy dose of curiosity.
You are bad at conducting technical interviews. Yes, you.
You’re asking irrelevant questions, brushing good developers the wrong way, and actively screwing yourself and your company.
I realized my folly years ago when I was interviewing a gem of a developer; one of the best in the field.
He was the perfect candidate in every respect. Every bouncer and missile I threw at him, he destroyed it with poise, confidence, and logic. I soon ran out of questions but there was not even a dent in his armor.
“Ok, Jack, I am impressed. Can we close the compensation part and get you on-boarded quickly” I said, barely able to disguise the smugness spreading all over my face.
He said quietly.
“Ravi, Thanks for taking out time for this exhaustive interview. I always believe that interviews are a two-way street. The company gets to know the candidate and the candidate gets an opportunity to know more about the company. In fact, an interview is the only window available to any candidate where he can gauge the culture of any organization and his fitment into it.”
I shifted uncomfortably in my chair, not knowing where this conversation is leading to.
“Having said this, I would like to decline this opportunity as I don’t think I will be the right fit within the culture of this organization. I do not want to enter into a relationship which is bound to be painful for both of us. He said looking straight into my eyes.
I was annoyed, angry. ego-bruised would be the right word.
I waited for him to give the reasons.
“I am not here to get impressed by you”
Deyth Banger nailed it when he said.
“Better to play dumb than to go as smartass… after all smartasses get what they deserve in the end.”
You spend 15 minutes of the interview talking about yourself, your job title, responsibilities, and skills. You mention about the ingenious ways in which you had tacked crisis situations.
You let me know in no uncertain terms that you are the most powerful person in your organization. In addition to all this, you expect me to be an expert in everything from golf to foreign policy and even the price of peanuts.
What exactly are you trying to achieve here?
If you are recruiting somebody, you should be looking for a problem solver, an asset who can join your team and help it to be better and creative. If you are looking for a submissive developer who just follows what you say blindly, then I am not the guy for you.
All I expected was a great honest and humble technical conversation where we can learn and get to know each other. That would have been a great start to this relationship.
“Brainteasers are a waste of time”
Rebecca Wells once said.
“It’s life. You don’t need brainteasers to figure it out. You just climb up on the beast and ride.”
What is the most innovative way to break a watch?
A clerk at a butcher shop stands five feet ten inches tall and wears size 13 sneakers. What does he weigh?
In British Columbia, you cannot take a picture of a man with a wooden leg. Why not?
As per some enlightened souls, such Brainteasers help in understanding how candidates “think,” especially if they were faced with a sudden and unexpected workplace issue.
Are they good at calculations and estimating? Visualization and problem-solving? Are they lacking in certain soft skills? Are they logical thinkers, or are they more apt to search for the “hardest” way out of a puzzle or business problem?
All this is bullshit.
The ability to answer these brainteasers has nothing to do with how well the candidate can think through the business problem and write well-crafted code. None of these brainteasers will ever give an insight into whether a candidate is a good team player or has great leadership skills.
Such skills are only be found by asking relevant questions pertaining to his experience and understanding situations in his employment history where he proved his mettle. It is time companies dump this archaic practice for good.
“I am not a paper Coder.”
Richard Feynman hit it bang on the nail when he observed.
“What I cannot build, I do not understand.”
You give me a piece of paper and ask me to write code on it. I am expected to remember every minuscule syntax of the language. Every function within the library should be embedded within my mind. Every error thrown by the compiler should flash within my mind and my “paper” code should be near perfect.
I am sorry this is not the “real” world in which I will work.
In the real world, I am supposed to use the tools, techniques, and functionalities available to me to solve the business problem. A great developer uses the resources at his disposal and produces well-crafted code through testing and refactoring. If you really want to test my skills, give me a system and all the resources, I will show what I can do with them.
Developers become great not by cramming and parroting details about every language that comes in the market. They become great by knowing precisely how, where and when to use the tools at their disposal.
“My way can also be the right way”
Michel de Montaigne has rightly said.
“He who establishes his argument by noise and command, shows that his reason is weak.”
You remember the “small” disagreement we had?
I went up to the blackboard and showed you in detail the SAP architecture I had implemented in my previous project. I explained to you all the advantages of the approach and simplicity in maintenance which has become a turning point for operations. I also mentioned to you the appreciations and accolades I got from my customers who were using it.
And your reaction?
“Something is very wrong here. I have architected so many applications and this looks too simple to be true and workable. This cannot be used in the real world effectively”.
“But Ravi, this is being used by 90,000 users across 3 continents and we have received no complaints so far. In fact, we have a bunch of very satisfied users.”
“I still believe the way we are implementing here is the best. It is tried and tested and nothing can be better than it.”
I left the conversation at that.
The point is that I want to work in a collaborative atmosphere where ideas are discussed, contested, and selected based on merit and not by “this is the way we do things here” approach. Every organization uses fancy words like collaboration and team effort and all that stuff but few organizations walk the talk and make things really collaborative.
Creativity needs collaboration to thrive but there is a very thin line between collaboration and colluding. The former is a “disagree to agree” culture which brings out the best in people while the latter is a “agree without disagree” culture which is a recipe for disaster.
I lost my respect on that day but I learned something more. I learned how to respect candidates and treat them as equals.
Bad interviews are easier to conduct. They require less thought and creativity on your part. But the end result, as we all know is disastrous.
That said, there are no rules for good interviews, no acid tests that can be applied. But the payoff to trying harder is a stronger company, better people, a better product, and a happier working life for everyone on the team.
Making those things happen is, as a hiring manager, your only job.
As Mark W Boyer has rightly summed up.
“Experienced managers interview to “Qualify”… inexperienced managers interview to “Disqualify.”