原创： 小编整理
本文是楼主针对 junior engineer
发起的一个话题
小编为大家整理了精彩的跟帖
发起
话题
作为junior engineer，在一个满是senior甚至更高level的engineer的组里是好事还是坏事？
由 shiloh00 发起话题
我现在在的组除了我T3，基本上都是T5起 ，平均工龄5 years + 甚至还有一些工龄10年+的大佬。 想到的好处就是peer pressure会小一点，可以跟老人学东西。
坏的地方有，得不到好的项目和信任、impact少、做下边角的东西，被老年人们忽略以及开会听不懂的挫败感。
考虑过转向产品组。
如果去newgrads junior很多的组， 做得项目会快很多， 好上手（因为senior多的组一般系统都比较复杂 + 难)，但是peer pressure又会很大一堆t3等着升4，但是个人做很多项目应该会有很大的满足感。
男朋友在前公司的第一个组就是因为组里有很多E8（funding member) 项目被压着，新人不被信任，导致后来换组了。
我在前司的组里也是用了很久的时间融入（因为组里都是做了五年+的老人，很难插上手新的项目）现在这个组又不是年轻人多的产品组，所以有点迷茫。
想求大家指点迷津：如果是infra的组就是会这样，那么问题也可能是”年轻人如何在infra team survive？”
前面提到男朋友在的第一个组很多E8，而这些E8都是自尊心极强的白人，整个open source的funding member 连老板都要看他们脸色行事，很明显不是一个好组。
我的前司高达90%的印度人比例，作为组里唯一的女程序员非常的不被重视。印度老板思想里觉得女性差不多做点小活就行了，不需要take很大的responsiblity。即是年底的pf给的是exceed，自己却因为学的太少很郁闷。
新组的国人白人各一半，华人老板很supportive。一周两次的1o1，积极的给我找不太复杂又有价值的task， 老板本身也刚来半年，感觉还在ramp up阶段。组里的人都比较独立强大，没有team lunch 工作，各司其职！
以下是整理自地里的优秀回答
回答来自 ay3333
只能说各有利弊，取决于你有多么junior。
我工作没多久也算是两种都经历过了，以下讲讲我的经历和感受：
刚毕业的时候加入的是个senior远超于junior的infra team，大概是6个超大牛（principal及以上级别）、3-4个senior、1个SDE2和1个可怜的new grad(我）。
缺点就是三个字：压力大。大到晚上睡不好觉，因为我无论如何努力都远不及我的teammates，经常担心我的manager会有buyer’s regret后悔收了我。
优点当然就是能从不同人学到非常多的东西，不仅是coding技术上的更是工作上沟通为人处世方面的。
我觉得作为team里面唯一的junior不要一上来就想加入核心feature，而是要从bug一点点入手。主动去问大牛们他们手里的bug那个你可以help investigate+fix。一般他们会非常开心把bug甩给你。
改bug是个很好熟悉系统的方式，主动帮senior load balance也会让老板更加了解+信任你。我是大概做边边角角和改bug将近三个月后才开始参与feature的，都是senior们的design我来implement这样。
我觉的只要会主动要work，在senior多的组才impact大。因为项目选择多且都是非常核心的项目（每写的任何一行code都有可能take down整个service。。），而且没有人会和你抢东西做。
大概工作一年多后我们组因为牛人太多被分成了两个组然后新招了些SDE2级别的人，不过依旧senior多。
分成两组代表我们team own的core features变少了，on-call时候负责的东西少了，相对压力变小了，整个team room氛围感觉更放松了，但是同样的可以让我随意问问题或者bounce idea的人也少了。
又大概半年后组里先后走了两个大牛，其中离开的一个大牛是我很好的朋友对我帮助非常大，可以说是我工作以来最敬佩的一个人。大牛把手下很core的feature ownership留给了我，工作压力突破顶峰。
现在我们team大概senior/junior一半一半把（我依旧level最低）。优点就是责任变重了，慢慢开始lead小project了，更敢在design meeting上发表自己观点了。
不好不坏的就是一些琐碎的事情比如需要回复的email，参加的design meeting，review的pull request都变多了。
缺点就是学到东西少了，感觉大家（尤其是junior间）多的是埋头做自己分配的的工作反而knowledge sharing少了。
回答来自 Black Liu
感觉这个就像围城墙里的面的人想出来，墙外面的人想进来。
我一开始入职的时候我们组只有两个人，连manager都还在招。
这个时候的team刚刚建立，虽然有了自己own的东西，但是很多不明确，根本不可能去做一些大的系统的活只能干一些边边角角的小feature。
后来manager入职了之后，会觉得你是这个team的founding member然后给你分派一些大的活。而且还会招一些新的SDE，这样你还可能mentor新人。
优点是可以做一些很大的project并且写一些design。
缺点就是没有一个经验成熟的senior的话可能会在design上有所欠缺。具体到component的设计，scope，resource等等。
一个有经验的senior可以很好的define不同team的界限，掌握整个的project的进度并且进行有效的push back。
这点很重要，有些时候的push back是必须的，不然就陷入了无穷无尽的自己team承担很多活。
以上都是当你在没有经验去lead一个project的时候会遇见的坑。 但是反过来，当你和一个senior合作的时候，你的impact一定会在这个senior之下。这个时候就会感觉到自己可有可无。
我个人的意见是楼主想明白自己现在追求的是什么，并且学习和掌握怎样增加自己的visibility。
举个例子，如果现在target升职，在很多Senior的情况下就比较困难，因为自己的impact可能并不会很大。
但是如果想要学习就好好利用这个机会学习一切的关于tech和soft skill的东西。同时也需要让你的manger知道你的想法，主动积极的去争取一些项目。
当你在一个组里的时候，可以主动写一些proposal出来来说服你的老板这个会给整个团队带来什么。一旦你的项目被采纳来lead这个项目的人就应该是你了。
我觉得不管在任何一个组成的团队里，你要展现的都是你对整个团队的影响，大到所有的design，小到所有的featur task，CR你都可以用自己的理解来comment。满满的有了新的想法就可以起飞了！
回答来自 hxtang
取决于senior是怎样的人，以及team的人跟project之间的比例。
提供一个data point：
我入职的时候是4，组里两个senior都是e7 tl。
刚入职的时候两个人轮流带我，有问题的时候帮着debug，有质疑的时候回答很谦虚，performance review的时感觉比我自己还希望我promote。我之后又有若干4-5 join，都是这个待遇。
当然这个data point一半是运气，两个senior都是人好的大神。
另外一半我觉得是team增长的需求，如果own很大scope却没有足够多人，那来了新人不会想着信不信任，想的都是赶紧教上手了可以新人自己own一块，还能帮着带更新的人。
回答来 自buck_zzy
我在senior多的infra组和junior多的产品组都呆过，也经历过一个组从基本全junior成长到senior人满为患的过程。
前面大家已经把两方面的优缺点都总结的差不多了，很多人提到senior多的环境容易学东西，也有人说要自己有机会上手才能涨经验。
我从自身经历聊聊这两种情况下的到底能学到什么。
首先，我们这里不讨论书本上能学到的知识，这里包括但不限于各种CS基础知识，OS，网络，语言，算法，常见open source system架构。
这些知识有大量的公开课，教材，文档可以自学。我记得看到过有人写在google工作的好处，是可以直接在内部IM上问golang commitee的人初级问题。这就是典型的浪费学习机会，也是浪费彼此的时间。
那在一个全是senior的环境下能学什么呢？
我理解主要是两方面：
第一是解决复杂技术问题的方法论。
这里的复杂问题可以是各种奇怪debug过程，系统重构，或者是梳理一个一团乱码的项目。我接触到的最senior的工程师，往往是team里最被信任能够解决困难的问题的人。
而我在观察他们解决这类问题的过程时，能明显感觉到他们会对技术问题有各种各样的抽象，也就是所谓的"solve the problem at a different level"。
这种抽象能力和方式和每个人的知识结构和经验有直接关系。在一个全是senior的组里，你可以接触到很多人很多年形成的知识体系，那还等什么呢？
第二是设计经验，或者说是提前预测问题的能力。
设计一个系统，或者做任何一个技术决定的时候，一个工程师能提前考虑到多少不同的因素和潜在的问题，是system design能力的直接体现。
设计一个直接能上线的系统容易，但设计一个能survive若干次需求和人员变动的系统，是需要踩很多坑才能锻炼出来的能力。
现在轮到junior挑大梁了，我觉得这种情况下最能学到的是各种软能力。
如何push一个cross team的项目，什么问题该什么时间和什么人用什么顺序communicate，谁有资格做什么样的决定，如何说服别人一个技术上分歧。
这些问题在项目里有senior的时候往往被解决好了，只有当你自己挑大梁的时候才能锻炼。