Haskell's aeson library, which is probably the most popular way to use JSON in that language, doesn't require any of this complexity or typecasting ugliness. It can derive a typechecking parser for a particular JSON format from an ordinary Haskell data type. Your type becomes a JSON schema, and as long as the JSON you're parsing conforms to that schema, the parsing just works with a single function call.
The problem you're pointing out is not a problem with statically typed languages. It's a problem with bad languages.
Well, you can always assign a different reviewer if your initial choice is taking too long. I usually try to check with my teammates to see who has time for a review before sending them my code, at least if it's something that I want to get submitted quickly. That ensures that I pick someone who will look at it sooner rather than later. Sometimes the specifics of the process require someone who is not on your immediate team to give their approval, in which case delays are more likely.
I'm an SRE, which means most of the code I write isn't directly user-facing, and thus isn't normally subject to hard external launch deadlines. That means I'm rarely rushing to push my changes through on a tight schedule. If there's a production emergency and I need to make an urgent change to avoid or mitigate an outage, there are escape hatches at our disposal to temporarily circumvent the code review system when no one is immediately available to do a review, but the need for that is pretty infrequent.
I rarely find it frustrating. On the contrary, I really appreciate Google's emphasis on code quality, even though it does come at the cost of some agility. I used to work at a company where the implementation of code reviews was generally resisted, and though we did get new code out the door faster, we ended up with some real maintenance nightmares as a result.
It's common at Google to have a few projects cooking that you move between. One reason for this (though I doubt it's the sole reason) probably has to do with the mandatory peer review process for all code, which can cause delays in getting your code submitted if your reviewer's schedule doesn't line up well with your own. Instead of introducing a bubble into your pipeline when that happens, it's nice to have a side project you can hack on for a little while until you get your code review feedback.
He's a Tech Lead Manager, or TLM, which means he's an engineer who also manages the team he's a part of. In some cases, dev teams have SRE counterparts who take the pager responsibilities, among other things. But not all services at Google have SRE support, and for those that don't, the developers themselves are usually on call. That includes the dev team's TL, or TLM, as the case may be.
It's too different from Gmail to be integrated into it. It coexists with Gmail so that you can choose to use Inbox and its "opinionated" workflow, or not. Users who like their personal Gmail workflow probably wouldn't appreciate having that flexibility taken away if it's not aligned with how Inbox wants you to work.
Every existing class A or B share will be matched by a class C share. Most Googlers had class A shares before, so now we'll have half class A and half class C, i.e. twice as many total shares, with the same number of votes as before.
If you don't think it's worth your time to interview twice at the same company, then simply don't. That's a completely reasonable point of view, and I didn't mean to imply otherwise.
For what it's worth, Google has a public reputation as a great place to work and as a company that hires "high quality" engineers. Both of these things mean that some people are willing to put more effort into getting a position there. My post wasn't meant to say that he must keep trying at all costs, but just to let him know not to be discouraged if he happened to really want that job. In many places, you're dead in the water if you don't make it the first time, but Google is not like that.
Personally, I didn't see my interview process as "something I had to go through", i.e. a laborious means to an end. I enjoyed the challenge and the opportunity to get a glimpse of a company like Google from the inside. Even when I was turned down the first time, I came away feeling glad that I had done it. It's not like I had anything to lose from trying.
> You wanna be the person that has to obey Larry Page's whims and integrate Google+ into more places users don't want it?
Not in the least, nor do I feel that I am doing that. I don't work on Google+ or anything related to it. However it may look from the outside, Google is not Google+. It's a big, multifaceted organization with opportunities to work on all sorts of interesting things. Much of our work is driven directly by the engineers themselves and not by management whims. And there's plenty of mobility to change roles if you decide you don't like what you're doing.
SRE specifically has proved to be a truly interesting and unique position. There are engineering challenges that we face which quite simply don't exist anywhere else. Beyond the much-touted perks, that's what makes Google special, in my opinion, and well worth the comparatively small effort I put into getting there.
The Google lunches are emphatically not a test. It's very rare for the lunch "interviewer" to provide any feedback at all. That usually only happens if the candidate starts spouting racist comments or punches someone in the lunch line, etc. The real purpose is to answer any questions the candidate has about culture, perks, etc. and to give them a chance to relax, catch their breath, and feel at ease in the middle of a stressful day of interviews. If the candidate was referred by a Googler, then often that person will be the one to take them to lunch, which would obviously create a conflict of interest if real feedback was expected.
I'm a Google SRE that had a very similar experience. My best advice would be not to sweat the rejection.
I was also contacted by a recruiter based on an open source project I had contributed to. I went through the same series of phone interviews, culminating in an on-site in NYC. I left there feeling largely positive about my chances, but a few days later, I was politely rejected. I was not that broken up about it, as I already had a job that I liked, so I just counted it as good interview practice and moved on.
A year later, almost to the day, the same recruiter called me up out of the blue and asked if I'd be willing to try again. I agreed, and after an abbreviated version of the phone interview process, went to Mountain View for another on-site. Soon after, I was hired!
It's actually very common for Google to reject candidates the first time around, as the interview process is deliberately tuned to produce a lot more false negatives than false positives. We have that luxury thanks to the volume of applicants we receive (there are still a surprising number of Nooglers starting each week despite the selectivity). The hiring committees recognize this tendency to reject qualified candidates and won't count you out after one try. If you got to the on-site stage, then rest assured that your interviewers took you seriously as a candidate. If you've decided that you would really like to work at Google, you will still have a good shot if you try again in a year or so. And if not, then hopefully it was at least a fun challenge and a free trip to London.