Between languages like CoffeeScript and TypeScript and runtimes like WebAssembly, it looks like we have some pretty good ways of evolving gradually into a post-JavaScript world and are on our way there. No need to articulate grand visions.
Either you don't get it or you don't want to get it.
No, you don't get it. You say that if a company has great people, it can achieve Amazon-like stability. It can. But the problem is that great people are hard to find, so when they retire or leave, you are left with a problem on your hand.
Solid businesses don't rely on technical or managerial superstars, they have business processes that function reliably with mediocre technical staff and managers.
If you run your own IT shop, you necessarily have a much smaller pool of IT staff than Amazon. That means that your risk of losing an employee who is key for keeping your systems running is necessarily much larger than for Amazon. If you don't understand that, you certainly "don't have your stuff together".
Have a look at the progress in semiconductor process size. To you as an end-user, this looks like a fairly smooth curve. What's hidden behind that is tens of thousands of engineering breakthroughs, as the physics change radically as you go down the size. The second thing is that going from a great idea to a mass market product takes time as well. There are many ideas for radically more efficient technologies, but it takes years, or even decades, to create the tools, fab lines, and expertise to produce them.
Even when there are no engineering obstacles, there are often other barriers to adoption, such as education, preferences, and backwards compatibility. It took decades for technologies like garbage collection, OOP, and runtime typing to be accepted by industry, and even today, many developers are still reluctant to adopt functional programming. And declarative programming, logic programming, and FPGA programming are still niche technologies.
However... The more you have your stuff together the easier it is to reach absurdly high levels of availability at affordable costs. Automatic host fail over, automatic site fail over, etc...
How nice. And when the employee that put all that together leaves to company for greener pastures or to pursue his dreams and when you have to replace him on short notice, that setup falls apart. Likewise, when you suddenly need to quadruple your capacity because of some business decision, you lack the staff and resources to do so quickly.
The nice thing about Amazon is that it is predictable, low (not zero) risk, and scalable.
If you took responsibility for your own hardware resources, this wouldn't have been an issue for you.
True, but anything from the extra staff to your data center flooding would. And if you total all of that up across S&P 500 companies, you likely end up with bigger total losses.
In different words, your advice is penny wise and pound foolish.
Will the high-paying positions be a thing of the past? Zhang thinks it's already starting to happen. He's one of 79 IT workers from the University of California, San Francisco,
That may have less to do with outsourcing and more to do with the fact that California has budget and pension problems.
"In two years, I could be at another company, and I could be facing the same thing," he said.
The guy wasn't working for "a company", he was working for the California university system. Peopl who "work for companies" already understand that they may get laid off when their employer needs to save money. Apparently, to government employees, this is a big surprise.
But now they use H-1B (visa) and use foreign workers to replace the high-paying jobs. This trend is dangerous
H-1B is a red herring; these jobs will get outsourced with or without H-1B visas, for the simple reason that external companies can provide these services cheaper than state employees.
and if they focus on requesting proof of unnecessary long-term memorization skills
Asking you to do a little programming problem isn't a test of "memorization", it's a test of your ability to write basic code without ropes and safety nets. People pick bubble sort because candidates are unlikely to have memorized the solution yet understand the specification pretty well.
but you keep telling yourself they should
Actually, I think whiteboard interviews are a waste of time for the interviewer. Much simpler questions usually tell me what I need to know, like "What is the purpose of whiteboard coding?" and "What's your reaction the statement 'I don't need to know even basic library functions because I can always look them up'?" or even "What questions do you ask during an interview?"
If you're actually an expert programmer, you know that writing any sort of sort by hand is an utterly stupid thing to do.
I didn't say that you should implement bubblesort when doing a job, I said that any decent programmer should be able to implement it. I even gave examples of lots of other silly things experts can do, like ski backwards and play the piano blindfolded. How utterly stupid do you have to be to still not get the distinction even if it is spelled out for you like that?
I'm sorry, but no. Experts avoid acquiring bubble sort, and you're a fool for suggesting otherwise.
A programming expert:
(1) Can implement it correctly in less than a minute. (2) Knows not to use bubble sort under most circumstances. (3) Can answer why it's a bad algorithm. (4) Can come up with situations where it might be the best algorithm to use after all.
Memorizing bubble sort is beyond pointless for a seasoned programmer.
That's the point. It's trying to test the ability of a programmer to write correct code for a simple specification from scratch. If you actually have it memorized, the interviewer will probably give you a different coding question.
To continue your analogy, it would be like asking a piano expert to compose a 6/8 waltz with a G progressive chord structure with a minor chord on the 4rd beat of even measures that resolves to the tonic on by the 6th beat in the style of Mozart. And compose it on a whiteboard without a piano.
If you think that writing a correct bubblesort on the whiteboard is that complex, then I don't think software development is a good job for you.
Who actually uses bubble sort on the job? Bubble sort is one of those algorithms that you should see roughly once in your career—in an introductory Algorithms class as an example of what not to do.
If you had implemented it many times, that would defeat the purpose. The reason people ask about bubble sort is because it's a simple (or simple to describe, if you don't remember it) algorithm you rarely implement. Hence, you have to actually think through things like edge cases, generic typing, argument validation, correct pointer usage, etc. It's a programming test, not an algorithms test.
A better interview task would be to compare and contrast some of the more common algorithms and give examples of situations where each would be suitable.
And that gives rise to nice follow-up questions. Why don't people use bubblesort? Can you think of any applications where bubblesort might still be a good algorithm? Can you think of hardware architectures where bubblesort might be a good choice?
You need me, that's why you called me; and now that I'm here, I see you're unsure and you've wasted both of our time.
That works both ways: if people invite you for an interview, your resume obviously misled them into thinking that you were something that you were not.
Personally, I don't give whiteboard interviews; I consider it a waste of time. There are simpler and faster ways of telling whether you know your stuff.
However, when people have given me whiteboard interviews, I viewed it as a matter of professional pride to get it right, even if I had already decided that I wasn't going to take the job.
After 20 years of programming experience, I STILL routinely look up the order of arguments for function calls via Google. Who cares to remember when Google has the answer in 0.10 seconds?
People aren't testing knowledge, they are testing familiarity. Let's say I want to hire a sales rep for Portland.
Interviewer: "So you say you're from Portland?"
Interviewee: "Lived in Old China Town for 10 years until last year."
Interviewer: "Oh, isn't Rocking Frog Cafe near there?"
Interviewee: "No, you're probably thinking Stumptown Coffee Roasters. Rocking Frog is on the other side of the river."
Interviewer: "Thanks, you pass."
I don't care about coffee shops in Portland, I'm trying to see whether you are actually from around there as you claim. And if you can't answer that question, I'm going to try some others. If you can't answer any of them, I might start having my doubts about your claim that you're from Portland.
Slashdot Mirror
Between languages like CoffeeScript and TypeScript and runtimes like WebAssembly, it looks like we have some pretty good ways of evolving gradually into a post-JavaScript world and are on our way there. No need to articulate grand visions.
No, you don't get it. You say that if a company has great people, it can achieve Amazon-like stability. It can. But the problem is that great people are hard to find, so when they retire or leave, you are left with a problem on your hand.
Solid businesses don't rely on technical or managerial superstars, they have business processes that function reliably with mediocre technical staff and managers.
If you run your own IT shop, you necessarily have a much smaller pool of IT staff than Amazon. That means that your risk of losing an employee who is key for keeping your systems running is necessarily much larger than for Amazon. If you don't understand that, you certainly "don't have your stuff together".
Have a look at the progress in semiconductor process size. To you as an end-user, this looks like a fairly smooth curve. What's hidden behind that is tens of thousands of engineering breakthroughs, as the physics change radically as you go down the size. The second thing is that going from a great idea to a mass market product takes time as well. There are many ideas for radically more efficient technologies, but it takes years, or even decades, to create the tools, fab lines, and expertise to produce them.
Even when there are no engineering obstacles, there are often other barriers to adoption, such as education, preferences, and backwards compatibility. It took decades for technologies like garbage collection, OOP, and runtime typing to be accepted by industry, and even today, many developers are still reluctant to adopt functional programming. And declarative programming, logic programming, and FPGA programming are still niche technologies.
How nice. And when the employee that put all that together leaves to company for greener pastures or to pursue his dreams and when you have to replace him on short notice, that setup falls apart. Likewise, when you suddenly need to quadruple your capacity because of some business decision, you lack the staff and resources to do so quickly.
The nice thing about Amazon is that it is predictable, low (not zero) risk, and scalable.
True, but anything from the extra staff to your data center flooding would. And if you total all of that up across S&P 500 companies, you likely end up with bigger total losses.
In different words, your advice is penny wise and pound foolish.
You'd be amazed at how much money a rainstorm costs the country. Or a heatwave. Or a cold virus.
Encourage them! I'm still hoping for Lena Dunham to make good on her promise.
Yes: that minute includes tests, and it's also provable from the code.
"I hate all this inequality and progress! I'm going to move to an egalitarian paradise, like ____!"
Unfortunately, people never actually follow through on the second part, because it means moving to places like Venezuela, Cuba, or Greece.
That may have less to do with outsourcing and more to do with the fact that California has budget and pension problems.
The guy wasn't working for "a company", he was working for the California university system. Peopl who "work for companies" already understand that they may get laid off when their employer needs to save money. Apparently, to government employees, this is a big surprise.
H-1B is a red herring; these jobs will get outsourced with or without H-1B visas, for the simple reason that external companies can provide these services cheaper than state employees.
Asking you to do a little programming problem isn't a test of "memorization", it's a test of your ability to write basic code without ropes and safety nets. People pick bubble sort because candidates are unlikely to have memorized the solution yet understand the specification pretty well.
Actually, I think whiteboard interviews are a waste of time for the interviewer. Much simpler questions usually tell me what I need to know, like "What is the purpose of whiteboard coding?" and "What's your reaction the statement 'I don't need to know even basic library functions because I can always look them up'?" or even "What questions do you ask during an interview?"
I didn't say that you should implement bubblesort when doing a job, I said that any decent programmer should be able to implement it. I even gave examples of lots of other silly things experts can do, like ski backwards and play the piano blindfolded. How utterly stupid do you have to be to still not get the distinction even if it is spelled out for you like that?
A programming expert:
(1) Can implement it correctly in less than a minute.
(2) Knows not to use bubble sort under most circumstances.
(3) Can answer why it's a bad algorithm.
(4) Can come up with situations where it might be the best algorithm to use after all.
(1-4) are not mutually exclusive.
I explained why they asked you those questions. I didn't defend it as the best interview strategy.
Hiring and firing have become costly, so companies err on the side of caution.
That's the point. It's trying to test the ability of a programmer to write correct code for a simple specification from scratch. If you actually have it memorized, the interviewer will probably give you a different coding question.
Took me less than a minute.
If you think that writing a correct bubblesort on the whiteboard is that complex, then I don't think software development is a good job for you.
If you had implemented it many times, that would defeat the purpose. The reason people ask about bubble sort is because it's a simple (or simple to describe, if you don't remember it) algorithm you rarely implement. Hence, you have to actually think through things like edge cases, generic typing, argument validation, correct pointer usage, etc. It's a programming test, not an algorithms test.
And that gives rise to nice follow-up questions. Why don't people use bubblesort? Can you think of any applications where bubblesort might still be a good algorithm? Can you think of hardware architectures where bubblesort might be a good choice?
That works both ways: if people invite you for an interview, your resume obviously misled them into thinking that you were something that you were not.
Personally, I don't give whiteboard interviews; I consider it a waste of time. There are simpler and faster ways of telling whether you know your stuff.
However, when people have given me whiteboard interviews, I viewed it as a matter of professional pride to get it right, even if I had already decided that I wasn't going to take the job.
Did I say anything different anywhere?
Well, gosh, and in those jobs, people probably aren't going to ask you those questions! Imagine that!
Nothing I mentioned is "genius level"; it's something anybody with a few years of professional experience in those fields should be able to do.
Not necessarily, which is why not every employer asks these kinds of questions.
But when people ask those questions, they usually are looking for a seasoned expert.
I'm not. So, you're free to not hire me as a forum poster, even though you yourself may be a professional (=shill).
People aren't testing knowledge, they are testing familiarity. Let's say I want to hire a sales rep for Portland.
Interviewer: "So you say you're from Portland?"
Interviewee: "Lived in Old China Town for 10 years until last year."
Interviewer: "Oh, isn't Rocking Frog Cafe near there?"
Interviewee: "No, you're probably thinking Stumptown Coffee Roasters. Rocking Frog is on the other side of the river."
Interviewer: "Thanks, you pass."
I don't care about coffee shops in Portland, I'm trying to see whether you are actually from around there as you claim. And if you can't answer that question, I'm going to try some others. If you can't answer any of them, I might start having my doubts about your claim that you're from Portland.