The point was that it causes that coefficient to be rather low if some specific condition is needed at some very specific time in the planet's life, rather than generally being something that can happen at any moment.
With life being at least 83% as old as the planet according to this result, it makes me begin to wonder "has life been on earth ever since it formed?"
That's clearly not a question we're going to answer today, but it might have drastic impacts on the drake equation if there was some requirement for life that has to happen as the planet forms.
1.) Who cares if someone knows bubble sort (or insertion or quick or merge or whatever you please). Particular algorithms are well defined tools that good programmers don't re-invent. Much better to determine if that person knows the right tool to use for a particular job. In other words, a question like "what type of sort would you use with sets of data that are nearly, but not completely in the desired order" or better yet "what different types of sorting are there, and why would you choose to use one over the other"? To put in in other terms, If you were interviewing a plumber, would you ask them how to make a pipe wrench or would you ask them what type of wrench to use to tighten a loose fitting?
That's rather the point - I'm not trying to hire a programmer - I'm trying to hire a software engineer.
If I were trying to hire a programmer, sure, your plumbing type questions make sense. But since I'm trying to hire someone who can do the software equivalent of designing pipe wrenches, I'd better ask them questions about that.
If the interviewer is asking you trivia that they've got memorized, they're not going to be impressed at you flailing around trying to work it out from scratch.
Yup... that's why a good interview involves doing a problem on a whiteboard, not sitting there asking trivia.
No, that's not an illustration of the problem at all, that's an illustration of how to do white board coding correctly.
They've found someone who can solve a problem, not someone who has crammed the textbook on a particular language. That's far more valuable. That is, they've found someone who knows how to software engineer, rather than someone who only knows how to program.
No, not at all - I want them to be able to look at an algorithm, and say "given the user doing x, what kind of affect is that going to have on the runtime of the thing you wrote on the board".
That's not memorisation at all, that's actually understanding how to assess performance of algorithms.
You're right - the fucking job is writing code to accomplish the business' goals in an efficient manner. The business' goals in this case, are to produce tools for users that work reliably, fast, consume little memory, consume little power, etc. Writing good code absolutely is a requirement to meeting the business' goals. If you don't want to write that kind of code... well, that's why I'm rejecting you in an interview. That's why the business trust's my (and my colleagues) take on who's a good hire - because they trust that we understand the kinds of qualities needed to do the job well.
Maybe I've been lucky. I've never ever ever been to one of these white board coding interviews where someone has not made it clear that what they're after is seeing how you work, not perfect code written on a whiteboard.
Every single day at my work I need to come up with new algorithms. I expect other people we hire to be able to do the same.
Bubble sort is a useless question, exactly because it can be done by rote so easily, but I absolutely expect you to be able to come up with an algorithm for a slightly obscure problem, and write up some details of it. Why? Because that's the fucking job - coming up with the best algorithm to do something.
Honestly, I see all of the complaints above as whines by people who don't understand what a whiteboard interview is.
* If I ask you to write a sorting algorithm on a white board, I am not asking you to by rote copy out a bubble sort - in fact, if you do it by rote, I'm likely to go "oh, well that was uninformative, he didn't solve any problems, he just copied something out" (and that's why I'm unlikely to ask you to sort things, but instead, something more obscure) * If you "don't do riddles" then I actively don't want to hire you - the entire purpose of a software engineer (i.e. not a flunky programmer) is to do riddles, all day, every day. If you don't want to do that, you don't want to do the job I'm interviewing you for. * If you need to look up how to find the length of a string in python, I don't give any shits. I don't care if you write x.length(), x.size(), x.count, length(x), I'm asking for you to solve a problem, not get the code in the exact shape it'll compile in. * If you don't know what NP complete means, I don't care. Of course I'm going to probe a bit into whether you can analyse the performance of your code - that's absolutely part of the job, and something I need to know you can do. But not knowing what one term means is not going to not get you hired.
Long story short - don't assume that everything in a whiteboard interview should be taken literally. I don't want to find out if you can write exact algorithm x perfectly so that it will compile. I want to know if you can solve a problem, and can talk rationally about your solution, its trade offs, its performance, etc.
160k doesn't take home 10k a month. It takes home about 6.5k a month. That said, yes, he still has 3.5k a month for other expenses, and it's his own stupid fault for choosing to live in SF, rather than the south bay, where a 2 bed apartment can be had for 2k a month.
To take home 10k a month you need to earn about 220k a year before tax.
The single payer they're typically comparing to is the NHS in the UK. While other insurers exist, they're such a small share of the market, that effectively the NHS holds a monopoly on paying for goods sold by drugs companies and/or hospitals.
Once you have a monopoly — such as "Single Payer" education, or healthcare, or Internet-Service provision — the price goes up and the quality goes down.
Actually, no - you've got your monopoly on the wrong side with single payer healthcare.
Companies that are monopolies are allowed to arbitrarily increase their prices because they are the single seller.
Single payer health care involves there only being one single insurance company buying goods from the drugs companies, doctors, and hospitals, allowing them to drive the price *down*, not up. That's why healthcare is so much cheaper in Europe than the US.
The fact that that's repeatedly been the outcome of unregulated economies? Either one, or a very small number of people establish a controlling position, and abuse it to shut everyone else out.
The reason the engine revs constantly is because the Prius has a clever mechanism using two electric motors and a differential that keeps the gasoline engine reving at exactly its optimal RPM.
I think you're just ignoring the breakthroughs that have been happening.
It's only about 15 years since a laptop was 1.5" thick, weighed 5lb, and had an amazing 2 hour battery life. In only a decade and a half the amount of energy that's been packed into a laptop battery has increased enormously.
This is also hugely visible when you look at power tools. I cordless power drill from 15ish years ago would almost certainly us NiCd batteries, with a life of only an hour or two. Modern power drills will last a full day or more with a battery pack that's substantially smaller, and that charges in a far shorter amount of time.
That's (roughly) the way it works today, except it's they'll be paid 'more' than the average salary for the position they're in.
The problem isn't the 50% bit, it's the 'the position they're in' bit. The contracting firms like Infosys fill positions that are generic contractor roles - *not* highly skilled positions, which command low salaries. They then contract them out to other companies to do highly skilled jobs, at their low skilled salary.
Companies like Apple, MS and Amazon (which are not in those top 10 visa getters) hire people directly into the highly skilled roles, and are more than willing to pay extremely high salaries for them.
Changing job with an H1B is trivially easy. Changing job while in the process of getting a green card, will reset your application and set you back years.
That was rather my point in a somewhat underhanded way - the article moans about "why don't browsers do this", when the reason is "because everyone writing it found that it was a useless feature for one reason or another". It's not like guys writing browsers aren't thinking about how to deal with this well, it's just not a problem that they can solve magically themselves.
A sleeping bag on a hard floor does not get you proper sleep. A break from thinking about work, a meal with your wife/girlfriend, and your own bed gets you proper sleep.
Slashdot Mirror
The point was that it causes that coefficient to be rather low if some specific condition is needed at some very specific time in the planet's life, rather than generally being something that can happen at any moment.
With life being at least 83% as old as the planet according to this result, it makes me begin to wonder "has life been on earth ever since it formed?"
That's clearly not a question we're going to answer today, but it might have drastic impacts on the drake equation if there was some requirement for life that has to happen as the planet forms.
1.) Who cares if someone knows bubble sort (or insertion or quick or merge or whatever you please). Particular algorithms are well defined tools that good programmers don't re-invent. Much better to determine if that person knows the right tool to use for a particular job. In other words, a question like "what type of sort would you use with sets of data that are nearly, but not completely in the desired order" or better yet "what different types of sorting are there, and why would you choose to use one over the other"? To put in in other terms, If you were interviewing a plumber, would you ask them how to make a pipe wrench or would you ask them what type of wrench to use to tighten a loose fitting?
That's rather the point - I'm not trying to hire a programmer - I'm trying to hire a software engineer.
If I were trying to hire a programmer, sure, your plumbing type questions make sense. But since I'm trying to hire someone who can do the software equivalent of designing pipe wrenches, I'd better ask them questions about that.
If the interviewer is asking you trivia that they've got memorized, they're not going to be impressed at you flailing around trying to work it out from scratch.
Yup... that's why a good interview involves doing a problem on a whiteboard, not sitting there asking trivia.
No, that's not an illustration of the problem at all, that's an illustration of how to do white board coding correctly.
They've found someone who can solve a problem, not someone who has crammed the textbook on a particular language. That's far more valuable. That is, they've found someone who knows how to software engineer, rather than someone who only knows how to program.
No, not at all - I want them to be able to look at an algorithm, and say "given the user doing x, what kind of affect is that going to have on the runtime of the thing you wrote on the board".
That's not memorisation at all, that's actually understanding how to assess performance of algorithms.
You're right - the fucking job is writing code to accomplish the business' goals in an efficient manner. The business' goals in this case, are to produce tools for users that work reliably, fast, consume little memory, consume little power, etc. Writing good code absolutely is a requirement to meeting the business' goals. If you don't want to write that kind of code... well, that's why I'm rejecting you in an interview. That's why the business trust's my (and my colleagues) take on who's a good hire - because they trust that we understand the kinds of qualities needed to do the job well.
Maybe I've been lucky. I've never ever ever been to one of these white board coding interviews where someone has not made it clear that what they're after is seeing how you work, not perfect code written on a whiteboard.
Every single day at my work I need to come up with new algorithms. I expect other people we hire to be able to do the same.
Bubble sort is a useless question, exactly because it can be done by rote so easily, but I absolutely expect you to be able to come up with an algorithm for a slightly obscure problem, and write up some details of it. Why? Because that's the fucking job - coming up with the best algorithm to do something.
Honestly, I see all of the complaints above as whines by people who don't understand what a whiteboard interview is.
* If I ask you to write a sorting algorithm on a white board, I am not asking you to by rote copy out a bubble sort - in fact, if you do it by rote, I'm likely to go "oh, well that was uninformative, he didn't solve any problems, he just copied something out" (and that's why I'm unlikely to ask you to sort things, but instead, something more obscure)
* If you "don't do riddles" then I actively don't want to hire you - the entire purpose of a software engineer (i.e. not a flunky programmer) is to do riddles, all day, every day. If you don't want to do that, you don't want to do the job I'm interviewing you for.
* If you need to look up how to find the length of a string in python, I don't give any shits. I don't care if you write x.length(), x.size(), x.count, length(x), I'm asking for you to solve a problem, not get the code in the exact shape it'll compile in.
* If you don't know what NP complete means, I don't care. Of course I'm going to probe a bit into whether you can analyse the performance of your code - that's absolutely part of the job, and something I need to know you can do. But not knowing what one term means is not going to not get you hired.
Long story short - don't assume that everything in a whiteboard interview should be taken literally. I don't want to find out if you can write exact algorithm x perfectly so that it will compile. I want to know if you can solve a problem, and can talk rationally about your solution, its trade offs, its performance, etc.
You are definitely not only paying 25% tax when you're earning 160k in CA.
To take home 10k a month in CA, you need to earn around 220k a year before taxes.
160k doesn't take home 10k a month. It takes home about 6.5k a month. That said, yes, he still has 3.5k a month for other expenses, and it's his own stupid fault for choosing to live in SF, rather than the south bay, where a 2 bed apartment can be had for 2k a month.
To take home 10k a month you need to earn about 220k a year before tax.
The single payer they're typically comparing to is the NHS in the UK. While other insurers exist, they're such a small share of the market, that effectively the NHS holds a monopoly on paying for goods sold by drugs companies and/or hospitals.
Once you have a monopoly — such as "Single Payer" education, or healthcare, or Internet-Service provision — the price goes up and the quality goes down.
Actually, no - you've got your monopoly on the wrong side with single payer healthcare.
Companies that are monopolies are allowed to arbitrarily increase their prices because they are the single seller.
Single payer health care involves there only being one single insurance company buying goods from the drugs companies, doctors, and hospitals, allowing them to drive the price *down*, not up. That's why healthcare is so much cheaper in Europe than the US.
The fact that that's repeatedly been the outcome of unregulated economies? Either one, or a very small number of people establish a controlling position, and abuse it to shut everyone else out.
Yes, and as noted above Gaben saying "it doesn't matter if we don't sell any more" indicates that they don't expect to sell many more.
i.e. it's failed.
The reason the engine revs constantly is because the Prius has a clever mechanism using two electric motors and a differential that keeps the gasoline engine reving at exactly its optimal RPM.
That said, yes, the Prius is slow as shit.
I think you're just ignoring the breakthroughs that have been happening.
It's only about 15 years since a laptop was 1.5" thick, weighed 5lb, and had an amazing 2 hour battery life. In only a decade and a half the amount of energy that's been packed into a laptop battery has increased enormously.
This is also hugely visible when you look at power tools. I cordless power drill from 15ish years ago would almost certainly us NiCd batteries, with a life of only an hour or two. Modern power drills will last a full day or more with a battery pack that's substantially smaller, and that charges in a far shorter amount of time.
That's (roughly) the way it works today, except it's they'll be paid 'more' than the average salary for the position they're in.
The problem isn't the 50% bit, it's the 'the position they're in' bit. The contracting firms like Infosys fill positions that are generic contractor roles - *not* highly skilled positions, which command low salaries. They then contract them out to other companies to do highly skilled jobs, at their low skilled salary.
Companies like Apple, MS and Amazon (which are not in those top 10 visa getters) hire people directly into the highly skilled roles, and are more than willing to pay extremely high salaries for them.
Changing job with an H1B is trivially easy. Changing job while in the process of getting a green card, will reset your application and set you back years.
That was rather my point in a somewhat underhanded way - the article moans about "why don't browsers do this", when the reason is "because everyone writing it found that it was a useless feature for one reason or another". It's not like guys writing browsers aren't thinking about how to deal with this well, it's just not a problem that they can solve magically themselves.
Most web browser engines are open source. Go and modify one or many of them to handle slow connections better.
A sleeping bag on a hard floor does not get you proper sleep. A break from thinking about work, a meal with your wife/girlfriend, and your own bed gets you proper sleep.
Alternatively, let the engineers rest properly, and then they'll come back and write both more code, and better code the next day.
4!!! + 4 + 4 +4... Boom, bigger than your "biggest possible".