5 ms·

> 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 peop

> 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 mind reading devices are pretty good: "Here is a complex problem that can be solved in more than one way - show your work." > How does that evaluation have anything to do with "diversity of thought"? By clearly demonstrating an applicant's competing priorities by way of solution selection? It sounds like you've never worked on a team that had that one guy who would regularly shoot down seemingly sensible textbook solutions, and instead offer a solution that either sounded like more work or just plain insanity. Have you never heard the story of Mel [0]? I can tell you from my own experience, as a former full stack developer who had to do a lot of interdepartmental work at a non-software company, diversity of thought is very useful. [0] https://groups.google.com/forum/#!topic/net.jokes/k2JVKQzJSpY https://groups.google.com/forum/#!topic/net.jokes/k2JVKQzJSp...

eesmith 8y ago
> "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 very useful" How do you apply it to the hiring process? How does the proposed method (skills testing) result in improved diversity of thought? I'll be more concrete with two examples. Example 1: Suppose there are only three schools which teach COBOL programming, and you are a bank which is looking to hire junior COBOL programmers. Do you design your test for COBOL competency, which will result in preferential selection from those small number of schools and hence reduce the diversity of thought? Or do you hire for more general diversity of thought and expect more overhead to train people in COBOL? Example 2. Suppose you put the applicant on an Ubuntu box and ask them to write a sort program in C++ which takes two command-line arguments. The first is an input file name containing set of lines (ending with a '\n'), the second is the output file name containing the input lines but sorted by byte value. Of those that pass the test, 50 do the 'standard' vector<string> with a sort from the standard library, but only 10 do I/O failure checking, and 1 of the 50 decides to make the parent directories if the filename's directory doesn't already exist. But wait, another 40 treat C++ as C, and use stdio along with a resizing array of char * . Of those, 30 use qsort, 8 implement quicksort, and 2 use bubble sort. (Oh, and one person who didn't finish was 90% of the way through implementing a Timsort.) That's a diversity of thought. Do you give preference to them for thinking about the problem in a different way? But wait, another 7 think about it a bit, realize that 'sort' is on the Ubuntu box, and construct system("sort filename1 -o filename2"). That's surely thinking outside the box, so should be encouraged in the name of diversity of thought, yes? Except another 2 think about it further, realize that the filenames may contain spaces or shell metacharacters, so construct the exec call directly. Security thinking is hard to train, so they should have preference, yes? And finally, the last one writes a C++ program which uses the Python C API to pass in a Python program as a string. Surely that's even more diverse thinking - and completely within the test protocol as given. Now to reverse the direction. I know all of these solutions. If I were given the task and I know that the employee wants to hire for "diversity of thought". Which implementation should I do to improve my chances of being hired? 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?
- zaarn 8y ago
  Here is an example that I've mentioned in a top-level comment here; ask the candidate to design a calculator. Budget doesn't matter and they can do it software or phyiscal. All that matters is that at the end the calculator is the most ideal one for you as the candidate. All the features you wish for and none of the downsides. So you get a bit of paper to draw on and maybe write some short text. Compare the results to what your team has drawn when they were hired (or you asked them separately). Of course the comparison is still subjectively but ideally you pick the candidate with the most different calculator from the others. That's better than coding tests since you can look at the result and it's independent of coding skill. Similar tests are possible where you don't test coding skill but instead test if and how much a person thinks outside the box and what it looks like. This would better help to assemble diverse teams than a simple coding tests. Another one would be to look for people that are contra to the current team. If you develop COBOL look for a developer that can do COBOL but hates it and would love to switch elsewhere. These kinds of people will make your team diverse since they can find problems more efficiently. I think the problem there is that your diversity tests still only test for coding skills, which aren't as important when you consider that someone with a fresh and contra perspective to your current team could be much more helpful.
  - eesmith 8y ago
    The stated goal is to design the model which is most ideal for me. The real goal - meaning, the one which decides if I will be hired - is to design the model which is most different from others. Since I want the job, shouldn't I disregard the instructions and instead create crazy looking calculators which aren't ideal for me but which are different enough to stand out, and thus get me hired? As a test designer, aren't you making a bias toward hiring people who are good at gaming the system? Is that really good for the company? Going back to my examples, which you did not address, would your team hire the "C++ programmer" who implemented the sorting challenge by using the Python/C API to write a Python program? Because that's certainly thinking outside the box. But it doesn't tell you if the programmer would be a good C++ hire. > If you develop COBOL look for a developer that can do COBOL but hates it and would love to switch elsewhere. What? If you want to hire a COBOL developer with the expectation of working for 20+ years at a bank, why would you want that developer to hate that job? Do you have any evidence that they will be "more efficient" at it? Why wouldn't they do the bare minimum need to do a satisfactory job, while looking for a new job on the side. And when that happens you'll need to retrain your new employee. It seems like money down the drain.

eesmith 8y ago

> "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 very useful" How do you apply it to the hiring process? How does the proposed method (skills testing) result in improved diversity of thought? I'll be more concrete with two examples. Example 1: Suppose there are only three schools which teach COBOL programming, and you are a bank which is looking to hire junior COBOL programmers. Do you design your test for COBOL competency, which will result in preferential selection from those small number of schools and hence reduce the diversity of thought? Or do you hire for more general diversity of thought and expect more overhead to train people in COBOL? Example 2. Suppose you put the applicant on an Ubuntu box and ask them to write a sort program in C++ which takes two command-line arguments. The first is an input file name containing set of lines (ending with a '\n'), the second is the output file name containing the input lines but sorted by byte value. Of those that pass the test, 50 do the 'standard' vector<string> with a sort from the standard library, but only 10 do I/O failure checking, and 1 of the 50 decides to make the parent directories if the filename's directory doesn't already exist. But wait, another 40 treat C++ as C, and use stdio along with a resizing array of char * . Of those, 30 use qsort, 8 implement quicksort, and 2 use bubble sort. (Oh, and one person who didn't finish was 90% of the way through implementing a Timsort.) That's a diversity of thought. Do you give preference to them for thinking about the problem in a different way? But wait, another 7 think about it a bit, realize that 'sort' is on the Ubuntu box, and construct system("sort filename1 -o filename2"). That's surely thinking outside the box, so should be encouraged in the name of diversity of thought, yes? Except another 2 think about it further, realize that the filenames may contain spaces or shell metacharacters, so construct the exec call directly. Security thinking is hard to train, so they should have preference, yes? And finally, the last one writes a C++ program which uses the Python C API to pass in a Python program as a string. Surely that's even more diverse thinking - and completely within the test protocol as given. Now to reverse the direction. I know all of these solutions. If I were given the task and I know that the employee wants to hire for "diversity of thought". Which implementation should I do to improve my chances of being hired? 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?

zaarn 8y ago
Here is an example that I've mentioned in a top-level comment here; ask the candidate to design a calculator. Budget doesn't matter and they can do it software or phyiscal. All that matters is that at the end the calculator is the most ideal one for you as the candidate. All the features you wish for and none of the downsides. So you get a bit of paper to draw on and maybe write some short text. Compare the results to what your team has drawn when they were hired (or you asked them separately). Of course the comparison is still subjectively but ideally you pick the candidate with the most different calculator from the others. That's better than coding tests since you can look at the result and it's independent of coding skill. Similar tests are possible where you don't test coding skill but instead test if and how much a person thinks outside the box and what it looks like. This would better help to assemble diverse teams than a simple coding tests. Another one would be to look for people that are contra to the current team. If you develop COBOL look for a developer that can do COBOL but hates it and would love to switch elsewhere. These kinds of people will make your team diverse since they can find problems more efficiently. I think the problem there is that your diversity tests still only test for coding skills, which aren't as important when you consider that someone with a fresh and contra perspective to your current team could be much more helpful.
- eesmith 8y ago
  The stated goal is to design the model which is most ideal for me. The real goal - meaning, the one which decides if I will be hired - is to design the model which is most different from others. Since I want the job, shouldn't I disregard the instructions and instead create crazy looking calculators which aren't ideal for me but which are different enough to stand out, and thus get me hired? As a test designer, aren't you making a bias toward hiring people who are good at gaming the system? Is that really good for the company? Going back to my examples, which you did not address, would your team hire the "C++ programmer" who implemented the sorting challenge by using the Python/C API to write a Python program? Because that's certainly thinking outside the box. But it doesn't tell you if the programmer would be a good C++ hire. > If you develop COBOL look for a developer that can do COBOL but hates it and would love to switch elsewhere. What? If you want to hire a COBOL developer with the expectation of working for 20+ years at a bank, why would you want that developer to hate that job? Do you have any evidence that they will be "more efficient" at it? Why wouldn't they do the bare minimum need to do a satisfactory job, while looking for a new job on the side. And when that happens you'll need to retrain your new employee. It seems like money down the drain.