Why technical recruiting process is broken - 2
This is the second part of my series on why I hate the current technical recruiting process.
Disclaimer: This post is not my typical post where I write goodie goodie stuff and nice things. This post is a result of my 3 months of in vain efforts. Efforts I took to get the best result, and with each effort came a failure which took a nasty stab at my confidence, self respect and self worth. People could've judged me better and fairly, but the current system does not allow them to do so. In this post I am writing some of the frustration I have with current process and how I will try to fix it in the hypothetical scenario
This is the story from few months back when I was appearing for various technical interviews. When I began, I was so happy about my prospect, I had a masters degree, good list of side projects and 3 years of iOS experience - A skill not quite routine and valuable in the job market.
But guess what, I was wrong. Every iOS job I interviewed for started with algorithmic question. Not that I could not answer them, it's just interviewer always demanded for most optimal solution in 15 minutes. (First 15 minutes to present original solution and last 15 minutes for Q&A). Not very ashamed of it, but I failed at most of them.
I sometimes wonder if someone really uses these problems in day-to-day life at work? I am pretty sure day-to-day work is much simpler or is quite irrelevant to these questions. I mean how many people are going to craft a solution for dynamic program or recursion in under 15 minutes unless they've seen it before? Not many. And if they've seen the question before and know the answer already, doesn't it defeat the purpose of an interview?
Given the difficulty level of these questions, I wonder how many current employees of top level companies can get selected when presented with same set of questions they like to fire at candidates? However, thanks to an unknown pioneer, but all the technical companies are taking this approach nowadays which makes less sense.
Do you want to gauge if person has enough knowledge of work he or she is going to do or will fit the company culture, why can't we ask more questions from their domain of knowledge and ask them to give examples of their leadership and mentorship skills? Asking programming questions related to their domains is fine. But,
- Dynamic programming problem
- Egg problems
- Knapsack problems
- Robin-Karp string comparison algorithm
- Write program to find square root
- Write program to find if square root of number of perfect integer
- Write a program to convert any roman number to integer in 20 minutes
REALLY? How many interviewers can answer even one of the above questions on the spot? And you want prospective employees to answer them for you? Even if they do answer them, how many times are they going to use them at job?
I am pretty sure never. Still they will keep asking these useless binary search, linked list, trees and graphs problem. To be honest, you are not testing candidates' analytical ability, but you're gauging their memory. Majority of them will already know the answer from one source of another. (CareerCup and GlassDoor). Some companies are so lazy that they will keep asking same GlassDoor questions over and again.
This is the reason I feel bad for some deserving candidates due to such orthodox vetting process while undeserving people who know how to game the system get away with it. On one occasion, when I applied for an iOS job, I answered all the iOS related questions, but failed at one of the dynamic programming problem which I saw for the first time and interviewer expected an answer from me in under 15 minutes. Needless to say, I flunked in the first round.
I have countless examples, but two such examples stand out. One of the people I worked with at previous company deserved to go to and almost got to one of the top 3 tech companies. But in his last round, interviewer judged him on one of the obscure dynamic programming problems and he got rejected. Other occasion, a guy from my university - pathetic GPA, never contributed to group projects, famous for breaking builds and caught up in Plagiarism scandal, twice - Once officially and another one unofficially got into Amazon and then after 1 year into Microsoft.
In these examples, I feel bad for first guy. When he deserved so much more and could've climbed the ladders of success had to give away that opportunity. Why? Because he didn't know answer to question he possibly was never going to use in his software career. Second guy may have by hearted all the answers and got lucky. If you are worrying about second guy, don't worry. His resume is solid strong by now, but I still wouldn't hire him. He is the reason I am saying no matter how much so called challenging your recruiting process is made, you're still going to incompetent people as an employees.
My thoughts on interview process are, rather than solely concentrating on some random algorithm questions and expecting candidate to write "clean" code on board, you can gauge his soft skills and test his technical skills pertaining to job. But I know, no one is going to do that, everyone thinks their interview process is too perfect.
If I ever open a software company, I will try to avoid standard interview questions as much as possible. Rather I would do following things
- Try to contact my past colleagues and managers if they're interested in job
- Try to talk to some eager to learn and smart new grads
- Talk to people who are open to new ideas
- Work with team oriented people who are great guide and mentors
- Look into open source field. People who write and contribute to open source projects
- People who invest in learning and working on side projects
- People whose interests and experience strongly aligns with my requirements
- Talk to their former university colleague and co-workers
In my opinion these are few ways to gauge candidate for open position. I am not saying I won't ask any questions to test candidates' analytical and logical thinking, it's just that they won't carry the entire weight.
