一年半Google SETI谈谈这个职位

感觉时常在地里看到询问Google的SETI的问题，比如这个title是什么意思，和SWE有什么区别等。于是想专门开个帖子谈谈Google SETI。
LZ背景：2017年初作为new grad SETI进Google，18年年底离职。在这个岗位待了超过一年半了，因此相信自己讲讲对这个岗位的感受还是有参考意义的。
我会尽可能多的涵盖我对SETI的见解，以后再有朋友想询问关于SETI的问题的时候，希望这个帖子可以作为一个data point。

什么是SETI
SETI的全称是Software Engineer, Tools and Infrastructure。这个title诞生于大概两三年前，它的前身是叫Software Engineer in Test(可能不准确但不会偏差太多)，由于原本的名字不太容易招到人，于是重新改了个好听的名字包装上市。但不要慌张，这个不是一个QA职位。


SETI的工作内容？和SWE(Software Engineer)的区别？
SETI和SWE是两个不同的job latter，这意味着两者的工作内容(job description)以及衡量/评价标准是不一样的。
总的来说，SWE是输出，SETI是辅助。

先说说SWE，这个title和别的公司常说的SDE等价，他们负责的是一个产品的production code，他们服务的用户是这个产品的所有用户。
他们的工作内容包括开发新的production feature，production code maintenance（包括refactor/重写等），write unit test for production code，write integration/e2e test for the whole product等。
总之他们开发维护的software是production本身。

对于SETI来说，他们的产出也是software(而不是test case)，只不过他们的用户是SWE。SETI的目的是给SWE提供支持，让SWE能更快更高质量地deliver。tool and (test) infrastructure是SETI最主要的产出。一些简单的例子包括：
build production-like sandbox environment，build test framework/infra for the product to make integration/e2e test much simpler，provide tooling that collect certain metric from production and build dashboard to display the data...
SETI并不对production code负责，他们负责提供工具。

以上是按照job description的理论区别。在实际中情况中，不少SWE做的是SETI的活，也有不少SETI做的是TE(test engineer)的活。对的，Google是有TE这个title的，只不过让SETI做TE工作的情况并不罕见，因此会让一些非SETI产生SETI=TE/QA的感觉。因此如果接了SETI offer，在team match的时候最好搞清楚那个组是怎么用SETI的。同样对于SWE来说，也尽量不要做SETI的活。不同的latter在review的时候都是按照各自latter的description来评估的，做不属于自己latter该做的事并不能赚到credit。

SETI在org/team里的两种常见架构
在我的观察中，SETI的人事结构常见的有两种
第一种是一manager下面有很多(10-20+)个SETI(通常是SETI manager)，然后这manager参与负责一整个大org的所有project的tooling/testing，他下面的所有SETI一起搭建给这个大org的test infra或他分配他手下的各个SETI去做org下不同的project。
另一种是一个manager下有SWE有SETI，这种SETI负责给这个manager下的SWE build他们需要的tool/infra。

个人认为第二种架构是比较好的。SETI虽然不负责production，但对production code越熟悉，对architecture越熟悉，肯定对自己的工作越有帮助，因此和SWE的沟通和请教肯定是在所难免的。
第一种架构下，由于product SWE team和SETI不在一个manager下，实际上沟通成本很高，他们在build production的时候可能也不会参考SETI的意见。第二种架构下，大家同属一个team，关系更近，交流起来也更方便没有距离。
SETI的deliver一定程度上比较依赖于SWE的进度。如果SWE的project没有很好的进展，SETI做的东西价值不见得很高。

SETI的面试是否比SWE容易？
理论上说SETI和SWE的录取bar应该基本一致，只是面试考察的侧重点有区别，SWE的面试每轮都是算法(L5及以上增加system design)，而SETI的面试会有个别轮次偏重算法(这部分评价基准和SWE完全相同)，个别轮次偏重测试(问题相对简单，更多考察在代码完成后如何考虑对代码进行测试)。

Again以上为理论情况，实际中由于SETI比SWE来得紧缺/更难招到人，确实会适当降低SETI录取的bar。并且很多面试SWE得到bottom line NO的candidate会被推荐去加面SETI。

SETI的薪资和SWE比如何？
SETI的薪资和SWE在同一水平。例如对于new grad来说，在都没有任何compete offer的情况下，SETI和SWE的package相同，都会明显优于如TE等title的package。

SETI是否比SWE更容易promote？
是的，因为对比的是同个org下相同title的人，SETI由于总人数少，竞争压力远比SWE低。

SETI想内部转SWE容易吗？

相对容易。
SETI到SWE的latter转换是不需要面试的(如果TE转SETI/SWE需要重新面试)，只需要找到receiving manager，得到对方的支持就可以。到新的组后，需要顶着SETI的title做2个cycle，一切正常就会在2个cycle结束后自动转为SWE title。并且SETI到SWE的转换通常不需要降级，因此不少人喜欢从3升到4后立刻尝试转L4 SWE

SETI的发展如何？

如果你的兴趣是做正统的SD做product的话，SETI不是一个好的选择。
如果你的兴趣是给周围的engineer提供tooling，SETI适合你。
简历上SETI的这部分experience，很容易被外面的公司认为是更适合他们的devops，CD/CI tool这样的位置。

做SETI能学到的比SWE更多的东西？
这个我从自己的经历出发讲。
我作为SETI的这段时间基本都在做test infra。实际上对于很大的pipe line/distributed system来说，给他们搭建一个test infra意外的复杂和有学问。
Google的culture中对quality的要求很高，因此testing是所有人开发中非常看重的部分，所有的Google engineer都写大量的test code。作为SETI，我学到了怎么样的code是更容易test的，怎么样的code在出问题的时候是更容易debug的。

我见过很容易test的system，也见过完全untestable的一坨东西。
我认为这部分经验这对所有想写出高质量code的engineer都有价值。

LZ，SETI有哪些部分你不喜欢？
1. 对SWE的dependency太重，需要很多team wise communication。
2. SETI的产出通常基本没有SLO，no one cares the performance，也不需要很复杂的architecture，个人感觉从engineering的层面上来说不是太有挑战性。
3. Average code quality比SWE的production code差些(毕竟实际hiring bar还是低于SWE)。
4. 自己的经历上来说，大多数teammate都是在转SWE的路上，manager也知道手下的人都是在转SWE的路上....Errrr.....没办法，大家还是更喜欢输出位，能carry谁要做奶妈啊。

什么情况下接SETI的offer好？
如果SETI听起来是你喜欢的工作，那么恭喜你，高高兴兴的接这个offer就好啦。
如果你是特别想做SWE但最后只给了SETI offer但你又特别喜欢Google，你可能会考虑接了这个offer，先进Google再说，以下是几点你需要考虑的
1. 转SWE确实不难（我离职的时候组里80%早于我入职的SETI都成功转SWE了），但你需要至少在SETI的位置上做1年，要想在一年后转一个不错的SWE组，这1年里还是需要有不错的deliver的，那么自己是否能做好自己不太感兴趣的事情？
2. 自己的面试水平如何？如果这次只是没发挥好bottom line NO，那么可能做一年正经SWE，明年再战Google SWE更好，毕竟一年的时间和经验非常宝贵，不要浪费了；如果这次是超常发挥了，觉得以后再面可能就直接没机会了，那接下来是一个不错的考虑。
3. 你需要更小的压力和更好的wlb，SETI是个好选择。


最后
Google对于quality的要求很可能是行业标杆，这也导致了对于SETI有足够多的需求(head count)。
从candidate的角度来讲，这个title是很多人曲线救国进入Google的方式。
实际上我也认为哪怕是想做SWE，有一小段SETI的经验是完全有利的。

以上都是我基于个人经验给出的见解和总结，但毕竟也只能代表我自己能见到和感受到的范围。如果有更多的SETI愿意提供自己的data point的话就更好了。
暂时想到的就是这么多了。如果大家还更多问题也欢迎提问，我会尽量都回答一下。



补充内容 (2018-12-28 14:32):
所有latter=ladder。笔误严重

这个和SRE一样不是个适合new grad的职位，需要有product sense也需要知道什么是high quality code。像外面小公司类似职位都需要三年经验以上的人。GG因为螺丝钉替代性高愿意找没经验或者经验很少的人，这对刚参加工作的人是机会也是挑战，做的好的像楼主这样可以有个全局观，做的不好的估计忙活了半天都觉得螺丝钉的活没什么意义。。。

yixinwu921203 发表于 2019/02/03 00:09:33


直接转就是在商谈offer的时候问HR能不能考虑swe职位，我现在是过了hc，hc给的意见是推荐我做SETI，我在想能不能和HR商量转swe，如果可以的话几率大不大？

你肯定可以去和HR商量，他不可能因为你去商量了就给你把offer撤了对吧。
是不是真能给你换我觉得可能性不大，根据最近地里的汇报看起来是SWE没坑。但你问一下总是无妨的

我在现在的公司很神奇， end to end test有专门的人写，然后code infra (CI/CD) 有不同的人管。
做CICD跳FLAGUAP看起来也不是问题，认识有一个人是这样。

但general开发的其他人可能更多 -- 他们一套CI/CD Tool可以喂饱很多开发组，而这些个每个开发组又有自己的SWE。

所以有这一份经验可能不错的。

感觉有兴趣的同学可以试试看，没兴趣的还是可以SWE。

PS 楼主是一个善良又具体的好人 笔心

latter是不是指的是ladder？

bananapancake 发表于 2018-12-27 12:46
latter是不是指的是ladder？

是...英文太差了羞愧

LZ大大你好！我也是最近收到Google的offer，然后想问您俩问题：

1. SWE 和 SETI 这两个职务是相互平行、而不是互相包含的关系是吗？
2. 我最后选的组是Google Search 下面做一个 data infrastructure (也是做 infra)，然后按照您的描述，SETI也是做infra，这二者之间有联系嘛？或者说一般各大组的 data infra 是属于 SWE的？

谢谢！

论坛匿名账号 发表于 2018/12/27 13:16:49
LZ大大你好！我也是最近收到Google的offer，然后想问您俩问题：

1. SWE 和 SETI 这两个职务是相互平行、而不是互相包含的关系是吗？
2. 我最后选的组是Google Sea...

平行关系，不同ladder，就好像SWE和SRE是不同的两个ladder。

SETI的infrastructure默认为test infra就行了。
Google里说的各种infra，如果你现在不是很好理解，可以先笼统的认为是backend product，不完全准确但大概是那么个意思。

你可以把data infra看作是一个product，组里面肯定有swe去build这个，但也可能会有SETI针对它做test infra来给它做test，还会有SRE来保证它的正常运作。
具体你是哪个role看offer就知道了

lz 没有试着转SWE吗?

say543 发表于 2018-12-27 13:37
lz 没有试着转SWE吗?

转啦，现在在新公司就是做SWE。
想换的时候内部和外部的机会都看了一下，最后选择了出去体验一下

好奇SETI比较具体的技术栈呢~~

cszhazha 发表于 2018-12-27 13:59
好奇SETI比较具体的技术栈呢~~

我的体验和大多数SWE差不多吧。语言看组但也无非是C++/Java/Go/Python，然后像db(SQL/NoSQL), queue, gRPC, GFS, GCP等等的在做test infra的时候该用的都得用，都是Google in house版本就是了。SWE用得比较少SETI用得比较多的应该是build sandbox的 tool。