army

Not sure why the other comments are so negative. I don't see how you can dispute that having a large part of your net worth in a single stock leaves you vulnerable if anything happens to it. There's also the fact that your fortunes are still very closely tied to your company's through unvested stock, bonuses, and employment. Regardless of how positive you are on your company, you're probably already sufficiently invested in it. I can't imagine any combination of individual situation and risk tolerance that would make holding a large amount of a single publicly-traded stock an optimal investment strategy.

"This equity is provided in order to align incentives."

That leaves out the other - probably more significant - reason - it's provided because it can increase the (real or perceived) value of compensation packages without spending scarce cash.

"Lack of equity might cause an employee to feel left out and/or poorly compensated." ... uhh... or they might not have joined the company in the first place?

The original version of the "10x" idea didn't require the productivity distribution to be bimodal - it could be a bell curve or skewed bell curve with high variance. I think it's contextual as well - if you're working on a project that's just at the edge of your present abilities, your productivity is going to be pretty marginal compared to someone who's done it before and has strong aptitude at it.

I think it's silly to simply sort programmers into two buckets.

It does make a lot of sense though to try to attract and retain good programmers though - having a programmer who's at the 75th percentile of productivity instead of the 50th percentile is going to give you a big boost in productivity if productivity is high variance. It also makes sense to try to match programmers to projects that they have good aptitude and motivation for.

You could probably conspire with another party to sell your shares back and forth at +10% every day. That way the official market price of your shares would eventually get to the point where you could share them at their true value.

Your analysis of the arbitrage is faulty - if there's a cost associated with time-shifting energy, then the gap will only narrow to the extent that it's still economically justifiable for people to invest the money in time-shifting energy. What you're describing (no peak/non-peak difference plus people still buying batteries to time-shift energy) isn't a steady state - why would people continue to buy the batteries when they're going to lose money on the deal? You'd actually expect the gap to be the price difference per watt plus some additional amount for the capital and inconvenience.

Also, if there's significant arbitrage, it will also reduce peak prices - because of reduced demand, and also because of reduced costs of expensive additional capacity. I.e. it can reduce energy costs for people who don't use it.

In special cases multiple string concatenations can be optimized into using a StringBuilder calls. Not in the general case.

Do you know for sure that RethinkDB can't work out what columns are being filtered by a function? In the examples it would certainly be possible with some analysis.

Right, I'd be a lot more forgiving of MongoDB if they had been bringing the product to market 10-15 years earlier.

'When you query with ReQL you tack on functions and “compose” your data, with SQL you tell the query engine the steps necessary (aka prescribe) to return your data:'

... what? ReQL and SQL are both declarative query languages: I don't really see the author is getting at. Is there an implication that SQL isn't declarative?

The only real difference is that the API is based around chaining function calls rather than expressing what is needed as a string - there are many SQL query builder APIs that will let you build SQL queries by chaining together function calls.

Hey, he's too busy working 300 hours a week to worry about things like "averages" and "mathematics".

Uh, it's completely acceptable to "discriminate" against people based on factors that relate to their ability to succeed in the job. I don't think it's controversial that people's social skills or style of social interaction has a bearing on their job performance. You can argue to what extent and so on, but it's bizarre to think that it's not relevant.

I've definitely heard the negatively correlated variant of the meme. I'm not sure it's the predominant one or always explicitly expressed, but it's out there.

They can't selectively block parts of github when it's going over HTTPS. All they see is an encrypted connection from inside China to github.com.

Great, another person who doesn't understand marginal tax rates.

If you're learning, it's really important to have the skill of narrowing down what it is you don't know and formulating a clear question about it.

I've seen all sorts of failure modes with that:

* People asking overly broad questions, e.g. if they are having trouble using, say, a dictionary class: "How do dictionaries work?" rather than "I'm trying to do x with a dictionary and I can't figure out how to make it work - I tried the put() method but it doesn't do what I thought." This makes it very difficult to dig into what's actually being asked and provide a relevant answer.

* People not admitting what they don't know. E.g. maybe they just don't have a clue what a dictionary is, yet won't admit it.

* People making a lot of assumptions and not articulating them. This tends to manifest as a really specific question that doesn't make sense. E.g. "I tried to build a spellchecker and dictionary is not returning the right thing." Then it turns out they assumed dictionary was prepopulated with the English language. This is even worse if the person can't/won't explain their thought process when prompted.

* Not reading any of the docs. I ran programming tutorials at one point and it was remarkable how many questions would have been answered by the introductory paragraphs of the tutorial if they'd read them instead of skipping it then spending 10 minutes struggling with a problem that didn't make sense to them.

* Unwillingness to talk through things systematically, e.g. explaining code line-by-line. It's surprising how often people will ask for help, then lose patience with you once you want them to spend any amount of time explaining things. This is enormously effective - half the time they realize their mistake on their own.

Yeah I have a hard time telling what's definitely going on from the OP's description.

I personally find the most difficult people to work with are the people who have trouble filling the gaps in their knowledge themselves AND are evasive when they don't know something.

It means he doesn't have the commitments that come with being a full-time faculty member but that he can teach classes.

Even if Toyota went away, it wouldn't be so hard to just go and buy a Mazda or whatever and drive that around.

My bias is better than your bias ;)

Um, you can practice for anything that involves communication or demonstrating your skills. Its just arrogant to think that you can go into an interview cold and rely on the interviewer to tease out your positive qualities. If they're a good interviewer they'll do their best to do that but its also on the interviewee to convince the interviewer that they're a good fit for the job.

I wouldn't present on a technical topic without preparation, because I'm not going to do a good job of explaining it or communicating the ideas - I'd be wasting the audiences time. Same with interviews - you need to be prepared to explain your work and put your experience in as favorable a light as possible.

You are wrong about the Dunning-Kruger effect - there is not a negative correlation between perceived and actual ability, just a weaker positive correlation than you might expect. There's plenty of debate about the causes of the effect in the original Dunning-Kruger paper. Moreover, if you look at the actual paper (rather than exaggerated retellings of it), you will see that perceived ability is actually positively correlated with actual ability: most people tend to think that they're above-average - the bottom quartile tends to think that they're in to 50th to 60th percentiles, while more able people tend to think they're in the 70th to 80th percentiles.

See Figure 1 at: http://psycnet.apa.org/journals/psp/77/6/1121.html

Also, $100,000-200,000 a year is the range you'd make at those companies and have more job security and income consistency, so I'm not sure what your point is.

It sounds like #3 was a good thing to happen - you learned a lot.

Nice feature or cunning conspiracy you be the judge.

If those numbers about grad students are right, that's pretty weird - it sounds like they're being overly picky about who they admit and only admitting the people who were accepted at other, more prestigious, places.

Edit: I've seen exactly the same thing happen with faculty hiring, it's a bit stranger that it would happen with grad students since it's easier to move the bar year-to-year there.

This made a lot more sense when I saw who the author was...

I think the lack of highlighting and indentation support in some of those tools is a pain and adds unnecessary mental overhead.

Whether a candidate can reason about the correctness of their code without using a debugger is a useful data point though. Both in a more abstract way and by manually tracing at least part of the program instead of stepping through it with a debugger. If you struggle to manually trace code in your favorite language, that raises some questions in my mind.

Those are for the more senior engineer grades at Google - the average engineer isn't making that much.

That was a really long-winded way of saying "I don't like tech people".

Heroin still requires growing poppies. Aspirin can be be synthesized.