You’ve gotta understand — when you interview a developer, it’s not an interrogation.
Sometimes you learn the harshest life lessons from the unlikeliest of sources.
And you never ever forget those lessons throughout your life.
Some time back I was in the process of recruiting a bunch of “coding superstars” for my organization.
Candidates came in and went out but none of them could even closely match the exacting standards of my expectations.
And then one day I found my “gem” at last.
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.”
“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 dumbfounded, angry and confused, all at the same time seeing the audacity of his statement
I resisted the urge to THROW HIM OUT while allowing him to give his 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 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.
Bringing it all together
I lost my respect on that day but I gained something else on that day; I learned how to respect candidates and treat them as equals.
Good developers are in hot demand these days and if we want them to join our company, we should interview them properly. We should always remember that an interview is a two-way street. The developers are also evaluating the companies and they also have the option to reject the bad ones if required.
Every interview is like doing a business negotiation. On one hand is the organization with needs and business goals. On the other hand, is the professional developer who can help the organization achieve its goals. It requires a win-win situation for both parties for the negotiation to bear fruit; simple as that.
As Mark W Boyer has rightly summed up.
“Experienced managers interview to “Qualify”… inexperienced managers interview to “Disqualify.”
About the author-:
Ravi Rajan is a global IT program manager based out of Mumbai, India. He is also an avid blogger, Haiku poetry writer, archaeology enthusiast and history maniac. Connect with Ravi on LinkedIn, Medium and Twitter.