Consider the following:
A paper with Chinese characters is passed into a closed room through a slot on the door. The room’s occupant picks up the paper and examines it briefly, but he can’t read Chinese characters, and so he shrugs and sets about his task. He brings the paper over to his desk and opens a hefty volume containing thousands of rules describing a complex procedure. The rules themselves are written in English, but they are extremely tedious and dry, and so the man feels no enthusiasm for the dull task that he now begins to execute. The book tells him to look at first character, painstakingly copy a few of the inscrutable Chinese characters onto a new piece of paper, and then proceed to follow the rule on page three-thousand, four-hundred and ninety-eight. The rules are extremely detailed, providing a course of action for any possible set of characters. After several hours, the instructions tell the man that his task is complete, and that he should now take his new sheet of paper and pass it back out through the slot in the door.
A native Chinese speaker then retrieves the resulting sheet of paper and reads it, likely with some surprise, for the sheet of paper contains a coherent response to the letter that she had written and slipped into the slot earlier in the day. The volume of rules is a remarkable piece of work, indeed. It describes a completely mechanical process by which any suitably meticulous person can appear to understand the Chinese language.
The situation that I have just described is a thought experiment known as “Searle’s Chinese Room.” The philosopher who originally described these events used it to show that even if a computer seemed to understand Chinese (or English, French, Spanish or any other human language), it wouldn’t neccessarily mean that the computer was sentient, as you and I are.
Of course, this is all common knowledge for most computer programmers. However, you may not have realized that a variation on Searle’s Chinese Room has been adopted by many large software companies.
The “Large Software Company Room” method begins when a software team-lead passes a piece of paper through a slot in the door and into the sealed room. The piece of paper contains a list of character strings, mostly made up of English letters, but with the odd number thrown in as well. For example, character strings such as WTL, DB2 or UDP sometimes appear on these lists. The occupant of the room examines each string on the list, and compares it to the character strings on a stack of other documents. If he finds that one of the other documents contains one or more of the character strings on the list, he places that document into a separate pile. Once he has finished sorting the documents, he takes the pile of documents that contained at least one of the desired strings and passes the pile back out through the slot in the door. The software team-lead outside of the room may then select one of the resulting documents, called “Resumes,” and contact the person who wrote it. What I have described as the “Large Software Company Room” is more commonly referred to as the “Human Resources Department.” In practice, the list of desired strings will frequently also contain other qualifiers, such as the number of years of experience in using a particular character string.
Sometimes this system can have undesired consequences. If a software team-lead asks for “Resumes” containing “Java,” then all resumes that don’t contain “Java” but do contain strings like “J2EE” and “JDBC” will be discarded. The obvious advice would be for the software team-lead to simply be sure to include all character strings that could possibly indicate a desirable candidate. However, I doubt that this is really a workable strategy. For example, even if I’m looking for a Python developer, that doesn’t mean that I would automatically eliminate a candidate with no Python experience. If they had experience with Scheme, Erlang, Haskell, Ruby, Smalltalk, Perl or any number of other interesting tools and technologies that have piqued my interest, then I might decide to invite that person to an interview. The only way to really know for sure is to see the Resume myself.
I understand that this may not always be possible if a company receives ten thousand resumes for a single opening, but how often does that really happen? I don’t object to HR departments helping to take some of the burden of hiring away from technical people, but the help should always be optional rather than being forced on resentful software developers by arbitrary corporate policies.