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

avatar 104034
hxtang
34462
28
无意中看到了自己之前写的behavior笔记。因为感觉这个笔记开启了自己的沟(吹)通(牛)能力,所以拿出来和大家分享

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

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

以下是笔记
----
把握大方向[align="left"]Custom obsession强调拥护体验,围绕用户需求进行设计[/align][align="left"]Think big 有大局观[/align][align="left"]Insist on the highest standard 追求完美,不会满足于fix小问题[/align][align="left"]Invent and simplify 不拘泥于现有技术,愿意发明新算法来解决新问题[/align][align="left"]Frugality 不盲目增加成本[/align][align="left"]XXX project[/align][align="left"]- 跳出一般对XXX问题的认识,更多地考虑XXX是否是一个用户愿意用的方案。它和其它方案的差距在哪[/align][align="left"]- 比如设计的时候会考虑用户交互的effort,假设是否实际等等[/align][align="left"]- 这个虽然需要重新设计以跳出传统XXX的框架,开发成本更高有一定风险,但是觉得最终会带来良好的用户体验[/align]
[align="left"]frugality[/align][align="left"]- 一般YYY的办法是blahblah。这个setup很烧钱,研究了一番后使用了一个blahblah替代方案,它的成本是ccc块钱。[/align][align="left"]- 即使公司很有钱,设计project的时候还是需要考虑硬件成本,因为需要考虑用户是不是卖得起。[/align]面对冲突/困难[align="left"]Ownership 对project有责任心,当作自己的career来做,而不是觉得就是一份工作[/align][align="left"]Have backbone 有不同意见要坚决表达出来,但是群体意见形成以后,还是要commit wholely[/align][align="left"]Bias for action及时动作,合理分析风险[/align][align="left"]Earn trust 愿意听同事的意见[/align][align="left"]Deliver results 及时deliver结果,respect deadline[/align][align="left"]Ownership - backbone - deliver results[/align][align="left"]- 去AAA公司实习的时候一开始给的问题是从XXX角度做YYY问题[/align][align="left"]- 提出不同意见,觉得应该把问题设计得更用户友好...[/align][align="left"]- mentor觉得可能问题太难做会有风险,于是拆成几个小块分别做出initial结果出来,分别设定了timeline/目标。 然后自己还设定了每天的小目标,尽量让所有的目标都是measurable的(比如具体小目标是blahblah,评价标准是blahblah)[/align]客观评价[align="left"]Are right, a lot 客观全面分析,对不确定的问题有vision[/align][align="left"]Dive deep 碰到问题的时候通过metric有逻辑地解决,用数据backup,而不是随便make statement[/align][align="left"]Bias for action - earn trust - deliver results - dive deep - are right a lot[/align][align="left"]- 碰到过做XXX模块的时候,几个方案的相持不下[/align][align="left"]- 每个方案都是直觉上觉得自己的idea最好,但是都觉得自己没有特别solid的理由[/align][align="left"]- 最后决定先建数据集,罗列每个方案的假设,然后用数据集验证假设[/align][align="left"]- 实验的顺序是先做好做的,再做难做的[/align]
[align="left"]dive deep[/align][align="left"]- 在AAA公司实习的时候,做的project比较成功,在领域里挺有impact的,但是我自己觉得对其中一块很不满意[/align][align="left"]- 实习结束以后用业余时间开始研究剩下的一块,自己做了一些preliminary experiments,又摸索了一年[/align][align="left"]- 感觉靠谱了以后回去找AAA公司进行了第二次合作,又发了第二个paper[/align]其它[align="left"]Learn and be curious 爱学习爱探索[/align][align="left"]Hire and Develop the Best 愿意提拔(帮助,support)一样优秀的人(同事)[/align][align="left"]身边很多做不同研究方向,各种专长的大神,经常跟他们讨论他们的project[/align][align="left"]- 认为跟他们讨论重在交流,不是特别在意credit。从中可以学到东西本身是开心的事。[/align][align="left"]- 有时候学的东西从知识上来说是没用的,但是方法是有启发性的。[/align]Behavior问题[align="left"]why amazon[/align][align="left"]大的busines platform,user base很大,觉得可以接触到challenging又实际的问题[/align][align="left"]很多和engineering的interaction,觉得可以得到更多engineering sense,学习怎样deliver product[/align][align="left"]亚麻本身technical和business都很重视,也比较感兴趣培养自己的business[/align]
[align="left"]最自豪的项目[/align][align="left"]XXX[/align][align="left"]- 真正地让我开始考虑是做难的问题重要,还是做实际的问题重要[/align][align="left"]- 从更深的层次考虑了很多一般做XXX的人不会考虑的问题,感觉自己的全局观巨大地提高了[/align][align="left"]- 是做过的最复杂最难的project,从头到底很多innovation,intern结束的时候file了N个patent,很有成就感[/align]
[align="left"]对一个问题,和老板同事发生了争执怎么办[/align][align="left"]如果知道同事是错的,怎么办[/align][align="left"]如果一个事情决定不下来,deadline又要到了,怎么办[/align][align="left"]- 先考虑争执的点是哪里。是确定同事是错的,还是两个alternative觉得自己的略好一些。[/align][align="left"]- 还有考虑时间是否紧迫[/align][align="left"]- 如果同事是错的,那么还是要及时跟同事沟通。用data和逻辑说服他。[/align][align="left"]- 如果只是不同alternative,那么特别是时间不够的时候,就不坚持自己的方案。[/align][align="left"]- 如果时间也够,那么就跟同事罗列优缺点,两个alternative先试容易验证的一个。[/align][align="left"]
[/align][align="left"]例子[/align][align="left"]- project里一般不碰到这种情况,因为大多争议可以通过实验比较客观解决掉。[/align][align="left"]- 写paper的时候碰到过。我想用方式A写,老板last minute说想用方式B重写,我个人觉得方式B过于aggressive, 也许收益大但是风险更大。[/align][align="left"]- 最后coauthor把票投给了老板(因为觉得老板投paper比较有经验),于是focus on B,加班加点把paper改完了。[/align][align="left"]- 投了之后paper跪了,原因和我预测的一样...[/align][align="left"]- 事后评论:A和B的差异完全取决于主观因素,所以B不是错的,coauthor相信老板的经验也合理。最后paper跪了觉得也没事,因为事先整个team已经选择了take risk,那么就愿赌服输啦。[/align]
[align="left"]怎么解决很tight的deadline[/align][align="left"]怎么控制项目进度[/align][align="left"]怎么测试项目[/align][align="left"]如果再多点时间怎么改进[/align][align="left"]- 事先定好小目标,确定每个目标expected完成时间和最长完成时间,最低完成度和最高完成度,排好优先级[/align][align="left"]- 和同事/老板讨论confirm这个计划是可行的(尤其是如果需要同事配合,需要同事确认能allocate相应的时间/资源)[/align][align="left"]- 如果发现这个plan表明了解决不了deadline,那么需要跟老板/比较有经验的同事谈,看是找更多的resource来加快进度,还是推迟deadline,以免custom有不合理的期待,还是先把基本功能做出来让custom能先使用[/align]
[align="left"]有没有part是teammate来不及完成,你帮他们完成的[/align][align="left"]- project里不太有,因为大多项目是1-N个mentor和我。XXX项目里公司那边的engineering更多定位在和我一起工作的peer,但是他们的时间管理非常好。只有一次YYY实验确实很花时间很困难,我们一起加班了几天完成的。[/align][align="left"]- 别的场合有。比如实验室study group,别人忙的时候自己会多做一点supporting的活。但是这个帮助是相互的,我忙的时候别人也会support我,所以觉得挺好的。[/align]
[align="left"]有没有在manager不在的时候做决定的事[/align][align="left"]- 老板大多数时间会尽量保证meeting,所以这种经历很少。[/align][align="left"]- 有一段时间老板出差out of internet,这个时候自己定计划,跟周围同学讨论,看他们从outsider的角度怎么看project。总之希望通过得到尽量多外部意见防止自己走偏。[/align][align="left"]- 老板back on line之后第一时间跟老板sync[/align]
[align="left"]有没有解决customer last min 需求的事[/align][align="left"]- 因为research project,customer是潜在的(将来可能用这个方法的其他researcher,或如果工业化以后的用户)。所以没和具体的customer打过交道。[/align][align="left"]- 不过如果碰到这样的问题,会看需求是需要小fix,还是大改变。[/align][align="left"]- 如果是可行的小fix,或者team allocate多点resource可以解决的fix,会立刻根据customer的要求改变[/align]- 如果是大改变,可能会跟custom商量先给customer一个可用的东西,和一个满足customer需求的timeline.

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