一亩三分地

 找回密码 注册账号

扫描二维码登录本站

BBS
Offer多多
Salarytics
交友
Learn
Who's Hiring?
Visa Tracker
疫情动态
指尖新闻
Instant
客户端
微信公众号
扫码关注公众号
留学申请公众号
扫码关注留学申请公众号
Youtube频道
留学博客
关于我们
查看: 2743|回复: 3
收起左侧

5.18结束亚麻virtual实习体验

  [复制链接] |只看干货 |amazon, 码农类general, 八卦我司
我的人缘0

升级   14.93%


分享帖子到朋友圈
本楼: 👍   100% (9)
 
 
0% (0)   👎
全局: 👍   97% (127)
 
 
2% (3)    👎
码农类General 实习 本科+(短暂实习或全职不超过3个月) [4] 您的积分不足。关于如何获得积分,请参考新手上路指南总帖 IC (Individual Contributor 技术岗,不管人) @ Amazon Amazon Business Greater Seattle Area
在这家公司工作了多久: <3months | 你还在这家公司吗: Intern/Not Full time employee
==== 综合评价: ★★★★☆ ====
你对公司商业前景有信心吗: Yes
你觉得有清晰的发展空间吗: No
WLB-平均每周工作多久: 40-50hours
上次refresh多少钱: NA
公司食堂: No free food, no easy access to paid food

人员流动-你的director组内最近半年有多少人离职: 0%
周围做决定的人一般是谁: PM
大部分同事上班状态: Reasonable work ethics, not killing themselves over work
你身边政治斗争如何: Barely any

当初为什么选择来这家公司?: Big title
如果已经离开这家公司,为什么选择离开?:

具体工作,组,tech stack等:
B2B marketplace under Amazon Business

最满意的是什么:
Nice and highly supportive mentor, colleagues, manager.

最不满意的是什么:
Requirement keep updating all the time

你对这份工作最看重什么:
Learning and Return

注册一亩三分地论坛,查看更多干货!

您需要 登录 才可以下载或查看,没有帐号?注册账号

x
地里已经很多亚麻实习体验贴了,这里主要为打算面/将要来亚麻的intern,作为过来人角度来介绍一下,我实习中的坑!!!return evaluation标准
首先介绍下楼主的背景,楼主在Amazon Business,B2B marketplace下的一个组,由于我们组的manager在我来之前走了,所以负责我intern的manager实际上是应该是原本的skip manager,这里是我实习第一个困难所在之后会回来详细说。我做的project是在一个正式launch的portal里建自己的全栈service,有paginated query and download large discounts excel的功能,这个internal tool的query功能是给SDE developer用于debugging的,download功能是用来support Vendor Manager,Product Manager的,他们可以参考这个downloaded excel对亚麻所有markplaces的Vendor进行update discounts. 这个project技术上难度其实不是很大,但是也不是随便设计让实习生做做的,如果intern不做也是其他full-time来做,而且最后presentation里 我的大老板(L7)也感谢我的contribution,说这个project对他们非常有用,managers们对之前update discounts是多么的struggle(当然其中也有老美过分赞美人的传统在这里...,但是我实际上听完也是很开心的)

接下来介绍我的实习project从开始到交付的大概的流程
skip manager给我的大哥(SDE2)一个idea(我不在场),大哥做了一个mock(mentor说本来应该我做的,所以大哥考虑到我没有什么business context,所以人是超级nice的),manager因为太忙,所以没有看让我先做吧,于是乎我大哥和我,我的mentor开了个会,主要负责介绍我的project需求以及解答我的疑问(此时我一直觉得我按大哥的需求走就行了),我得到的需求是,2个 RPC service的query DynamoDB GSI的API,外加前端页面就完事儿,因为大哥也比较忙所以等确定出我的project且开第一次meeting的时候已经是第三周,虽然这样,我心里仍旧舒服的很。我们接下来进行tasks break down,大哥人很好,怕太push我给我布置任务量不大而且一直和我说,你觉得任务多就提出来,所以初始给的task timeline是是在第十周实现UI。第5两周我写好了API也进行了beta测试,然后心里抱着早做完给manager和team留下一个好印象的想法用5,6两周就写好了前端,此时叫它version1,我按照大哥给我的需求只有query active discount and discount history on ASIN的功能,这里多亏了我提前写,要真按着timeline来我估计就歇菜了,在team内部展示完获得大家一致好评后,我又给我的skip manager展示,老板提出,你make big progress但是光查ASIN不行啊,每个ASIN的discounts一共没有几个,重要的是query on vendor,这个返回的records数量可能数十万,所以需要pagination,于是乎我们又开了一个meeting让我加一个API且改前端query active discount on Vendor,因为我的manager是skip manager 比较忙,所以recurring meeting是两周一次,而且老板基本上不怎么参加standup,我下一次给老板展示的时候就是第8周了,这次是version2,老板这次接着说了download funtion你有么,我说没有,老板说这个比query还重要的呀,因为query 只是support SDE,download是support managers的。Download large excels这个功能真的是totally new to me 而且mentor和大哥原本打算download function让他们自己来做,所以那时候他们也不太清楚具体的技术比如避免out of memory,另外是即使功能实现了,latency如果太长的话,也需要换workflow的。实话说此时我的心态已经不太好了...于是开始加班research实现,然后进行latency test,比较幸运的是,research后发现难度不大,million records的excel generation and downloading最后也是两分钟多点,用户能忍受,这才没改变原来的workflow,此时版本已经是version3,这时候我意识到了虽然是mentor大哥负责我的project,但是我的最后project要满足的是老板而不是大哥他们,而且照老板的increamental requirement update性格,不知道需要几个version才能定下project,两周一sync肯定歇菜啊,果不其然,从第九周到十一周我基本上每次update除了和大哥和mentor确认也要和老板确认,每次followup requirement update,我都抓紧改,主动骚扰,抓住一切机会能尽早和老板sync up... 果不其然总共到第11周改了7版version,其中包括了新的需求比如download需要用template,template外需要加什么字段,前端页面展示的字段及format,dropdown list出现的选项等等等等

我从开始实习到结束发了30个CR,基本上每天都能保持着三四个CR pending review的状态,隔壁组实习生总共发个8个...到10-11周又是各种需求update,从用户上看虽然就加个dropdown 选项,但是需要改的部分,包括DB Model scheme,API logic, unit test,有时候还需要code refactoring,当然也有前端显示

总结:如果为了return的话,实习间一定知道在final evaluation的时候影响对你项目评价的人最大的人是谁,我的例子就是我的skip manager,按照我的例子来说,即使我按部就班听老板的,自己先做,一步一步按照大哥定地timeline完成project,最后给老板演示的时候也得翻车。相反的我认识的学长,在亚麻实习的时候,是大哥/mentor全程负责project,老板对intern基本上属于放养状态,基本所有的feedback都从大哥/mentor那里获得,这种情况下大哥/mentor的重要程度就非常高了。另外要主动骚扰sync-up确定scope,不要等老板主动和你沟通,不知有没有其他intern和我是一样的情况,我一开始的mock基本上用处不大,从第3周到第11周始终在处于定scope的阶段,我的分析就是因为老板太忙了,很多requirement并没有在书面上或者脑中列一个list,所以很多情况下都是比如,老板给我version5以及version 6的requirement update比如drop down list的选择,完全在version1,2,3的时候就提出来。我觉得我做的比较好的一点是实习过程中从来没有因为不理解需求而step back, 尽管这样我还是用了7版version,而且给skip managerset up约 一个sync-up meeting真的是重重困难,他们太忙了,这对于开发实习生真的挺痛苦的,因为自己要take ownership,要保证make delivery in time主要是靠自己而不是mentor/大哥,最后没做完的话,mentor/大哥都不能给你背锅...

大家应该都知道最后evaluation是三方,mentor,manager,bar raiser三方会谈,但是实际上peers,mentor给的evaluation内容自己,写的self-evaluation-form也都是以军规14条为基准,在最后的last-day-meeting老板给我大家的evaluation feedback以及是紧扣军规14条的,所以以后将要亚麻实习的同学,可以想一想在实习的过程中有什么行为example可以扣上14条的,老板对我的feedback是deliver results(of course),bias for action(没等需求完全确定提前自己impelement),take ownership(From scratch,需求上就问,一直在催CR, 催meeting)

还有我intern开始之前有看过帖子,说因为不与colleagues交流因为交流问题被卡return,我其实在实习前也担心这个问题,万一自己的project和别人没啥关系呢,万一没什么交集聊什么呢。其实这个基本不用担心,因为即使你的技术无懈可击,没有什么实现不了,需求上的问题一定要与别人交流,CR大概率需要催别人,CR的feedback也需要经常讨论,反正需要交流的地方非常多,如果是deploy这类的问题,可以不用一直怼着mentor问,多问问其他peers(如果人家不太忙的话)

最终能做完project拿到return,也还是要感谢我的mentor,以及我的colleagues,我的mentor是个国人小姐姐,对我更是一个朋友,虽然技术上mentor对我的帮助有限,毕竟人家做的和我的project交集不大,但是她会指出我的一些SDE的practice上的不足,比如如何和别人问问题,如何写doc,提供resources,deployment上也对我很多帮助。大哥是一个印度小哥哥,超级忙,所以回消息慢比较慢,但是慢慢接触发现人超级nice,meeting的时候很有耐心,即使我问题能想到的都问完了,他还是主动在问我有没有其他问题,而且chime上说这是我的blocker,他就会之后忙忘回来帮我。另外一个SDE3小哥哥,他是俄罗斯人,我的80%的CR都是他approve的人家很忙但是让人家帮忙review我的CR从来没有不耐烦,作为一个senior天天被一个Intern 催review CR的小哥哥真的为难人家了,mentor也调侃我,说我天天在chime上催,催完在standup meeting上又催



评分

参与人数 19大米 +122 收起 理由
redemptionnuo + 3 给你点个赞!
hhappy + 1 给你点个赞!
whdawn + 10
jshalyf + 2 给你点个赞!
斧声烛音 + 2 欢迎分享你知道的情况,会给更多积分奖励!
admin + 50 很有用的信息!
93Mmiles + 2 欢迎分享你知道的情况,会给更多积分奖励!
sunyt + 2 给你点个赞!
ItsJavert + 2 很有用的信息!
ikol1729 + 2 给你点个赞!

查看全部评分


上一篇:来微软Azure之前我建议你慎重考虑。
下一篇:黑车公司四年从new grad到L5踩尽雷区辛酸史
我的人缘0

升级   14.93%

 楼主| KT的鱼 2020-8-10 00:46:00 | 显示全部楼层
本楼: 👍   100% (3)
 
 
0% (0)   👎
全局: 👍   97% (127)
 
 
2% (3)    👎
我实习没开始之前我也有个困惑:“遇到问题,一个劲儿的钻研不问mentor/colleague,会被认为communication不够,老是问问题会被认为dive deep不行”,这里我想说一下我个人的感受
PS:我不属于create AWS infra from scratch所以难度相对小一些,我的经历不一定所有人都适用哈,请不喜勿喷
我的实习过程中大部分technical问题和deployment的问题可通过内部sage解决,像cloudAuth onboarding,以及创建IAM这种配置问题一般有单独的wiki介绍,以及public AWS文档
什么问题该问呢?
1. 像前面如果牵扯到组内architecture,business context,配置部署这种需要wiki,其他文档资源link的可以多问,mentor或者colleagues会很乐意给你的,因为换位思考一下这个根本花不了多长时间,还能earn trust,何乐而不为?这里说一下,亚麻内部wiki感觉不是很好用,关键词有时候换个大小写,加个space,都能查出截然不同的东西... 所以有的时候对于intern来说光凭自己臆想的关键词可能查不到很有用的资源

2. Use cases多问, 我说的是一些use cases,在与customer讨论requirments的过程中可能并没有cover到,而且像我,作为一个新人business context+我自身反应能立也不快的 的人 都是需要时间去消化meeting内容,然后慢慢梳理才能发现一些没cover到的use cases,这时候应该把他们整理出来一一提问(better not in chime,and better organzie them together)

3. wiki/sage里的表述让你不理解的地方多问,这里提到了前文说的wiki,这里说一下内部wiki文档的质量很多没法和public文档质量比,无论是措辞,完整度,上下文逻辑,而且有的很多outdated的文档也没人会维护... 这里的上下文逻辑什么意思呢,举个例子:文档XXX... 步骤n,presequites is A,A完成之后我们去做BC... ;BC都在当前页面,注意这里的A可能是一个link,等你点进去之后,你会发现 文档TTT, D is presequisite of A, to finish A, you also need to coplete J,K,L. 好家伙,J,K,L虽然还都在当前新的页面里,D又是一个link跳到别的页面去了,循环往复,奇妙的事情出现了,深度优先遍历这些redirect link,其实能发现是个环。尽管如此我还是自己花了好长时间梳理了逻辑流,因为像文档上下逻辑问题指能靠自己。。问别人都不知道怎么文,什么可以问peers呢,比如这个文档1里的partA的部分咱们的service是否符和它的要求呢,咱们是否需要做呢 - 因为这里牵扯到对已有service架构的background knowledge,我是不太清楚的?还比如,他说的step1里的M operation只是大概略过了,没说具体怎么操作啊,有没有文档可以去看呢? 最后切忌把一整段贴给colleagues问他们这段说的什么意思... 问题尽量细,而且尽量确保在文档里确实查不到了再问

4. business context, 注意这里如果别人都和你说过/或者别人给你分享的文档里有介绍,你没听清/没看到 还问的话超级减分.... business context我真的是两眼一摸黑,我们组没有比较formal的文档去描述通用的业务逻辑,而且我根本没法从Entity Model/DB Scheme推测出Entity Relationship,像Emtity Model/DB scheme中无法定义constraints,但是business上它是有的,比如Enum1里有ABCD 4个value 和 Enum2中有EFG 3个 value. 实际上enum1选择了A,enum2就只能选FG... enum1选择了B,enum2就只能选F...等等,完全就是business model constraint,看code是完全看不出来的,没有document的话,这些东西只能自己问了

5. 一些在sage上查不到的technical问题,其实种类5在我实习过程中也就寥寥几个,matbe <= 3, 我印象特别深有一次我在standup meeting上提出来,我的大哥说了一句never met this probem before,然后就和另一个senior讨论起w我的这个问题来了,看到两个工作了7,8年的在讨论我的问题,有种莫名的成就感在里面....

6. 为什么User需要这个O function,这个o field,为什么User不需要B这个function,这个b field 这个是我自己做的不好的一点,在最后的老板给我evaluation中也建议我improve,我在实习的过程中过多的关注于理清Entity Relationship,考虑所有的corner use cases,当然这是好事儿,但是这都是technical details,我还应该从用户角度出发,去理解为什么他们的motivation,除了他们要求的,你还需要考虑未来的扩展性,你还能为他们在为来提供什么,我想如果我这点做的好也就不需要7版revision了,但是话又说回来,有一部分原因其实是除去我的project相关part的business context不是很关心,业务也不精通,因为我也不是PM,VM,我也不需要天天和Vendor打交道,但是老板的出发点是好的,因为我现在完全处于老板让我做啥我做啥,但是我觉得如果某一天当老板问我,加上b,c,d这个字段吧,然后我能理解他的motivation,并且能给出自己的见解,胸有成竹的提出补充u, f, g,就能很好了. 这个需要日积月累,怎么做呢,或许再给我一次机会,我会每天从DB里抽出一个字段在team里问一下,Vendor manager/Product Manager他们需要用这个字段做什么吧...

接下来说什么问题不该问:
1. 别人给你发的resources有明确答案的不该问,resources没读透的问题不该问(如果那句/那部分没懂当然可以问)

2. sage,google,wiki,stackoverflow上能根据关键词轻易找到的不要问(不知道关键词是啥,可以问mentor关键词,然后自己去找)

3. 对于自己没打log,或者打了log没看,没有根据log/exception一些关键词没查过的别问(log没找到存在哪可以问)

还有一个是我对我自己在实习开始有的一个误解做一个纠正
“在问别人问题之前首先描述一下自己做过的research,显得自己dive deep”- 这个对于in-person适用,对于chime聊天只有像我那样的耐心的mentor可能看,如果mentor在on-call或者其他senior的engineer跟本没功夫去看你一大段问题描述+research,我这么干过,大概率就是人家并不会理你,能用简单几句清晰描述一下问题就已经很不容易了,所以我很少在chime上问senior engineer。对我个人而言,如果menor也不会的问题需要问senior,最好的问问题的机会在standup meeting(别占用太多时间5-10min以内),通常比较资深的enginer 大概会告诉你尝试一下ABC,如果我们已经尝试过了可以当场和他们沟通说不work,这样还有一个好处是,组内内部所有人都会去回想一下是否和你有相似的问题,这个效率真的很高,强推!而且最后老板给我feedback的时候还夸我这点做的比较好,因为你即使点名问了同事A,同事BCDE和manager都能看到啊,这样也能凸显自己的communication和ownership

评分

参与人数 7大米 +115 收起 理由
kissorkill1926 + 1 赞一个
mereT + 1 赞一个
hhappy + 1 很有用的信息!
whdawn + 10
admin + 100
yanliangwu + 1 赞一个
JFreeman + 1 赞一个

查看全部评分

回复

使用道具 举报

我的人缘0

升级   33.75%

本楼: 👍   0% (0)
 
 
0% (0)   👎
全局: 👍   0% (0)
 
 
0% (0)    👎
药厂实习的return怎么发放呢
回复

使用道具 举报

我的人缘0

升级   2%

医疗兵 2020-8-14 17:58:48 | 显示全部楼层
本楼: 👍   0% (0)
 
 
0% (0)   👎
全局: 👍   91% (11)
 
 
8% (1)    👎
为了生活呀
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号

本版积分规则

隐私提醒:
■为防止被骚扰甚至人肉,不要公开留微信等联系方式,请以论坛私信方式发送。
■特定版块可以超级匿名:https://pay.1point3acres.com/tools/thread
■其他版块匿名方法:http://www.1point3acres.com/bbs/thread-405991-1-1.html

手机版|||一亩三分地

Powered by Discuz! X3

© 2001-2013 Comsenz Inc. Design By HUXTeam

Some icons made by Freepik from flaticon.com

快速回复 返回顶部 返回列表