There is a lot of dispersion between the skills one needs to be good at interviewing and the ones that are required to get the damn job done. The former requires math problem-solving abilities which essentially boils down to playing the game and gaming the system. It’s that classic human construct to which everybody adheres to establish a standard. You can observe this pattern whenever the demand side of things gets exploded. An objective filter gets developed and is used as a metric to screen the best. In the software industry, most of the big tech, where the pool of applicants is high, resorted to interviewing the applications using algorithmic tests. It makes sense for them to do this. But the repercussions may not be immediate.

The problem with having standard algorithmic tests is that people resort to gaming the system in innumerable ways. Leetcode is the test book material that one refers to while prepping for an interview. No domain expertise is being tested. Hence there is no incentive for the interviewee to ramp up their specific knowledge cause it has no use. Now, this is where things generally start to fall apart. In the good old days, the average lifespan of the software used to be around 5 yrs. Whereas, now it plummetted to 2 yrs. Essentially you have to rewrite an application that has been written 2 yrs ago. This can happen for a bunch of reasons, but the thing I am most interested in is the lack of deep specific knowledge that is required to write reliable and maintainable software.

If you start cramming leetcode questions day in and out, how can you develop the knowledge required to write software that is well tested and maintainable? If all you practice is writing helper functions in test prep platforms, how do you plan to write software from scratch and deploy it in the modern infrastructure? When faced with these questions people come up with some version of this answer. Training people. Yes, training people is good for upskilling, but you can’t expect many of the folks to write a good frontend application by running a react bootcamp for 4 weeks. All you can get from them is spaghetti code. This can work for startups where software rewrites are common in the early days but not for a big corp where the tech debt grows exponentially with every passing year. And nobody wants to address this tech debt.

If there is no value to being a specialist in this industry, then don’t expect people to write code that spans decades. Then there is a serious attrition problem in the tech industry. As Chamath says “how can you expect people to do any meaningful work if the average stay of a person is 3 yrs?”.

There is another extreme of interviewing people. That is interviewing for framework ninjas. You can generally observe this kinda behaviour in DBA(database admins). They know to make a database performant by optimizing the queries and stuff but they can’t spin up another database. They are specialized in using the tool and that’s what they are good at. But what you are looking for in a good hire lies in the middle of this skills spectrum. You want people with some sort of specialization who can also develop a solution in the case a situation demands it. These are the people you develop a new database technology by some means if they aren’t satisfied with the ones they are using it. And they belong to the mythical 10x engineer group and ninja coders. And to become one takes more than munching leetcode day and night. It needs a holistic methodology where you focus on upskilling yourself on a greater time horizon rather than attending a day bootcamp.