Earlier quoted context omitted.
> But I can't wrap my head around what "diversity of thought" means, in any meaningful way. For that to be true, you'd have to be unaware of the fact that people can process data and reason through complex problems differently. > I assume 'diversity of thought' refers to expressed thoughts - our mind reading devices aren't that good. That is a poor assumption that requires the redefinition of the word "thought". Our…
> "people can process data and reason through complex problems differently" This was in the context of hiring, and I gave my operational definition - how does one apply 'diversity of thought' to the hiring process? > "Here is a complex problem that can be solved in more than one way - show your work." Presenting a solution, or an attempt at a solution, is an expression of one's thoughts. > "diversity of thought is ve…
That is actually a helpful reminder - the context of the conversation is a blog entry that struggles over the objectives of quotas and the utility of using race and sex as a proxy for diversity quality beyond... race and sex.
> Presenting a solution, or an attempt at a solution, is an expression of one's thoughts.
Yes... are you trying to defend your prior conflation of behavior and thought?
> Example 1 ... do you hire for more general diversity of thought and expect more overhead to train people in COBOL?
That depends entirely upon your organization's capabilities and priorities. Hypothetically lets say that the bank's long term objectives don't include a migration from COBOL, the IT department doesn't have a long history of successful inhouse training, and being a bank - is generally risk averse. First, filter for candidates that demonstrate an acceptable level of competency in COBOL. Second, filter for candidates that have skills and interests that are not organic to your team - but could feasibly be useful (in your mind, that is all we've got). Third, ask the candidates for examples of times that they've come up with novel solutions to difficult problems. Here is a personal example: I once accidentally landed a contract when I was having lunch with a friend and his boss, I was later told the clincher was my long exposition on fault tree analysis in ballistic missiles. The contract involved the integration of time management and security systems.
You seem to be struggling with the prioritization of diversity of thought over skills that are actually need to perform a job. Here is a hint: the first order of business is getting somebody who you imagine can do the job (skills, job history, etc). If you have more options that positions, of those people, select the one who demonstrates the ability to reason in a way unique to your team.
> Example 2.
You hire the guy who points out that you did a poor job of framing the problem. Not only did you describe it in a way that could be interpreted to demand an implementation that spits in the face of POSIX utility conventions (newlines as argument delimiters), but you also failed to establish a success metric (time, maintainability, performance, etc).
> Surely that's even more diverse thinking - and completely within the test protocol as given.
You described a bunch of potential implementations, not different ways of thinking. The protocol you gave wouldn't be useful to measuring diversity of thought, unless you modified it to include the possibility for interviewer-interviewee interaction, where you might get some clues about their thought process. "What is the success metric?", "Are the sorted values bounded?", "Is the source untrusted?", "How does this fit into the larger process flow?"
> That is, should I do something which I know is less maintainable simply because I know it's more obscure and thus shows my diversity of thought?
No, even in the cartoon funhouse of an example you provided - they might already have a Python weirdo running amuck, you'd add nothing. You don't know that ahead of time.