Or to provide more highly-paid jobs for designers of robots to perform the task without human labor.

You should be a little careful with ideas like that... you may end up hurting the people you're trying to help. In many cases, they'd rather have the crappy, exploitive job than starve while watching the machines do what they used to. The machines will come eventually, but taxes like the one you describe will accelerate the process. In general, taxes and other regulatory inhibitors that are intended to fulfill some social goal are viewed by the market as damage, and routed around if at all possible. That doesn't make them useless, but it does mean that you have to step very carefully.

Courting isn't necessary to life, even though it may feel that way. And, actually, diamonds aren't necessary to courting, either. When I got engaged, I was poor and my wife had money, so she bought our rings, both of them. Diamonds are nice enough as long as they are only symbols. If they are more than that, you have a bigger problem.

Huh? This makes no sense. If they're Android, they can do an incredible variety of stuff. Being low-end, they might not do it well, but they should run pretty much every Android app out there. If they "can't do much to begin with", they're not Android.

To be fair, there *are* fixed costs to the power company in keeping you connected to the grid, in fact those costs are a fairly significant portion of the normal power bill. It's just that the current fee structure doesn't reflect it well.

By depreciating to zero in 10 years you're implying that a battery with 70-80% of its capacity is useless. That's hardly true.

Absolutely not. They're there for various very important reasons.

However, none of those reasons are the one you postulate. If you look at each of them individually, drop your bias, and think about what benefit there could be to the company in providing that service to employees... it's generally very obvious.

Where do you keep your toothbrush at work? Or don't you brush after lunch? Ick.

Attrition at Google is very, very low, and what there is is mostly people leaving to found their own companies. As for how it sounds to you... you really don't know what you're talking about. Go spend some time with some of said young employees and you'll see why they feel it's fantastic.

Nope, just another SWE.

Salary plus annual bonus and incentive stock. Yes it's the same for pretty much everyone. Why?

Not at Google. Engineers talk to each other a lot about what they ask in interviews, because one of the rules is that you must "calibrate" your questions, and the very best way to do that is by trying out your questions on your colleagues.

The goal, of course, is to select hires who are at least as good as you and you colleagues.

Actually there's an extremely good chance of Java. Google mostly runs on Java... infrastructure stuff like GFEs, borg, etc. is all C++, and search is C++, but nearly everything running on borg is Java.

This AC nails it. I'm also a Google SWE. And I have gotten yelled at (figuratively) for not disconnecting :-)

No, they don't. Google did try that once, with math problems on billboards. Lazlo Bock says those billboards resulted in zero hires.

(I'm a Google engineer.)

What use is that? That is asking for rote memorization.

Why would you want to test that? That's pointless. At the very least if you ask about complexity of common algorithms, you should also ask them to explain how they determined it, or could determine it. Even better, ask them to create an algorithm to solve a problem, then ask them about the complexity of that. Then they have to actually work out the complexity, demonstrating that they understand asymptotic complexity as a concept, rather than just regurgitating. Then take it one step further and see if they understand the difference between asymptotic and real-world complexity, and why the ideal algorithm for massive data sets may not be at all appropriate for small ones.

My goal in an interview is to make the candidate think, and to watch how they do it. How do they explore the solution space? Do they tend to get stuck on one unproductive line of inquiry, or can they step back and try another angle? Can they see ways to reformulate the problem to simplify it? Generalize it? Specialize it? Do they understand the tradeoffs of various design decisions? How effectively do they collaborate with me on the solution? Good engineers know when to ask for help.

Oh, and... can they write code? Because it's amazing how many people walk in fully able to talk the talk but when asked to produce some functional, reasonably-clean code fall flat on their faces.

Those are useful things to ask about. Memories of libraries and interfaces? Useless. Actually, probably counterproductive unless what you really want is someone who is deeply specialized, then you can ask about the relevant components in that specialty. But in the common case it's far more important to find out if they can reason, problem-solve, code and interact with you. They can google the specifics.

Yes, this is why one of the requirements for good Google interview questions is that they not rely on specific knowledge. They tend to ask you to invent and implement a new algorithm, not remember an old one. Where interviewers do ask questions that require specific knowledge, they're happy to provide whatever you don't remember.

Nice theory, but as I understand it, higher percentages of candidates with professional experience are hired than of candidates fresh out of school. I'm 45 and was hired by Google four years ago. Most of my team was in the 40s, with several in their 50s and a few in their 60s.

There is an issue that older guys who haven't reviewed their algorithms, data structures, complexity, etc. recently may be a little rusty. Most of the time this doesn't actually create any issues, and it's pretty easy for older guys to address simply by brushing up before the interview. I did.