coreyoconnor

I am ignorant of what iHasApp means in terms of users. Much less the ethics of it all. Why is what iHasApp did considered unethical?

One aspect of CoreAudio that, IMO, contributes to low latency: CoreAudio provides the buffers to process to the AudioUnit. Not the other way around. This permits CoreAudio to chain AudioUnits while minimizing buffer use. In the ideal case where all AudioUnits support the same audio stream format they are all provided the same buffers to process. Which can get close to zero-copy, zero-allocation audio rendering.

I don't know enough about android to say that this is the key aspect tho. Perhaps the low level API of android is the same? I didn't find an easy reference in a quick search.

Can we extend this to the rest of Silicon Valley?

I'm curious if the lag between change and impact is about equivalent to the tenure of a management employee.

After reading through a lot of blah: http://aurelia.io/docs.html

No question that Apple's quality has gone done. However, who's has gone up? Or better yet: Who is actually building quality software systems? Comparing only in the same problem domains as Apple: All of my Android devices have been rife with equivalently bad issues. Windows? Different quality issues, but just as bad. Google web systems? Same case. Better in some aspects, worse in others. Perhaps I'm old and jaded. Still, seems like we've reached a point in software development where building quality systems is not possible with existing methodologies. Where some problems, while we are able to develop 90% solutions, the last 10% might as well be impossible. The even more jaded part of me wonders: Does it even matter?

IIRC Space X is going with small rockets to slow decent instead of parachutes. Or in addition to parachutes? I wonder if that would be applicable for the required dV. Or if that is even safer.

I used to work for Fulcrum Microsystems. Super fun. Your summary of the market around that is great. Thanks! I had not thought about them in a while.

The technology involved in enabling 64 octet frames to be shoved around in 300ns is fascinating. The software control of these systems was just as fascinating. These chips had a high level of programmability in the frame handler. How to use that programmability was an open question when I left Fulcrum.

That would match the initial specification. The point is for the candidate to note that the initial specification is too ambiguous and determine what they do about it.

If they gave that answer and then said "which is why the specification is weak" then great! If they gave that answer and called it done... well... not so good.

Quality Assurance (QA) engineer. I do QA Tools specifically but still need to be on top of most QA stuff. Other QA engineers exist in the company for in depth QA.

My initial question starts with: "build a function that takes a string and produces an integer". About 30% of candidates fail to get anywhere. 50% produce an incorrect implementation. 20% produce an implementation that is mostly correct. 9% produce an implementation that is mostly correct and well tested. 1% actually produce a complete and correct response. Which, as of right now, translates to exactly 1 candidate in 2 years. Who was rejected due to culture fit. A complete and correct answer is not required to pass the screen. ;-)

The reason this question is so effective is due to how the question is asked and the details of the solution. There is a lot more than just the initial problem statement. The full script assess: the candidates ability to determine requirements; ability to produce complete set of unit tests; ability to handle the boundary conditions.

There is a sharp division that occurs between QA engineers and non-QA engineers on the requirements gathering. All but 1 non-QA engineer I've interviewed assumed they had all the requirements before writing code. A clever solution is almost useless if it solves the wrong problem. Sometimes even worse than useless if the code adds a maintenance cost for no value.

Covering all the critical cases in testing is the next part that most candidates fail at. Even if the requirements they assumed are correct, none of the non-QA engineers have succeeded in writing a complete and good set of tests. Many add too many tests.

After those two the other parts are just seeing how close they can get to building the correct implementation. The candidates typically pass if they do well in all parts; perfection is not required. Still, I think it's interesting to note that almost nobody has ever written a 100% correct solution. Even if they are given all the requirements in detail.

This question does not asses algorithm design ability. At all really. Well, I suppose there was somebody who immediately proposed "binary search!" and really wanted to stick with that idea. No clue why...