What tax benefits this move might have is my question as well. It seems like if this were purely about internal organization they could have effectively reorganized Google in the same way without making Alphabet (although I'm not an executive so I could certainly be missing something here).
Yeah, if we're talking about JavaScript, the explanation should start with promises. It's a pattern lots of people know, and it's a very real-world example. No need to front-load the explanation with a bunch of complication before people even know why they should care.
I suspect some people (not saying this author) butcher the explanation intentionally. Makes it seem like an ineffable topic that only the smartest programmer can understand.
Yeah the Haskell part is mostly tongue and cheek :P I wouldn't use it for any old project but I could see how the benefits of Haskell could outweigh its difficulties in some scenarios. Personally, I like functional programming, but I'm not sure it's suitable for the masses (perhaps some day? https://www.youtube.com/watch?v=oYk8CKH7OhE).
Yep, when I see "flat management" I really hesitate to apply. Especially as a minority in tech, I would rather find a hierarchical place with good managers who value good arguments than trust the herd.
Unless you have a team of unusually conscientious engineers, "democratic" or "flat" decision-making often translates to who shouts the loudest.
Not to mention engineers often want to complete the project in the most technically exciting way possible, rather than the way that will most benefit the product. Flat structure + too many engineers like that and you end up with this http://www.smbc-comics.com/?id=2597, written in Haskell.
As someone from a group that's underrepresented in tech, a co-op structure would make me hesitant to apply. I would be concerned that as a minority my voice would be lost. At least with a hierarchical structure I sign on knowing who the decision makers are and what their approach is (and thus I can find a place where the decision maker values solid arguments rather than whether the majority agrees).
I would like to know how they gauge performance too. Some cultures are about the perception of productivity, some are about actual productivity. Taken to an extreme, either case can make for a miserable work environment.
That is precisely the point. People with similar qualifications should have similar salaries. The "not great" trends implies salaries were correlated with something other than merit and qualifications.
The public schools I attended were far more economically, culturally, ideologically, and ethnically diverse than both my private college and post-college work environments (and you can throw in gender diversity too wrt my work environments). I would not have met kids like this otherwise -- certainly not if I had been in a homeschool group socializing with the children of parents who had similar philosophical views about schooling.
Public education is certainly in need of big reforms, but I'm grateful for the diversity I was exposed to attending one. It's a big part of what keeps me grounded in the ridiculous Silicon Valley bubble.
What is your programming interview like? If it's whiteboarding algorithms, it's likely to be eliminating a lot of good people who get nervous, and selecting for people who are good at studying interview questions and coding under pressure in an artificial environment. There is good evidence it doesn't predict job performance well, see: http://www.wired.com/2015/04/hire-like-google/ and https://twitter.com/mxcl/status/608682016205344768
I have told my designer friends in other areas how well in-house designers are paid in the Bay Area, and their response has always been that they think being in-house would be boring and they strongly prefer agency work (despite, in their experiences, super low pay and horrific management).
I have always wondered if in-house work is legitimately more boring or if the goal of working at an agency has just been drilled into them since design school.
Is it considered a stigma on one's resume to have done in-house work? If not, it seems like designers could go for the programmer model of employment -- work in-house for a few years then switch to a new place for new challenges when you stop learning and growing, unless a new challenge is presented.
I totally agree. Ironically I can't recommend LastPass to the people who most need it because they aren't tech-savvy enough to figure out and tolerate the UX issues.
I wish it were easier so I could get my parents using it.
> "From 5:30pm-8:30pm, I’m not a startup CEO. I’m a dad." <- That statement right there pretty much illustrates my point.
I don't understand. Most of the non-founder, regular engineers with kids I know don't even get home at 5:30. Sounds like he's doing well for a working dad.
In that dish is the rice hot? Does the egg end up semi-cooked? I really hate most convenient American breakfast foods because I don't like to eat sweet stuff in the morning. Egg and rice sounds pretty appealing and very convenient.
I agree that these interview questions are going to be around for the foreseeable future, so people need to just learn them. But it's still a waste of time -- you have a limited amount of time to devote to learning new technology. You can either spend your time building a cool side project with interesting languages, frameworks, or technologies that are highly relevant to your work or you can use it to study algorithms you will never implement outside of an interview.
When faced with this dilemma in the past I have picked the interview prep because it's necessary, but I'd rather have been building cool stuff that actually helps me do my job better.
The problem is that irrelevant whiteboarding questions are far more the norm than relevant whiteboarding questions. Most companies interview this way, so if you avoid those companies you avoid nearly everyone.
I'm a full stack developer who specializes in front-end. Knowing how to structure a front-end app, knowing/following JavaScript best practices, and understanding the arcane idiosyncrasies of JavaScript are in my opinion three of the biggest values a front-end developer can add. However, the companies that assess this stuff in interview are an extremely small minority. I usually get questions about binary trees.
It's partly because it's more difficult to assess those ways of thinking in interview, and it's partly because linked list kinds of questions are just the way interviewing has always been done, so people keep doing it.