Each year there's an ongoing discussion about tech interviewing processes. It's almost like Christmas. Once a year, there we go. That's not new for experienced people in the sector, but it may surprise folks that work in other areas.
Can they do the job?
The software development industry is relatively new, and it's disconnected from most Computer Science curricula. We learn calculus, physics, algorithms, data structures, and whatnot. Yet, there's not much emphasis on shipping production-ready software or working in a multidisciplinary team to create a mobile app.
Some years ago, there weren't many distributed systems courses. Nowadays, most companies are building them. The same is true for mobile development. However, we shouldn't convert universities into market-driven machines. Universities should be knowledge's Cathedrals. They should drive students to understand things from the basics and learn how to learn.
That said, this creates a problem:
How can we assess if that person can do the job?
That's the Saint Graal for software-first organizations. Some common ways companies conduct interviews are:
- Take-home projects where a candidate has a few days to build a project, such as a REST API and a small client.
- To answer quizzes on coding, networking, distributed system, operating systems, and other fundamentals.
- Pair-programming a kata or fixing a minor bug.
- System-design interviews. The candidates design high-level, known applications like Uber, Twitter, etc. Then, the interviewers add more constraints or scalability features.
- Code reviews of existing company's code or the candidate's decisions made on a take-home project.
- To solve coding puzzles involving algorithms and data structures. Usually, in a one-on-one whiteboard interview or platforms such as codeinterview.io.
Generally, there's a mix of this kind of interview in a process with two to four steps. There are many criticisms to almost all of the above. Nevertheless, it isn't possible to optimize all the variables at the same time:
- "An agile process that doesn't take eight hours from the candidate. They have a life and shouldn't spend all these hours in a take-home exercise."
- "A non-whiteboard exercise, because people get nervous and it's not representative of day-to-day work."
- "Better not be a coding exercise because there's more to software engineering than code."
- "Pair-programming is complicated because it creates a disadvantage for introverts."
- "It shouldn't have many interviews. Also, it must avoid biases."
- "Let's not create a bar exam and a professional association to recognize people's abilities to perform a job. That would impede people without a degree to get a job in the industry."
- "It shouldn't generate a lot of bad hires because using the probation period is dangerous. It generates too much rotation and lowers the morale."
While I sympathize with some of the above points, we can't have the cake and eat it too. In the best-case scenario, we can optimize for the company's culture or the taste/culture of a percentage of people we believe are our targets in the market. Having a process that caters to the majority of developers is a delusion.
Exams, professional associations, and corporatism
Some folks in the software industry think that having a "bar exam" and a professional association could reduce the effort we put into interviews. Studying "Cracking the coding interview" and preparing for whiteboard or system design interviews is time-consuming. If we're applying to a FAANG-alike company, depending on our background, it can take up to hundreds of hours.
One could say that the upside of it is well worth the time. There are exams to access public sector jobs — nurses, police officers, etc. — in Spain and other European countries. These also require a lot of time to prepare with salaries that are not near what big tech companies pay.
The good part of our industry is that it allows people with a Philosophy degree to access a good-paying job. It matters what you can demonstrate you can do rather than a piece of paper. I think that's beautiful. Promoting a corporatist approach to solve the problem is promoting gate-keeping and ensuring high-paying gigs for those already in the sector.
A way out
Is there a way out of corporatism and long, time-consuming processes that don't reflect our daily work? It depends on your pipeline. If you work for Facebook and you receive thousands of candidates every week, maybe they have the leverage to filter candidates. You may require whiteboard interviews, all the interviews on the same day, and whatnot.
For startups or mid-sized companies, maybe there's a way out. I especially like this interview shared by Javi Santana, Tinybird's founder. It requires the candidate to explain how they'd approach the problem and get a good understanding of their written communication skills. It also creates a good starter for a deep conversation during an interview. It doesn't require much effort since it's more a system design approach than a coding exercise.
Another way out is to create different processes and let applicants choose one. It can be a pair-programming kata, a take-home test, code-review, etc. There are two tricky parts to doing so. The first is how to keep the bar consistent across people that choose different paths. The second one is that instead of an interview process, you'd have several. It raises the cognitive load for your interviewers.
Interview processes are full of trade-offs, like everything in our industry. We can optimize for some variables and make conscious choices, but no process will cater to everyone's taste.
— João