19年西雅图亚麻实习体验

如题 本人前几天刚刚结束在亚马逊的实习工作 已经顺利拿到return 最近闲的有点蛋疼 所以就来地里边分享一下自己的实习体验~
先说一下我本人的实习过程吧

本人被分到AWS下边的一个组里边实习 这个组主要负责开发亚马逊的内部工具 manager和mentor都是美国人

组里人对我的实习项目是比较上心的 他们在我来之前 就花了很久的时间来讨论我的项目 确保这个项目既能满足内部客户的需求时也不至于太难 使得我在12周的实习期间无法完成
我的项目是一个全栈项目后端用Java 前端是Ruby on Rails 同时也有涉及Spring 第一眼看上去挺简单的 而且大部分有现成的代码可以模(chao)仿(xi) 所以我就觉得这个项目也挺简单的 每天朝九晚五不加班应该能够做完 所以刚开始的几周 我就没怎么加班 项目进展的也比较顺利

结果突然有一天 manager跟我说叫我写一个design doc 然后交给全组review一下 因为当时我项目进行的比较顺利 所以就把大把的时间投入到design doc上 我还在review之前排练了好几遍 以便到时候给组员讲的时候能讲的流利一些 结果在review meeting的时候被痛批了一顿 因为我的design doc没有包括user case(user case就是用户案例 就是阐述一下你做的这个项目是基于哪些客户需求 你做的这个项目能够如何解决这些需求之类的)

事后Manager 1to1的时候跟我说我在写design doc之前应该管mentor要一份样例 Manager叫我联系客户 重新写一份design doc 然后再重新交给组里人review一遍 因为我之前花太多的时间在design doc上了 所以进度已经有一点点落后了 如果接下来再把全部的经历花在重写上 肯定会落后的更多 所以我就跟Manager请示了一下 说能不能一边写design doc一边继续往下做 因为接下来要做的工作一部分我想当确定应该怎么做(毕竟有代码可以参考)Manager同意了 并且说他很希望我能把这两件事情同时做好

为这事儿我也跟我的mentor约了一次 1to1 我mentor是比较喜欢替我背锅的那种人 一开始疯狂把我的错往他的身上揽 说他一开始检查我的design doc的时候没有意识到这个问题 然后他给了我一个样例 叫我按照这个写 然后发给客户 看客户有什么feedback 于是我就开始重写design doc 一点一点过User Case 一点一点画UI 这段时间我曾经一度怀疑自己究竟是不是一个SDE intern 花了两三天的功夫终于写好了 然后发给mentor mentor跟我说「我的内容写的非常好 但是语法有些问题」然后他就帮我改了一通措辞 语法 我看了改稿 感觉跟重写的没啥区别。。。 然后我就把改稿发客户了 万万没想到的是居然真的有客户会回复我这个**实习生的design doc

全组通过我的第二版design review之后 我就开始疯狂的加班赶进度 但是过程十分的不顺利 因为之前没有做过全栈项目 所以有很多代码都是一行一行抄 一行一行憋出来的 而且Spring总是报一些奇怪的错误 根本debug不出来 经常需要clean workspace然后再重新Build 这样那些千奇百怪的错误就能莫名其妙的消失 而且越往后做越发现这个项目的工作量比想象中的要大很多 因为你稍微加一点东西 就意味着你要把对应的unit test和integ test给写好 有的时候写一个integ test 五百多行就出去了 而且我们组code review是属于那种一次代码非常少 总的code review次数特别多的那种(我曾经交过1行的code review)我的code review是只有我mentor看的 组里其他人不会看(他们都很忙)但是我的mentor也很忙 所以我的很多code review不能即使的被approve,merge 导致我本地仓库后期简直乱的飞起 有的时候实在是受不了了 就提交一个新的code review 专门负责解决之前code review当中提到的问题 不然还得回到原来的分支上改 然后cherry-pick到主分支测试 再提交 简直不要太麻烦

等到还有大概4周结束的样子 我的项目已经差不多做完了 只剩最后一个小feature 我跟mentor研究之后发现 这个feature需要用elastic search做 不然就只能用比较brute-force的方法做出来 但是一者剩下的时间太短 不够我上手elastic search的 二是设计我的实习项目的时候本来就没有让我做elastic search的打算 所以最后我只好用brute-force的方式把最后一个feature给做完了 最后demo的时候也很顺利 但是还是因为时间原因没有进production(有一部分代码甚至都没有merge到主分支上) 然后最后一天的最后一个小时被告知拿到了return 还是很开心的~

当然最后还是有一点小遗憾的 感觉前期特别爱面子 觉得加班就是打黑工 导致拖到最后没有时间做elastic search 学到更多的东西 如果再给一次机会的话我会从一开始就加班

然后再给些建议吧 可能不同组之间会有些不同 大家看着采纳~

1 如果你的项目涉及前端 需要自己设计UI 平时又接触不到给你UI设计提建议的人(组员 客户)那么强烈建议去一趟UX office hour 能够很好的体现Customer Obsession(去UX office hour之后我几乎每周的1 to 1都因之收到manager表扬 最后bar raiser也被此打动)

2 虽然说亚麻玄学招人 玄学return 但是大体上来讲 只要不是被分到特别坑的组 project做完应该就有很大的几率return了 如果能进production就更稳了(lz最后没进production 但是mentor明确跟我说了没进production不要紧 组里前几年的intern最后都进production 不过我也有听说有的组的intern最后必须要进production 所以说还是得看组)不过「求其上者得其中求其中者得其下」按照进production的标准来要求自己 定是有益无害的

3 只要不是被分到特别坑的组 那么建议从一开始就加班(如果 manager mentor允许的话)很多实习生都是前期慢慢悠悠的做着project 到中期一看发现做不完就慌了 后期疯狂加班 虽然最后也都能做完 但是赶进度的过程就比较痛苦了 LZ的项目比较坑爹 强制一年半毕业 I20只给开到年底 所以如果没有return秋招上不了岸的话就要回国996了 而且7月中旬的时候还面试了字节跳动的提前批 被虐的体无完肤 感觉回国了也找不到工作 所以最后赶进度那阵子真的是挺慌 挺焦虑的 生怕拿不到return 相反 如果前期适当加班 早早的把东西给做完 那么后期就有时间做stretch work(拓展任务) 这样一是做了拓展任务 return的几率大一些 二是可以丰富自己的简历 三是可以避免后期赶进度时候的焦虑~

4 如果最后manager mentor对你的项目都比较满意 那么剩下要做的就是和manage mentor一起商量如何对付bar raiser了最好和他们提前商量一下bar raiser可能会提出的刁钻问题

5 如果发觉进了坑组 那么就抱着丰富简历的心态 leetcode走起把 带薪刷题加丰富简历 不亏好吧

以上就是我的个人实习感受和一些建议 可能不适用于所有人 总体来说亚麻的实习体验还是不错的 manager mentor 还有组里的其他人都蛮好的

manager或者mentor有问题:

  1. 早就应该开始design doc,没design写什么代码
  2. design doc有格式要求必须写哪一部分,那应该早提供模板