Here are two extremes.
I interviewed in Manhattan at a company that occupies a building with its own postal code (a fact I do not think will make it unique in any way). Either the second or the third interviewer was a fellow who strode into the glass box that served as the interrogation chamber, carrying a stack of papers the way the Romans carried their shields. He locked the door behind him to facilitate a strange observed-by-the-world illusion of privacy. Perhaps this is what people mean by "transparency."
Time has passed, and many questions were asked that day, but a representative demand was very close to "Tell me how [name of function] in the pthread library works." I replied that I had been using the standard thread library in the C++ STL, and while I did not know the answer I assumed the libraries were probably similar. He snorted up a little contempt, and then checked a box somewhere within his shield of papers.
I was surprised, and fought back a little by asking of him "Isn't the real issue in multi-threaded programming knowing when there is a good case for creating a thread, and the design of the program so that it can exploit the abilities of multi-core processors by using multiple threads? After all, Google can tell me the argument list to just about any function." He snorted again, gave a "yes-but" word of agreement, and reminded me that while mine was the answer to some question, it was not an answer to the one he had asked.
Recently, I had another interview in which the topic of threads arose indirectly and accidentally from me rather than the interviewer. In a room with five or six simultaneous interviewers, each of whom was a senior and capable developer, I was asked to describe a project of particular interest to me.
My answer involved a factory simulation. Somewhere during the minute or two I gave as a summary, I mentioned that one way to view fork lifts moving things around the shop floor was that each could be considered as a single worker thread in the simulation, sometimes blocking each other but hopefully rarely.
Not the questioner, but one of the other interviewers said quietly, "I think you understand threads well enough," and we went on to talk about the challenges in the design, and how the passage of time had expanded the catalog of solutions for problems that require parallel processing.
Testing people to see how well they play Trivial Pursuit has its benefits. No doubt if you hire people who play the game well, you will staff your organization with good players. This type of testing is much like testing would-be firefighters to see if they can quickly ascend a ladder while carrying equipment, come down safely, and do it again three or four times without a rest.
For prospective firefighters, this type of testing is important: we cannot allow the fires to burn for a month while our firefighters get into shape. Even a firefighter's ability to search the web instantaneously for training programs does nothing to abate the flames.
It is here that the symmetry is broken: Firefighters must continuously be re-tested to assure the public that their abilities in this critical area remain intact. To the best of my knowledge, programmers who pass the interview fact test about thread libraries are never retested to see that their collection of immediate recall has remained intact. If the ability to snap recall atomic facts were important, continuous testing of this ability would have started years ago.
To contrast, the coffee house testing is reasserted each day of employment by the natural activities of the job: software development is mostly an experiment in collective thinking, and where it is not, it should be.
Want to talk about your interview experiences? You can get my email address here.