3 ms·
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
by 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 agoThe 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.