Unless you're using a functional programming language that does not support iteration. (and even if it does support it, it's typically preferred to use tail recursion)
This sounds great, and in theory should work on a well integrated team of autonomous individuals. I guess as in most things, common sense is the key requirement to make this a reality. Alas, common sense isn't very common...
I'm currently working on a mssql shop, and on aws it's more than twice the price vs postgres or aurora. I don't see how you can justify the price difference
You are correct, "culture fit" is not a good descriptor of what I meant.
We hire people we believe we will be able to work with. It's not a popularity contest, we evaluate problem solving, analytical thinking and communication skills, such as the ability to explain complex topics in easy terms.
I'll give you an example, usually we are interviewing people straight out of the university, but this can be applied to any candidate.
I'll start by asking the candidate to talk about his master's project. As he talks about it, I'll guide the conversation towards these topics :
-What was the problem
-How was it defined?
-How did you tackle it?
-Explain your solution
-support your decisions
-Was there a cost/benefit analysis?
-How was the problem decomposed?
This will give me an initial picture of the candidate's ability to address a problem, and is far more important to me than wether he knows "the number after F in hexadecimal" or some other nonsense.
I always interview for "culture fit". In my experience, that's almost always the bottleneck, and the technical part is rarely a problem. Learning a new skill is not an earth-shattering problem if you have a good attitude towards work, and good interpersonal skills are a must in teams
In my experience it's too high. I see a lot of unit test code that doesn't do anything except add complexity. But again, I guess this will depend on the nature of the project
I may be in the minority, but I find the 50% unit test coverage not useful, and sometimes harmful. Caveat emptor - depends a lot on the project, and how often you are changing the code and/or the complexity of said code.
During my bachelor's we used this all-encompassing book by two of the teachers called Distributed Systems for System Architects (DSSA for friends). It followed a case study of a fictional company that wanted to implement a distributed system, but the level of detail and technical complexity it covers is just mind boggling ( http://www.springer.com/us/book/9780792372660 )
To this day it's probably the best CS book I have ever read.
Going back to the white blood cell count. The gold standard is flow cytometry. If there is an interferent in the sample, or if the cytometer raises any flag, in some labs the backup plan is to do a manual count (100 cells) using whitefield microscopy ... are you really concerned about sampling problems?
I'm sorry but this is incorrect for a lot of blood tests. When the theranos debacle unfolded there was a paper making the rounds (no doubt leveraging on the media's attention)that argued this point for white blood cell counting. The conclusions were overblown, there is increased variability when using small amounts of capillary blood, but the tests are still useful. Furthermore, a lot of parameters are less sensitive to this heterogeneous distribution of the analyte.
Case in point. Major companies like roche and abaxis have had point-of-care medical devices that perform blood testing for various parameters that use a drop of blood.
Theranos's problem was that they said they could do pretty much every parameter under the sun, and they used an FDA loophole to operate their lab. It was later discovered that 90% of the tests were not being processed with their supposed technology.