Broken tech interviews

I am of the opinion that a tech interview needs no preparation apart from doing a great job in a setting similar to what we give an interview for. Doing a great job as a programmer involves a few major type of skills – Technical aptitude (Ability to learn something quick either from manuals, tutorials or peers), ability to work along with others, communication, fundamentals of programming like functional, oop, tdd.

Interviews have a problem “Like hires like”, if there are no checks and balances the entire organisation will converge to a narrow band of skilled people. Too much emphasis is placed on competitive coding and algorithms at many places. This is similar to hiring sprinters for your football team, they are fit and can run very fast, but they probably can’t play football or in a team setting well. This leads into a spiral of hiring more and more competitive coders and set the interview benchmark to hire similar people to do work that requires a lot of communication and co-ordination (teamwork).

This results in undue pressure in the industry, to be able to code competitively, the skillset which contributes only to a small portion of success in day to day work. Because of this, good application developers are left out from the hireable pool. The problem of this interview style is amplified by large new age companies who do not have a great product strategy but minting money through one or two cash cows and burning it in other engagements. This leads to headcount game to consume the budget, I have interacted with some developers who have cracked those tough interviews only to end up copying values from one spreadsheet/slide deck to another wasting their potential.

At the other end of the spectrum are interviews which are just fact based, this is done to reduce the amount of workload on technical interviewers by giving a template Q&A to recruiters who conduct the first round with strict matching of answers to the questions. This encourages rote memorisation especially for graduate interviewees without solid understanding of the fundamentals. Some organisations hire easily, but to staff on an assignment they interview people again internally, defeating the purpose of first interview in place.

Hiring is still a heuristics game, you catch a glimpse of the potential and continue with the person. To make the heuristics effective, interviews for developers need to have the following characteristics

• Have a diverse set of people in the panel, take the following into account – programming experience, relevant experience, management etc and huddle with the entire panel of all rounds to take a decision. This helps minimise ‘like hires like’ problem.
• Give more importance to design, architecture and clean coding skills than competitive coding. This will help in interviewing in the space that is closer to everyday work.
• Check feedback and communication skills by reviewing and extending functionality on a code. This ensures how well this person can be a team player and not a soloist.

Originally published at vinod.blog