mlashcorp

Pagerduty is up

Also, Portuguese for boat.

Well, not in a jar ... Right?

Ah gotcha. Apologies not a native speaker so the nuance was lost on me

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

Never has man so eloquently expressed the frustration of millions (OK maybe thousands).

The trick to use C++, is to use less of it. C with classes and namespaces. Oh and smart pointers.

I believe resilience is the big one

I agree, I regret my use of the term "culture fit".

Please see my other reply below

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.

I guess you don't know your audience ;)

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.

For that, hire a programmer. Need a dependable architecture for mission critical software? You get the point ...

Some people know how to program. Other people dedicated years to the study of computer architectures, first order logic, distributed systems, fault tolerant systems, etc ...

In my opinion, computer science and engineering is not about just making the code you're told, it's about questioning whether that code needs to be done in the first place, and if so, how.

It saddens me that laypeople equate software development to writing code, that's like saying an architect just knows how to draw.

There has to be a better way ...

Yeah... Have actual machine learning experience as well, never heard the term leverage as applied here. Sometimes the nomenclature can confuse people, and I guess the original point about more in depth interviewing processes was related to discerning whether the fundamental knowledge and team fit are there, not whether the candidate is aware of the particular subset of CS trivia the interviewer is currently interested in. I say this while admiting that I've made this mistake in the past while interviewing candidates for CS positions...

What's his h-index?

I actually find this clever and patentable. It's machine learning assisted caching for physical packages. Now it all comes down to the predictive performance of their algorithms.

Sounds like fiction

It's working for me ... this was a godsend! Thanks a lot!

I get your point, but knowing the differences between http, udp and tcp isn't minutia ... it's cornerstone knowledge for anyone working with distributed systems.