iyulaev

Thanks for answering the question :)

You know, sometimes, I feel like that's a personality trait that's often under-rated.

Are you a bad writer if you don't write on your own time?

Are you a bad carpenter if you don't craft on your own time?

No. You can be an excellent, professional .+\. But it's very rare to see someone at the top of their field who isn't passionate about their vocation. I haven't heard of many rockstars who started playing music for the money.

[1] http://www.techrepublic.com/blog/tech-news/micro-usb-to-be-a...

The correct reply might be something like "cannot understand or reproduce, can you explain more clearly?" along with some bug report guidelines.

Building a working prototype that can beam ~1W (or even 100mW) a few feet would be very interesting and would do a lot to lessen my skepticism.

Well he tried twice, and they told him it wasn't a bug both times. After that, what's wrong with selling "not an exploit" to the highest bidder?

Absolutely true. The reason I point this out is that the cost of a jerk goes up as the size of the team he/she is on increases. If you are a 3-man start-up, hiring a superstar coder who's sometimes a PITA can be worthwhile - have them work on some part of the project where they drive the whole thing. At 20 people, that person can become a huge liability - they will misdirect the team, demoralize other engineers, and eventually cause your best people to leave.

My examples illustrate how you might identify people with an uncontrollable mean streak during the candidate process, and hence filter them out. If you're building a scalable organization you must start with founders that aren't jerks and weed these people out of the candidate pool. If you start the company off with such a person, well, either live with it or find a new company.

Hiring for prior experience - the author emphasizes this, and based on my experience this should be de-weighted. The issue is that as soon as you start to define an area of experience, your hiring pool shrinks dramatically. Consequently you are more likely to pick a less powerful engineer. Another, bigger downside here is that companies are terrible at figuring out what they really need. Consequently you've hired someone who can do A and B but one month in you realize that the thing you were missing is really C. A less powerful engineer will have a harder time transitioning over to doing C work, and you'll be worse off. Moreover they might be upset - they came in with the expectation of doing A & B, and they're sitting here doing something unrelated instead. Can't count the number of times I've seen this happen, to both the employee's and company's detriment.

The thing that this article misses is how to avoid hiring jerks. Terrible employees can be a net negative to a company. Jerks, particularly those in senior positions, are the thermonuclear version of terrible employees. They can demotivate and destroy the productivity of entire teams and cause your best engineers to rage-quit. The best interviewing tactic I've seen to weed out these people is watching how someone behaves when you "play dumb" in an interview. See if they're happy to explain something to you, or if they get impatient with your lack of knowledge. A related trick is challenging them on something that is obviously correct - see if they carefully prove why their answer is correct, or become antagonistic. Really smart people are good, but much more effective are those that can help bring everyone else up to their level.

Modern SoCs demand thousands of pages to cover all available features and possible applications, and putting together that documentation in a self-consistent way is a challenge. Some vendors have decided that supporting low-revenue clients is not worth the cost of putting together said general-purpose documentation and providing support to each and every buyer. They'd rather not sell you the product in the first place than sell you something and stiff you on documentation & support, which is a reasonable position.

Often when you're a low-quantity company you deal with low-quantity vendors who are willing to support you. When you move to high volume you might prefer to keep working with the chips you know. But when your operations guy comes back to you and says that the Big Co (who wouldn't talk to you in the past) can sell you chips for $5 less, that's $50M you just saved (given your 10M unit quantity). So you switch. In this example you have two different vendors: high cost / high support, low cost / "exclusive" support. Both have markets, just different ones.

TI is an example of a vendor that is very hobbyist / small quantity friendly. Even that wasn't enough to save them - they've pulled out of the phone SoC business.

On a long enough time scale, everyone will get "Pfizered." What makes you think this is likely to happen soon? Genuinely curious, as a practicing (sort of) EE.

Vendors suck (some more than others) and it's not Google's fault that they can't convince the vendor to open source their device drivers. This sort of thing is extremely common in the embedded world and when you're making a device to a price point often times you have to put up with this sort of nonsense because only one vendor makes a chip with your feature set at a given price point.

There are/were plenty of PowerPC-based microcontrollers. Freescale, among other vendors, had a few families. It's all ARM now though as far as I know.

So why did you write IBM, instead of Ibm? Or ARM, instead of Arm?

Is fb, for example, a more appropriate venue, selling likes and all that? They explicitly allow sponsored posts that appear to have been made by friends. I think the marketing person figured that stack overflow was similar to fb for nerds. Whoops.