I had previously written an internal memo about how I conduct technical interviews at Zid, which has sparked an interesting discussion. There, I mentioned that, in technical interviews, I do not necessarily specifically look for technical knowledge — that is, how much the candidate already knows. Instead, I look for how they would interact in a knowledge exchange setting. In other words, how would they react if someone taught them something or they taught someone something? How would they behave in a setting where they are the least knowledgeable person or the most knowledgeable person?
Here, I will expand on this thought and discuss what I would learn about a candidate depending on how they react during the interview. Keep in mind that the interview setting can affect the candidate, but I think given how informal we, at Zid, try to make them, this effect is negligible.
Now, in the interview, we do a design exercise where I present the candidate with a product idea and some constraints and ask them to guide me through their thought process to build such a system. Here, we get to our first road crossing. Some engineers would be paralyzed and ask me to guide them. Usually, their first question is: What do you mean? They want a set of well-defined questions for them to answer and not an open-ended prompt. These engineers are executor engineers. The team lead[1] gives them clear instructions of what they want, and they execute[2]. Other people would start answering immediately. They do not ask any clarifying questions. They just go! These would usually mess up and go all over the place, and I would have to stop them to reorient. The last group are ones who would explicitly state their assumptions (or ask for ones). They wouldn't start the design without ensuring they understand what they are getting into.
The candidate's attitude towards this exercise gives a glimpse of their leadership style and attitude. Some people will never make a decision on their own. They might come up with options but never decide. Others would recklessly make decisions. And there are those who make well-thought-out moves.
Also, this demonstrates how independent the candidate is. There is a difference between asking to understand the context to make a well-informed decision and asking to push the interlocutor to make the decision on your behalf. There is a balance to strike between assumption-making (based on context) and asking questions to be independent yet not naively reckless. If someone asks too many questions, they require too much babysitting. And if someone asks no questions, they do not know what they do not know. To be honest, I've yet to decide which one is worse.
Returning to the interview, we get to the more technical parts as we go through the discussion. This is where I get to assess the candidate's technical depth. In the previous parts, we mostly learned about their mindset and attitude. Here, I would ask the candidate to concretely specify how they would implement this system.
They should choose the programming language, framework, and data stores (yes, plural). The majority of people would suggest the stuff that they already know. They would choose the programming language and framework they are familiar with and one of the major relational databases (i.e., Postgresql or MySQL). A small minority would be adventurous and suggest tools they have never used but heard might be appropriate for their case.
To assess their understanding, I would do the following: If they chose the tools they know, I would suggest to them a different tool that could work just as well (or better) and see how they differ – if at all. Some would say they simply do not know, some would make stuff up to defend their original stand, and some would discuss how this suggestion would or wouldn't work, given the system constraints addressed earlier.
On the other hand, if they were adventurous, I would point out a known problem with the technology they chose to see if they really have a technical logic behind the choice or if it is just chasing the buzzwords. For example, I once interviewed an engineer who solved a query performance issue with Elasticsearch on the explore page of their app – note that this app did not have search functionality. I asked them why they did not use their existing Postgresql database with a few materialized[3]. They said they did not think about this, which says much about this person's understanding of databases. If an engineer jumps to a new tool without fully exploiting their current ones, it indicates the depth they would take in solving problems (e.g., performance regressions are a very common example).
Circling back to my original point, all of these discussions should be viewed as knowledge exchange settings. Presenting a design is knowledge exchange, objecting to it is knowledge exchange, and defending it is knowledge exchange. Evaluating a knowledge worker should be based on this measure and not purely on what they already know. Nobody knows everything, and they are bound to learn something from someone. And at the same time, everyone will have to teach someone something at some point. So, their attitudes in these conditions will make all the difference in their success with the team and the organization.