Don't have numbers, but I'm guessing performance numbers (0-60 time, top speed) have increased over the same period as well. So I'm not sure it's fair to conclude that all the extra horsepower is solely to keep performance metrics constant while increasing body weight.
Taxes are always distortionary. You're always disincentivizing something. Do you want it to be something we want more of (like employment, or earned income, or corporate profits, or capital gains) or something we want less of (like gasoline consumption).
Gas taxes hit poor people with old vehicles much harder than affluent people with large vehicles. You're not thinking like an economist, you're thinking like a politician. As was Knittel.
So use the revenue from the new gasoline tax (which is regressive) to reduce some other tax which is also regressive (like the payroll tax) by an equal amount. There will still be some "losers" (for instance retirees and those on disability who pay no payroll tax) but the overall effect on the lowest income brackets would be neutral.
Revenues could be used to offset other taxes that also raise the cost of goods and/or decrease consumers' purchasing power. Such as the payroll tax (both employer and employee portion). Last time I looked at the numbers, taxes that roughly doubled the cost of gasoline and electricity would allow the U.S. to get rid of the payroll tax (which supplies ~$800 billion/year in revenue) altogether.
True. I guess the benefit I see is that putting someone in a room for 3 hours (or whatever) isn't much of a time investment on your part. The candidate spends three hours working on the task, but you don't have to be involved. And you can review his code asynchronously, possibly after he's left the premises, and bring him back for a second (fairly short) day to discuss his implementation if it isn't complete crap, do the "culture fit" checks, etc.
I can see that. But I also feel like some folks panic when asked to write code "live" in an interview setting and their brains just lock up. The same person who could write a FizzBuzz solution that is both clean and correct if left alone by himself in a room w/ a keyboard and IDE might freeze up and make stupid mistakes on a whiteboard. Though, I guess one could argue that such a person is rare enough that we can accept his being eliminated from consideration as "collateral damage" in the effort to create a filtering process that minimizes wasted time on the interviewer's part.
As someone who's been on a few interviews and had to interview people, I really dislike any test that puts the candidate "on the spot" in a high pressure environment (such as a live interview). Unless, of course, that's going to be a feature of the role you're hiring him or her for. That's not usually the case for software developers. I would extend this past brain teasers to also include "sketch out some code on the whiteboard" type tasks, unless the code being sketched is fairly simple. I agree with the 37signals guy that looking at actual code is way more useful than whiteboard and brain teaser type tasks, not least of which because some candidates try to "game" the brain teasers and memorize the common ones before the interview.
If I had my way, I would cook up a programming tasks that exercises a few "tricky" aspects of coding. Maybe some concurrency, some processing of arbitrary input, etc. I'd plunk the candidate down in a room, by himself, with a computer, network connection and whatever IDE I would expect him to use in the role. If there is no expectation with respect to IDE then provide all the common options and let him use the one he prefers. Express the problem in written form, albeit with some ambiguity that requires him to ask for clarification (or make a judgment call). Structure the task so that it's easy to get it working correctly for typical inputs, but tricky to get it working correctly for pathological inputs. Possibly choose a task that can be partially solved by using common off-the-shelf libraries, and see if he is savvy enough to use them. Stipulate in the problem description that it's okay to make use of free software as needed. Grade him as follows:
1. Correctness. Does his solution work correctly for the common cases? Does it work correctly for the pathological cases?
2. Completeness. Did he ask for clarification on areas where the problem description was ambiguous? If not, was he at least aware of the ambiguity and able to defend the judgment call he made?
3. Did he attempt to reinvent the wheel, or did he have the breadth of knowledge to make use of existing libraries *where it made sense*? I wouldn't count it as a huge strike against someone if they were ignorant of the fact that a given library existed, but able to reproduce the same functionality via custom code.
4. Is the code "clean"?
5. Is his code performant?
6. Can he dialogue intelligently about his solution, why he chose to do X over Y, etc.
Another task I might include in interviews is debugging. Come up with some toy applications that have contain fairly subtle (but not hard to correct) bugs. Have the candidate find and correct them.
Nope. Care to highlight where I'm wrong? I understand the gist of the article, which is that with an 8 vote difference, given the margin of error, on cannot say with any confidence that one or the other candidate "won". That said, all else being equal, if we could flip a magic switch and eliminate all error, Romney is more likely to have been received more votes than Santorum.
Even recognizing the certainty of there being some error, that Romney has 8 more votes means he is more likely to have been the true winner if that error were eliminated. Assuming the error is equally likely to benefit Romney as it is to benefit Santorum. That suggests something other than "a tie" to me. The most accurate thing might be to say, "We don't know whether Romney or Santorum won, but it's slightly more likely that Romney did."
Umm. If the market for Android developers is as tight as you describe (and I'm not saying it isn't) then wouldn't that validate what I said about the relative ease (or lack thereof) of him getting a job with Android experience compared to if he only had "general Java experience"? That was my point.
Not sure I agree. If he can demonstrate that he's smart, has the requisite basics covered via his education, can show that he's competent with some current skills, and is willing to accept pay equivalent to what someone might learn who's just coming out of college, then I don't see the problem. Especially if he wants to get into a "niche" like Android development.
What idiot thinks that "voluntary self-policing" works in any for-profit business?
It tends to "work" when there is the threat of regulation. Basically "regulate yourselves or we'll do it for you". Of course, the threat has to be credible.
On the other hand, public discomfort with antibiotics has, in the last few years, created a market (albeit small) for organic meat. While it isn't available everywhere, many people do have a choice to "opt out" regardless of the FDA's lack of action.
Both of them seem douchey, but the marketing guy is douchey and stupid and unprofessional for ever letting it get as far as it did. To be clear: I'm fine with Dave shaming this company by publishing its abuse of customers as widely as possible. I'm less okay with Dave acting like a 12-year-old while doing so.
Sure. But if you have limited human computing power, then using the compute as a heuristic to select the set of areas to human-inspect is probably better than selecting areas at random.
This seems like a job for computers. They don't have to recognize what an image is; they just have to recognize that it's "sufficiently anomalous to what is typical of the lunar landscape". If nothing else, use image recognition to flag "interesting" areas for further inspection by a human being.
I'm not an economist, but the matter of "who's paying whom" seems significant when it comes to manufacturing jobs. Usually the money is flowing in from the outside. On the aggregate, then, that would seem to enrich the country doing the manufacturing. Obviously if you could train your entire populace to do something more lucrative (say, design) and then have your trading partners outsource that work to your country then you'd rake in even more money. However, one wonders whether that's feasible given the inherent variance in human ability. There will almost always be some portion of the population which, for whatever reason (lack of inherent ability, lack of education, poor choices, etc.) are unable to do much beyond manufacturing or other unskilled labor. For this group to be actively engaged in manufacturing seems like a "win" compared to, say, having them all be unemployed or performing some unskilled task (other than manufacturing) where the compensation comes from domestic sources (e.g. working as a maid).
When it comes to the U.S., I've always felt like it should endeavor to compete at all levels of the labor spectrum. Currently it is not competitive in sectors like manufacturing because the cost of unskilled labor is simply too high relative to countries like China. That's something that could potentially be addressed via government intervention (possibly in the form of wage subsidies). As it stands, the U.S. has basically "punted" on manufacturing. It seeks to employ its labor solely in white collar pursuits and servicing its own (very high) domestic consumption. Instead of assembling electronics, the unskilled in the United States flip burgers, work in retail, clean houses, work as nannies, etc. Basically they meet the demand of a highly consumer-driven economy. When that consumption dips, however, such as happened during the recent recession, you see massive job losses (and these concentrated among those with lower incomes).
I was there from 1999-2004. If I recall, they would give you small cost of living raises each year. Maybe 1% base pay. As you neared the top end of the pay range for your "band" these might stop coming, but by the time you got to that point you were expected to be ready for promotion to a new "band" anyway. If you got that point and weren't deemed ready for promotion then you were doing something wrong. Once you were promoted to the new band you'd be near the middle of its pay range and could start collecting the small cost-of-living bumps again.
Don't have numbers, but I'm guessing performance numbers (0-60 time, top speed) have increased over the same period as well. So I'm not sure it's fair to conclude that all the extra horsepower is solely to keep performance metrics constant while increasing body weight.
Taxes are always distortionary. You're always disincentivizing something. Do you want it to be something we want more of (like employment, or earned income, or corporate profits, or capital gains) or something we want less of (like gasoline consumption).
So use the revenue from the new gasoline tax (which is regressive) to reduce some other tax which is also regressive (like the payroll tax) by an equal amount. There will still be some "losers" (for instance retirees and those on disability who pay no payroll tax) but the overall effect on the lowest income brackets would be neutral.
Revenues could be used to offset other taxes that also raise the cost of goods and/or decrease consumers' purchasing power. Such as the payroll tax (both employer and employee portion). Last time I looked at the numbers, taxes that roughly doubled the cost of gasoline and electricity would allow the U.S. to get rid of the payroll tax (which supplies ~$800 billion/year in revenue) altogether.
True. I guess the benefit I see is that putting someone in a room for 3 hours (or whatever) isn't much of a time investment on your part. The candidate spends three hours working on the task, but you don't have to be involved. And you can review his code asynchronously, possibly after he's left the premises, and bring him back for a second (fairly short) day to discuss his implementation if it isn't complete crap, do the "culture fit" checks, etc.
I can see that. But I also feel like some folks panic when asked to write code "live" in an interview setting and their brains just lock up. The same person who could write a FizzBuzz solution that is both clean and correct if left alone by himself in a room w/ a keyboard and IDE might freeze up and make stupid mistakes on a whiteboard. Though, I guess one could argue that such a person is rare enough that we can accept his being eliminated from consideration as "collateral damage" in the effort to create a filtering process that minimizes wasted time on the interviewer's part.
As someone who's been on a few interviews and had to interview people, I really dislike any test that puts the candidate "on the spot" in a high pressure environment (such as a live interview). Unless, of course, that's going to be a feature of the role you're hiring him or her for. That's not usually the case for software developers. I would extend this past brain teasers to also include "sketch out some code on the whiteboard" type tasks, unless the code being sketched is fairly simple. I agree with the 37signals guy that looking at actual code is way more useful than whiteboard and brain teaser type tasks, not least of which because some candidates try to "game" the brain teasers and memorize the common ones before the interview.
If I had my way, I would cook up a programming tasks that exercises a few "tricky" aspects of coding. Maybe some concurrency, some processing of arbitrary input, etc. I'd plunk the candidate down in a room, by himself, with a computer, network connection and whatever IDE I would expect him to use in the role. If there is no expectation with respect to IDE then provide all the common options and let him use the one he prefers. Express the problem in written form, albeit with some ambiguity that requires him to ask for clarification (or make a judgment call). Structure the task so that it's easy to get it working correctly for typical inputs, but tricky to get it working correctly for pathological inputs. Possibly choose a task that can be partially solved by using common off-the-shelf libraries, and see if he is savvy enough to use them. Stipulate in the problem description that it's okay to make use of free software as needed. Grade him as follows:
1. Correctness. Does his solution work correctly for the common cases? Does it work correctly for the pathological cases?
2. Completeness. Did he ask for clarification on areas where the problem description was ambiguous? If not, was he at least aware of the ambiguity and able to defend the judgment call he made?
3. Did he attempt to reinvent the wheel, or did he have the breadth of knowledge to make use of existing libraries *where it made sense*? I wouldn't count it as a huge strike against someone if they were ignorant of the fact that a given library existed, but able to reproduce the same functionality via custom code.
4. Is the code "clean"?
5. Is his code performant?
6. Can he dialogue intelligently about his solution, why he chose to do X over Y, etc.
Another task I might include in interviews is debugging. Come up with some toy applications that have contain fairly subtle (but not hard to correct) bugs. Have the candidate find and correct them.
+1 Vint Cerf (Insightful).
Nope. Care to highlight where I'm wrong? I understand the gist of the article, which is that with an 8 vote difference, given the margin of error, on cannot say with any confidence that one or the other candidate "won". That said, all else being equal, if we could flip a magic switch and eliminate all error, Romney is more likely to have been received more votes than Santorum.
Even recognizing the certainty of there being some error, that Romney has 8 more votes means he is more likely to have been the true winner if that error were eliminated. Assuming the error is equally likely to benefit Romney as it is to benefit Santorum. That suggests something other than "a tie" to me. The most accurate thing might be to say, "We don't know whether Romney or Santorum won, but it's slightly more likely that Romney did."
1. It does everything I need.
2. I'm using fairly old and underpowered hardware.
3. I'm not willing to pay for Win7.
Umm. If the market for Android developers is as tight as you describe (and I'm not saying it isn't) then wouldn't that validate what I said about the relative ease (or lack thereof) of him getting a job with Android experience compared to if he only had "general Java experience"? That was my point.
What about...buggy whips? To the extent there's always demand for "making and fixing" there is also almost always demand for "selling".
Not sure I agree. If he can demonstrate that he's smart, has the requisite basics covered via his education, can show that he's competent with some current skills, and is willing to accept pay equivalent to what someone might learn who's just coming out of college, then I don't see the problem. Especially if he wants to get into a "niche" like Android development.
Aren't video game and movie ratings industry-imposed?
Did you read what I wrote? "I'm fine with Dave shaming this company by publishing its abuse of customers as widely as possible".
It tends to "work" when there is the threat of regulation. Basically "regulate yourselves or we'll do it for you". Of course, the threat has to be credible.
On the other hand, public discomfort with antibiotics has, in the last few years, created a market (albeit small) for organic meat. While it isn't available everywhere, many people do have a choice to "opt out" regardless of the FDA's lack of action.
Both of them seem douchey, but the marketing guy is douchey and stupid and unprofessional for ever letting it get as far as it did. To be clear: I'm fine with Dave shaming this company by publishing its abuse of customers as widely as possible. I'm less okay with Dave acting like a 12-year-old while doing so.
Sure. But if you have limited human computing power, then using the compute as a heuristic to select the set of areas to human-inspect is probably better than selecting areas at random.
In my book this puts Dave in the same douchey category as the Ocean Marketing guy.
This seems like a job for computers. They don't have to recognize what an image is; they just have to recognize that it's "sufficiently anomalous to what is typical of the lunar landscape". If nothing else, use image recognition to flag "interesting" areas for further inspection by a human being.
I'm not an economist, but the matter of "who's paying whom" seems significant when it comes to manufacturing jobs. Usually the money is flowing in from the outside. On the aggregate, then, that would seem to enrich the country doing the manufacturing. Obviously if you could train your entire populace to do something more lucrative (say, design) and then have your trading partners outsource that work to your country then you'd rake in even more money. However, one wonders whether that's feasible given the inherent variance in human ability. There will almost always be some portion of the population which, for whatever reason (lack of inherent ability, lack of education, poor choices, etc.) are unable to do much beyond manufacturing or other unskilled labor. For this group to be actively engaged in manufacturing seems like a "win" compared to, say, having them all be unemployed or performing some unskilled task (other than manufacturing) where the compensation comes from domestic sources (e.g. working as a maid).
When it comes to the U.S., I've always felt like it should endeavor to compete at all levels of the labor spectrum. Currently it is not competitive in sectors like manufacturing because the cost of unskilled labor is simply too high relative to countries like China. That's something that could potentially be addressed via government intervention (possibly in the form of wage subsidies). As it stands, the U.S. has basically "punted" on manufacturing. It seeks to employ its labor solely in white collar pursuits and servicing its own (very high) domestic consumption. Instead of assembling electronics, the unskilled in the United States flip burgers, work in retail, clean houses, work as nannies, etc. Basically they meet the demand of a highly consumer-driven economy. When that consumption dips, however, such as happened during the recent recession, you see massive job losses (and these concentrated among those with lower incomes).
Happiness vs. fulfillment. There is a lot more irritation and annoyance in my life now that I have a kid, but I still view it as "worth it".
I was there from 1999-2004. If I recall, they would give you small cost of living raises each year. Maybe 1% base pay. As you neared the top end of the pay range for your "band" these might stop coming, but by the time you got to that point you were expected to be ready for promotion to a new "band" anyway. If you got that point and weren't deemed ready for promotion then you were doing something wrong. Once you were promoted to the new band you'd be near the middle of its pay range and could start collecting the small cost-of-living bumps again.