Is there a path for regular SWEs at Google to transition into a Brain-like role? I.e. with opportunities to do research, work on the problems you all work on.

Yes, there's the "ML ninjas" program, which brings non-ML SWEs into brain and other groups for a deep dive into machine learning through a project-based approach. (Often, but not exclusively, inspired by a problem from their originating area.). It's not a transition per se, but a great outcome is that the person becomes a bridge for their team between their specific domain of expertise and machine learning.

A full transition would be done by the usual transfer mechanisms. Two of my former students have switched into Brain from elsewhere in Google, for example.

Is Test Engineer different from SETI (Tools and Infrastructure)? What does SETI do?

Search for great tools and engineers on far away, exotic planets :-)

The begs the question: can we SETI at home?

I believe SETI is the new name for what was formerly Test Engineer. I think they changed the name because it was a better description of what they do. I suspect it also made it easier to hire for, although that might just be due to the aforementioned reason.

This is based off what I was told when I interviewed there a year ago.

SETIs are what SETs used to be. TEs are different. So SETI == SET but SETI != TE and SET != TE

I appreciate the correction and apologize for misinforming people. Unfortunately I can no longer edit my original comment

Yeah no problem. Just wanted to clarify. The vocabulary is confusing.

From what I understand, SEs in Test are now called SETI, but I could be wrong. It sounds like SETI does all the things the test engineers do in Google (I interviewed with SETI a half-year ago).

Yes, they are. That's why we started this little series of posts to highlight the difference. There already are some articles on SETI (aka SET). For example https://testing.googleblog.com/2016/03/from-qa-to-engineerin...

Bit new to Docker - so does this mean Docker 1.7 won't work with RHEL? Specifically I'm working on RHEL 6.6 machines, and I'm already stuck with Docker 1.5 so curious to know whether this will affect me

I'm not running RHEL myself, so I can't authoritatively speak about it. The backstory is that Docker, as statically compiled and released, uses the 1.02 release of the devicemapper driver, which has a bug in it. The OS has a 1.02.1 version (and has, for some time, it was patched in Dec 2013), but you have to make your own Docker build which will dynamically link to it.

Take a look at your version of libdevmapper, and you should be able to see if there will be a problem; what I've heard is that CentOS and RHEL also have a fixed version of devicemapper, which causes the mis-match and creates the problem outlined in the #4036 issue.

The ideal fix is to actually compile Docker on an Ubuntu (RHEL) OS when building the Ubuntu (RHEL) packages, but what's actually happening is that it's being built in a minimal Linux container - which gives it a different version.