分享自己准备behavior问题的笔记

无意中看到了自己之前写的behavior笔记。因为感觉这个笔记开启了自己的沟（吹）通（牛）能力，所以拿出来和大家分享


precaution:
- 这个是面试亚麻的那天早上写的，所以基本在围绕亚麻价值观和自己的经历（简历）写。但是我感觉其实之后面的每一个公司，基本都可以照这个套路走。
- 作为newgrad平时没有啥people skill的经验，并且零teamwork经验（连小伙伴一起project的经历也是0），因此可能写的答案里可能有很多毛病。但是换个角度大家可以参考下我address这个硬伤的的方式...
- 自己的背景不太typical，所以里面的例子应该不能用在大多数人身上。我还是把例子放在那里主要是想具体表示一下故事需要讲多细。大多数公司讲到这个level已经够细了，但是亚麻会问更细的细节。

- 笔记里的例子是真实的，但是面试的事后有根据对方的问题稍微改了一下故事以更符合问题，真实度70%-100%不等。我还是推荐准备一些真实的故事，以便需要的时候填进去细节。

以下是笔记
----
把握大方向

Custom obsession强调拥护体验，围绕用户需求进行设计

Think big 有大局观

Insist on the highest standard 追求完美，不会满足于fix小问题

Invent and simplify 不拘泥于现有技术，愿意发明新算法来解决新问题

Frugality 不盲目增加成本

XXX project

- 跳出一般对XXX问题的认识，更多地考虑XXX是否是一个用户愿意用的方案。它和其它方案的差距在哪

- 比如设计的时候会考虑用户交互的effort，假设是否实际等等

- 这个虽然需要重新设计以跳出传统XXX的框架，开发成本更高有一定风险，但是觉得最终会带来良好的用户体验

frugality

- 一般YYY的办法是blahblah。这个setup很烧钱，研究了一番后使用了一个blahblah替代方案，它的成本是ccc块钱。

- 即使公司很有钱，设计project的时候还是需要考虑硬件成本，因为需要考虑用户是不是卖得起。

面对冲突／困难

Ownership 对project有责任心，当作自己的career来做，而不是觉得就是一份工作

Have backbone 有不同意见要坚决表达出来，但是群体意见形成以后，还是要commit wholely

Bias for action及时动作，合理分析风险

Earn trust 愿意听同事的意见

Deliver results 及时deliver结果，respect deadline

Ownership - backbone - deliver results

- 去AAA公司实习的时候一开始给的问题是从XXX角度做YYY问题

- 提出不同意见，觉得应该把问题设计得更用户友好...

- mentor觉得可能问题太难做会有风险，于是拆成几个小块分别做出initial结果出来，分别设定了timeline/目标。 然后自己还设定了每天的小目标，尽量让所有的目标都是measurable的（比如具体小目标是blahblah，评价标准是blahblah)

客观评价

Are right, a lot 客观全面分析，对不确定的问题有vision

Dive deep 碰到问题的时候通过metric有逻辑地解决，用数据backup，而不是随便make statement

Bias for action - earn trust - deliver results - dive deep - are right a lot

- 碰到过做XXX模块的时候，几个方案的相持不下

- 每个方案都是直觉上觉得自己的idea最好，但是都觉得自己没有特别solid的理由

- 最后决定先建数据集，罗列每个方案的假设，然后用数据集验证假设

- 实验的顺序是先做好做的，再做难做的

. From 1point 3acres bbs

dive deep

- 在AAA公司实习的时候，做的project比较成功，在领域里挺有impact的，但是我自己觉得对其中一块很不满意

- 实习结束以后用业余时间开始研究剩下的一块，自己做了一些preliminary experiments，又摸索了一年

- 感觉靠谱了以后回去找AAA公司进行了第二次合作，又发了第二个paper

其它

Learn and be curious 爱学习爱探索

Hire and Develop the Best 愿意提拔（帮助，support)一样优秀的人(同事）

身边很多做不同研究方向，各种专长的大神，经常跟他们讨论他们的project

- 认为跟他们讨论重在交流，不是特别在意credit。从中可以学到东西本身是开心的事。

- 有时候学的东西从知识上来说是没用的，但是方法是有启发性的。

Behavior问题

why amazon

大的busines platform，user base很大，觉得可以接触到challenging又实际的问题

很多和engineering的interaction，觉得可以得到更多engineering sense，学习怎样deliver product

亚麻本身technical和business都很重视，也比较感兴趣培养自己的business

最自豪的项目

XXX

- 真正地让我开始考虑是做难的问题重要，还是做实际的问题重要

- 从更深的层次考虑了很多一般做XXX的人不会考虑的问题，感觉自己的全局观巨大地提高了

- 是做过的最复杂最难的project，从头到底很多innovation，intern结束的时候file了N个patent，很有成就感

对一个问题，和老板同事发生了争执怎么办

如果知道同事是错的，怎么办

如果一个事情决定不下来,deadline又要到了，怎么办

- 先考虑争执的点是哪里。是确定同事是错的，还是两个alternative觉得自己的略好一些。

- 还有考虑时间是否紧迫

- 如果同事是错的，那么还是要及时跟同事沟通。用data和逻辑说服他。

- 如果只是不同alternative，那么特别是时间不够的时候，就不坚持自己的方案。

- 如果时间也够，那么就跟同事罗列优缺点，两个alternative先试容易验证的一个。

例子

- project里一般不碰到这种情况，因为大多争议可以通过实验比较客观解决掉。

- 写paper的时候碰到过。我想用方式A写，老板last minute说想用方式B重写，我个人觉得方式B过于aggressive, 也许收益大但是风险更大。

- 最后coauthor把票投给了老板（因为觉得老板投paper比较有经验），于是focus on B，加班加点把paper改完了。

- 投了之后paper跪了，原因和我预测的一样...

- 事后评论：A和B的差异完全取决于主观因素，所以B不是错的，coauthor相信老板的经验也合理。最后paper跪了觉得也没事，因为事先整个team已经选择了take risk，那么就愿赌服输啦。

怎么解决很tight的deadline

怎么控制项目进度

怎么测试项目

如果再多点时间怎么改进

- 事先定好小目标，确定每个目标expected完成时间和最长完成时间，最低完成度和最高完成度，排好优先级

- 和同事／老板讨论confirm这个计划是可行的（尤其是如果需要同事配合，需要同事确认能allocate相应的时间／资源）

- 如果发现这个plan表明了解决不了deadline，那么需要跟老板／比较有经验的同事谈，看是找更多的resource来加快进度，还是推迟deadline，以免custom有不合理的期待，还是先把基本功能做出来让custom能先使用

有没有part是teammate来不及完成，你帮他们完成的

- project里不太有，因为大多项目是1-N个mentor和我。XXX项目里公司那边的engineering更多定位在和我一起工作的peer，但是他们的时间管理非常好。只有一次YYY实验确实很花时间很困难，我们一起加班了几天完成的。

- 别的场合有。比如实验室study group，别人忙的时候自己会多做一点supporting的活。但是这个帮助是相互的，我忙的时候别人也会support我，所以觉得挺好的。

有没有在manager不在的时候做决定的事

- 老板大多数时间会尽量保证meeting，所以这种经历很少。

- 有一段时间老板出差out of internet，这个时候自己定计划，跟周围同学讨论，看他们从outsider的角度怎么看project。总之希望通过得到尽量多外部意见防止自己走偏。

- 老板back on line之后第一时间跟老板sync

有没有解决customer last min 需求的事

- 因为research project，customer是潜在的（将来可能用这个方法的其他researcher，或如果工业化以后的用户）。所以没和具体的customer打过交道。

- 不过如果碰到这样的问题，会看需求是需要小fix，还是大改变。

- 如果是可行的小fix，或者team allocate多点resource可以解决的fix，会立刻根据customer的要求改变

- 如果是大改变，可能会跟custom商量先给customer一个可用的东西，和一个满足customer需求的timeline.


补充内容 (2016-11-9 01:02):
果然笔记格式被screw up了，大家将就着看吧，sigh...

(工作不到一年后的感想）
- 拼死拼活地赶deadline是很不好的，特别是对team来说。如果真是有人一直都需要赶deadline，需要看看在干的是不是最重要的活，team内部有没有load balance好，是不是该招新人了，etc。避免delay重要的是定期check progress，flag issue/risk，而不是指望到最后一刻加班搞定一切。
- 追求high quality是好的，但是如果一段code就是为了early learning的，code写得有点烂没关系。但是大多code要保持一定水准，避免tech debt。
- 同事和自己的时间其实也很贵。所以小钱能买到的时间还是花钱吧。。。（比如买一个比较差的且没有scale需求的设备需要一个researcher多花几个月设计一个复杂的算法，不如买好点的设备）
- 和同事意见不同：这个多半是看问题角度不同，或者miscommunicate引起的。双方都多听对方的意见很可能会带来更全面的理解和最优的方案，所以这个事是个合作，不应该看作矛盾。如果多个方案相持不下，让owner定优先级，不要浪费太多时间。
- 和老板意见不同：其实很多公司是ic driven的，所以很多老板其实愿意听ic的。对有争议的问题可以问问别的ic怎么看，最后回到和同事意见不同的问题。

mark hao tie

mark。。。。。。。。。。。。。。。。。。。。。

好棒啊，赞一个！

mark，明天面试， finger crossed

好帖！mark …

楼主总结得好到位

很不错，感谢楼主分享！

马克一下

mark mark