work simulation

https://www.1point3acres.com/bbs/forum.php?mod=viewthread&tid=445121&highlight=amazon%2Boa

Work simulation(原则有先后顺序) 目前两大做题中最重要原则：

1.requirement排在第一，deadline第二。

2.有manager出现的选项无脑选manager，manager就是一个组的地头蛇。

amazon9条主要原则

原则1：客户是上帝，requirement优先，任何影响上帝的事情都不能干，如某个requirement影响了上帝的体验，你就是死键盘上也不能砍了，宁愿miss deadline

原则2：为长远考虑，即客户几年之后可能会出现的需求也要考虑到，不会为了交付短期的deadline，而牺牲长期的价值。（比如 global api 和 local api）

原则3：最高标准，“最高”对应上面的“长远”。

原则4：一般情况，能请示manager就请示manager，manager一般不会出错

原则5：速度很重要，决策和行动都可以改变，因此不需要进行过于广泛的推敲，但提倡在深思熟虑下进行冒险。

原则6：不需要一定要坚持“非我发明”，需求帮助也是可以的，四处寻找创意，并且接受长期被误导的可能

原则7：敢于承担责任，任劳任怨，比如领导说谁会java，你会你就跳出来说我会

原则8：对问题刨根问底，探究细节

原则9：服从大局（团队比个人重要）

打分不是关键，排序才是关键。大部分情况下其实并没有deadline 和 requirement谁更好，更多还是在这个组合中你对ddl 和 requirement整体的权衡。每个选项可以评1~5分，most effective 是5，然后1是least effective 刚开始让你看一些介绍amazon工作环境的视频 1.上来给一段video，场景是项目的晨会，就是把team正在推进的项目描述一下，期间会有多个项目和你有关系，后面会遇到 2.进入工作界面，可以看到接受到邮件，接收到的instant message 3.进入工作状态。会有同事给你发邮件，发信息。需要你对他们提出的问题做一些判断，也就是给解决问题的选项评分 4.一个21题，有log分析bug，有给报告出问题结论，有判断项目走向的

情境1：给图书馆写图书推荐系统，关于book api 两个人，在表达不同的观点. 选择：tell me more 一开始其实每个人都在强调自己是对的，即使有一个人更对一些，也应该选tell me more（原则8），选了之后会得到更多信息

情境2：选图书馆的服务器有没有开放关于实体书的api 两个小哥讨论图书推荐的api应该是自己做还是用现成的。自己做api覆盖面广，但是due赶不上，别人做的能赶上due。 requirement优先（原则2），tell me more层层递进

情境3：经理说咱们最近服务器老挂，什么情况？先选看internal bug的记录选 I think service 3 is the problem, but I would like to see another report to confirm 烙印，义正言辞说自己做了20年服务器，不可能有错误，刚刚调试过服务器，不可能是内部错误。选自己去查，问题的关键在于不要麻烦别人

增加开发过程中测试的时间/测试覆盖更多case，放5

写Manuel test，放3

还有个是unit test，也放3

增加QA的人手，放1

让客户来当小白鼠发现问题，放1

情境4：Amazon recommendation system item，给你推荐一些你感兴趣的item，

第一个issue总是失败， --> 第一个问题是因为username 太长所以一直报错

第二个issue总是显示germany --> 第二个问题是因为他用proxy的name来决定是不是语言了。

情境5：德国amazon除了什么问题，让你看log回答问题。问你大概哪里.除了问题亚马逊推荐广告，给英国人推了德文广告，给你log文件，问你可能在哪，找bug in error log

情境6：员工们讨论case media network服务器最近好多compliants 有德国的，有invalid recommendation，有返回404，找出错原因的相同点德语因为服务器，一个因为用户名太长，一个是有些用户的语言变成德语

情境7：具体客户ddl 只有两周，两个方案，延到四周，做完整。另一个说先实现一部分功能做个demo，再慢慢做。

先做demo放5，