上一篇文章我们提到，在面试当中，传统的 STAR 已经不再是最好的框架，
在面试时间紧凑的情况下，使用 CAR 来帮助我们精简故事、聚焦在重点上。
这篇文章会专注在亚马逊中几条重要的原则，
主要是挑选:
1. 在面试 5 年以内经验的人重视的原则
2. 我认为最能够帮助到台湾面试的原则
这些原则分别是:
Bias for action
Have backbone; Disagree and commit
Ownership
这边我们就来一一解析，这些领导力原则是代表着什么，
我们可以怎么透过这三个原则规划我们的故事。
Bias for action
Speed matters in business. Many decisions and actions are reversible and do
not need extensive study. We value calculated risk taking.
永远记得一件事情，现实跟理想永远是有落差的。
在理想中，专案应该足够完整、需求应该足够清晰、
开发时间应该足够我们把软件开发流程都达到一定品质。
现实中，我们会面临有技术债的专案、模糊的需求、变动的开发时间，
而在这些不稳定的因素下，有个更重要的事情 : 速度在商业的世界中，非常重要。
因此，怎么取舍，变成困难的课题 —— 所谓的取舍，
就是你在多个当下差不多的选择中，做出了决策，且明白你的机会成本。
在亚马逊的面试中，不会有机会让你讲出完美的情境，
因为完美的情境在现实生活中很少出现。
绝大多数的时候，你会被迫做决定，例如：
在资讯不够清晰的情况下，你要怎么开始专案?
在时间不够的情况下，你要怎么达到目标?
这两个问题在回答的时候，不只要说明你当时怎么做的，更重要的是，你放弃了什么 ?
你为什么在多个选择当中选择了现在的方案?
举例来说:
我必须在五天内让系统在某个特定日期应付大约平常 10 倍的流量。经过分析后发现，
大部分功能透过加机器就能撑住，但有一个功能的水平扩张性比较差，
单纯加机器无法解决。
为了避免这个功能变成系统的瓶颈，我们决定把它独立出来，
用 serverless 的方式来处理。
这样可以让这个功能在流量高峰时自动扩充，也不会影响其他服务的稳定性。
这样的回答其实已经很完整，符合我上一篇文章提到的 CAR 架构，
最后补上更具体的作法，就是一个四平八稳的回答，
但这样的回答，在这个领导力原则下，还有欠缺。
欠缺什么 ?
我们没有提到我们承担了什么 Calculated Risk ，以及我们当初是跟什么方案比较。
什么是 calculated risk ?
指的是在时间与资讯有限下，仍评估风险与效益，做出快速且有根据的决策。
因此第二段可以改成：
为了避免这个功能成为系统瓶颈，我们评估了两个方案。
第一是改用 serverless，在高峰期自动扩展；第二是调整商业流程，降低系统压力。
Serverless 的主要风险是时间紧迫，无法完整验证整体架构，
只能透过压力测试来模拟实际流量；而流程优化则可能影响使用者体验与转换率，
且会降低我们取得的用户资讯。
最终我们选择 serverless，以保障使用者体验与商业价值，我们也做了两项风险控管：
一是在活动当天即时监控 log，
二是让失败的请求能 fallback 回原流程，确保不影响核心使用者流程。
在商业价值与系统稳定之间，我们选择了商业价值。
这样的回答基本上已经符合 bias for action 的要素：
在时限下达到目标，且分析了风险。
而面试的时候，除了符合领导力原则外，还需要做事实查核，也就是了解故事的真实性。
方法会是追问技术细节，例如：瓶颈是什么能详细说明吗？为什么不能水平扩张？
其他流程可以水平扩张的原因是什么？你们怎么做压力测试？你们怎么做 fallback？
Have backbone; Disagree and commit
Leaders are obligated to respectfully challenge decisions when they disagree,
even when doing so is uncomfortable or exhausting. Leaders have conviction
and are tenacious. They do not compromise for the sake of social cohesion.
Once a decision is determined, they commit wholly.
关于 have backbone 这件事情，大部分的工程师其实多数都有这个特质。
而这个领导力原则有趣的在后面：Disagree and commit。
这边的重点有两个：
1. 整个叙述更多是表达自己的意见、不轻易妥协
2. 当团队做了决策以后，就坚定执行团队的决策
这考验了一些重点:
1. 当你不同意对方的时候，你的沟通路径是什么? (准备一个成功说服且成功的故事)
2. 当团队做了你不同意的决定后，你的后续是什么? (准备一个自己看走眼的故事，并说
明怎么提高未来的判断力)
我过去和上百位工程师一对一讨论职涯的时候发现，许多人做不到 disagree and
commit 的根本原因之一，是他把专案的成败与个人的成败做了绑定。
当自己的意见被否定的时候 > 我是个失败的人
当自己的意见被支持的时候 > 我是一个有能力做正确决策的人
但面试者是否失败、以及是否有能力做正确决策，都不是这个领导力原则在考验的。
理论上，每个专业的工作者，
工作都存在着一定机率会失败，也一定会在某些时刻做出错误的决策，
因此，不存在一个永远成功、永远做正确决策的人。
那这个领导力原则在考验什么?
如何沟通、如何面对人际互动上的挫折、如何积极面对挫折。
在自己的意见被采纳的时候，强调自己的沟通策略、如何分析以及求同存异。
在自己的意见不被采纳的时候，叙述如何改善自己的判断能力、沟通能力。
这个领导力原则相对来说，故事并不复杂，因此我就不举例了，
想额外补充的是，专案的成功让所有人与有荣焉，但专案的失败并不能否定个人的价值。
面试前，尽量能让自己对所有的专案成败抽离，
成功，是团队做出了正确的决策，
大家分别扮演哪些重要的角色因此专案顺利完成。
失败，整个开发流程出了什么问题、自己身为
流程的一份子如何改善下一次的开发，在自己能改善的范围内降低风险。
如果不幸身处糟糕的环境，我们身为团队的一员，我们无法完全改善；
能做的，就是降低风险、提高自身的实力，到下一个更好的环境。
情绪，是值得我们在离开后放下的包袱。
Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value
for short-term results. They act on behalf of the entire company, beyond just
their own team. They never say “that’s not my job.”
这个词在台湾职场，似乎没有很好的翻译，
且大家对于 ownership 的定义可能多少有点不同。
从某些老板的角度，整段亚马逊的解释，他只看到了最后一句:
“员工不该说"那不是我的工作"。”
从亚马逊的角度， ownership 很清楚地在讲一件事情: 长期利益。
当短期利益跟长期利益冲突时，选择长期利益；
当我的长期利益要实现的前提，有部分工作不在我原本的职责，跳进去协作。
所谓的 ownership 不是把公司当成自己的公司，
而是工作中衡量所有工作决策时，心中都有公司的长期利益。
常见的几个类型的问题:
Outside responsibility
这个我相信大家工作中多少会遇到，
那驱动你去做不属于自己工作范围的工作，目的是什么?
单纯的时间太多? 那为什么不做同组未来的票，而是做不属于自己范围的工作?
单纯想帮助人? 那你会不会遇到太多需要帮助的人，而没顾好自己的事、燃烧过度?
最政治正确的回答是:
当我完成了这个原本不属于我责任范围的事情以后，
对公司、对我的组长期是有帮助的，且指出帮助是什么。
Own the outcome, not just output
这个通常会出现在追问的部分，我的 mentor 说，在亚马逊的面试中，
一般都会收到规定要在这场面试中考核那些领导力原则。
如果面试者已经达到了面试原本规范的原则，那么，可以再追问的时候考核其他的原则，
就会出现，原本你认为他在考 A 原则，后面却拐弯到了 B 原则。
这样的情况，多数是加分题。
那么，这句的重点是什么?
你在回答每个技术故事以后，心中都要知道这个服务的几个 metrics 。
服务稳定吗? 使用者满意这个服务吗?
这个服务当初被设计的目的是什么、有达成吗?
现在否有更好的方式可以达成当初的目标(商业角度、程式架构的角度)?
因此，要学着在工作中，定义好所谓的 "完成"，且能够衡量这个 "完成"。
最简单的就是 availability、response time、error rate、QPS 是否达到目标，
思考这件事情其实不会占用工作太多的时间、要能够简易的监控成本也低。
心中常存这些指标，会让你成为一位思考更全面的工程师。
最后，
从某些员工的角度，觉得 ownership、甚至整个领导力原则都是员工的自我 PUA 。
我的看法是，抛掉专案成败与职涯成败的绑定、甚至与个人成败的绑定，
当我们能够抽离情绪时，会发现亚马逊的领导力原则，反而是提供了一个思考的框架，
让我们可以不将个人价值绑订在专案的成败上。
成功，有我的努力与贡献，
失败，我们专注在下次的降低风险上面。
—
这次讲解了三个我认为最适合台湾工程师在准备行为面试时，需要参考的领导力原则，
下一篇，估计也是整个系列文的最后一篇，
我会分享实际上我怎么准备、整理我的行为式面试，
包含了思考脉络、如何自我检验、练习等等。
—
延续上次做的公益一对一职涯讨论， 我想将这个活动变成自己长期会做的事情，
和上次的差别是，这次我希望来找我的人，
可以挑选任何一个公益团体做出任何金额的捐款 —
我希望每个收获帮助的人，同时也能够回馈给这个社会。
详细的规则写在 Calendly 预约表单内。
https://calendly.com/riverski/sde_career
另外，我和 roy3550681 有在规划做针对 junior 工程师的 mentorship 计画，
目标是协助工作 1~3 年经验且职涯上卡关的工程师，做职涯的成长，
如果大家有什么想法，欢迎写信给我，
预计 25 年 Q3 等我俩都在新工作上熟悉以后，会启动这个计画!

看来亚麻的军规一样可以套用在别的科技公司上面呢………只有第二点Have backbone不怎么同意，你要有backbone，除非你跟上司很麻吉，上司也愿意站在你这边帮忙。要不然还是得乖乖地向现实妥协…

推推！感谢分享

ownership前提是"do other's job"没好处的时候真的不要do但是我听过的ownership几乎都是去硬找出好处……然后结果变成分工不明确 责任不清楚 大家浪费时间收烂摊也看不出有什么long-term好处

感谢分享！

先推，吃饭来看

推推

感谢分享

认真分享，给推！^_^

推

感谢分享

推

先推！

受益推

push

感谢分享

ownership感觉会被台湾老板无限上纲...XD

受益良多

ownership 的负面就是 情绪勒索(为了公司好)当然,好的公司会让多做事的人可以往上爬/这样就是正面的但是人治的缺点就会逐渐放大 公司就不会走向更好的治理方法而会走向事事都是逼着人去撞墙 撞得好就升官也就是很像台GG目前的文化.当然我不是说台GG这样完全不好就是进去的人要知道台GG就是这样的文化 欢喜做甘愿受就跟AMAZON明讲他们文化就是高压榨不是开明的公司文化

嗯嗯。我最讨厌那种拼命买版面，说自己是"幸福企业"，但骨子里完全不是那么回事的心口不一企业 =_=#血汗公司也没什么，就摊在阳光下，愿打愿挨，光明正大！

推推 感谢分享

讲的好听但亚麻里也是不少没ownership的

推分享。但理想与现实backbone/ownership也常不一样

推推 最近在准备面试 觉得很受用

工程师的本质还是技术，你要思考这些东西基本上就是要往上升了

以前还很认真看待这种面试 后来发现根本是演戏大赛面试者在演 面试官在帮你的戏打分 真的进去后就知道没人真的信这些鬼东西 反正最后就是想往上爬的就自己找事做 想coast的就安静一点 被pip就打开leetcode