Most startups are too busy doing their core jobs and often do not have time to innovate in non-core areas. One such area is recruiting and they tend to bank on the best practices available in the market. We were in the same situation till last year. For all our technical hiring we were relying heavily on “the brain-teasers hiring” prominently used by Microsoft, Google and the likes. We were sure that it would meet our requirements and moreover it provided an opportunity to offer mental-stimulation to ourselves; as we would prepare ourselves with the then in fashion-questions before interviewing candidates. I personally respect and like this urge of interviewers to appear smarter than the interviewees as it often results in re-skilling oneself. 
For the past one year, there is a buzz in the tech-circles that Google’s way of interviewing is under serious threats including Jon Evans’ The Technical Interview Is Dead and Google’s HR heads’ admission: brainteasers are a complete waste of time. This June, while planning our recruitment calendar for campuses, I decided to do a critical review of our evaluation process with our team. Pressing question was whether we were doing the right evaluation of candidates and making the “All Star Team” or do we need to rethink. I found that most of the team members were in the same plane and findings were encouragingly shocking:
- With the rise of recent Outsourced Development Centers by global companies like Google, Microsoft, Amazon in India and recent boom of e-commerce funding; students now have a lot of options and hence are preparing themselves for this cult of interviews. In some cases the preparation goes as early as fifth semester (of eight semester program). Most of them want to be evaluated on mugged up brain teasers.
- Though this is of no harm, in fact is a positive exposure. It is throwing them away from core competencies. I was able to prove to a couple of folks that the title of their B. Tech. project is inconsistent. This is something which I would have never imagined to be true during my graduation days back in 2001. Focus now has shifted to cracking a hip-hap company interview rather than creating a hip-hap project.
- Maintaining a CodeChef and HackerEarth online rank appears to be mandatory. This, no doubt increases the intensity of candidates and love for coding. But is somewhere compromising their love for their B. Tech. project and directing them to turn into mere coders with short sighted but intense problem solving.
- With plenty of guides available on how to crack Google interviews and sites like GeeksForGeek, there is a new economy evolving around interviewing whose focus is to make these interviews emulatable or spoofable. The charm of originality which it offered when Microsoft first started it, is no more seen. It has become too mainstream.
- We were sure that if we do not innovate now, we may end up with more number of people who know “why manholes are round” than people who know “difference between a deadlocked process and tight-looped process”
Our love for “brain teaser cult” was thus over. Trends on the internet also favored our decision, most companies including Google are now rethinking.
This decision left us with the question. What next ?
We decided to do away with the “notion” that hiring is not a core focus for start-ups. Forming an All Star Team is indeed one of the core focus. I once came across a nice article which pointed out: if you do not hire a driver without testing how he drives, how can you hire a coder without actually testing coding. I decided to follow suit and give this thought a try. We are good at developing products and want our All Star Team to make industry changing products, thus we should be evaluating the same. We modeled our evaluation scheme around the two most important aspects of serious product development
- Code penetration: Let me define code penetration as the speed at which an individual can go into a previously written code and own it. It is very important for one to be able to put oneself in original authors’ shoes and then take complete control. This is very important for the continuity of both; product and platform
- Individuals who treat code written by others as grey would ultimately increase silos in the code and make it fragile and fragmented. A good coder should be brave and take responsibility ensuring continuity.
- Besides fragmented code, resistance to penetrate code would eventually result in a lot of rewriting and eventually end up in reinventing the wheel thereby reducing the speed drastically.
- Visualization: Ask any technical aspirant if product development uses Left Brain (responsible for logic) or Right Brain (responsible for creativity) and it is highly probable that is answer would be the former.I found this number to be around 80%, during my presentations across campuses. They are right. We use our Left Brain during Product Development. In fact we use it very much in any software development.What differentiates product development from regular software development is ‘Visualization’ – a critical Right Brain function. It refers to individual’s ability to visualize
- various usage scenarios and the big picture of the product
- blocks and work in abstraction. Unless one is able to visualize abstraction, he tends to be more monolithic in design and thought. This is very important aspect for agile and platform based products.
We have been implementing the same this year and have been receiving positive feedback so far. It may be too early to predict the results of this interview approach as it shall be available only after one complete cycle, but this has been a joyful discovery and ride for me in person and the team in general.
Very cool article!
LikeLiked by 1 person