In my post on Thursday, I gave some example interview questions with the third one being a question about the detailed workings of one of several different computer scenarios including loading a web page, booting a computer, and a couple others. These questions are looking for domain knowledge, i.e. information about general fields of knowledge within computer science and practice versus information about a specific piece of hardware or software. You might well ask, why does he care if someone knows this stuff? Isn't the knowledge about that particular system better? Sure, but it would be way too time consuming to verify, for example, the details of the networking stack for an application, and in some cases the information isn't even available. You have to assume that things have been done in a sensible way or according to a known specification or pattern, and once you make those kinds of assumptions, your mental model of how that specification or pattern operates comes into play.

Mental model theory is a well-known psychological theory of human reasoning that says that rather than using deductive reasoning to solve most problems ("if X than Y" type stuff), humans build little models of situations in their head and refer to them to answer questions. It makes intuitive sense if you reflect on your own thinking. It is important though that when you are forced to rely on your mental model instead of being able to test things directly, that your model be accurate, or you will jump to nonsensical conclusions about how and why bugs are occurring.

For instance, you are working on a networked system and you are investigating a bug where some data is being lost in transmission. I have a mental model of network transmission where I imagine the data being snipped into little packets, tagged with a endpoint location and then relayed through a bunch of other computers to get to its destination. If pushed, I can get into the details of TCP stacks, how routing works, even the low-level details of ethernet transmission, but most of that doesn't really matter and so my default mental model is "good enough". In that model, I can easily see situations under which some data might get through but other data is lost since I know that the data is being turned into packets all of which may take a different set of hops through a network. However, if your mental model of a network imagines some sort of direct connection between the two machines with data simply being passed from one to the other in a big chunk, a partial transmission might seem totally baffling. This is an extreme example, and I assume that most developers with a basic CS education understand at least about packetizing, but I've been wrong before.

So in the example interview question, what I want to hear about is their mental model, and to a lesser extent, their direct technical knowledge of a particular specification or implementation although I don't expect them to quote RFCs to me. Also, I want to see how aware they are about their own thinking. I would much rather hear, "I don't really know what happens between here and here", than make something up that is patently false. We take these mental models for granted and it is easy to overlook flaws or gaps for a long time because we are never called upon to reason about a situation with that level of fidelty. In the world of debugging though, you will need to be very aware of how you are imagining the situation and what conclusions you are drawing from that world inside your head.