美国职场几年的工作经验，希望得到指导

我就分享一下我的工作经验也欢迎大家提出不同的意见来帮助我提高，至于我回国的原因呢？ 我觉得我觉得回国会更开心一些，事业上有更大的发展，毕竟在美国有很多不可控的因素啥的。 有些事不想写的太细，害怕被人认出来~
1. 交流上：我觉得工作中交流是很重要的，我就首先写，
1.1 老板布置的任务要好好理解意思，然后通过问问问题来make sure自己是完全理解的。这很重要，刚开始工作的时候，经常没有完全理解就开始工作，最后做出的东西跟老板想要的有出入，这种过程就很不好，一定要不停地问确保自己对任务的每个要求都是理解的。 这个过程最好发生在做任务的开始阶段，如果发生在任务过程中，这样老板会觉得你做事鲁莽不稳定，所以这部分一定要出现在任务的布置初期。
1.2 写的每一封邮件，每一个doc, 都要好好琢磨，要预先设立好audience是谁？他们会有什么background knowledge，你怎么说他们能轻松理解，并且觉得你的论述也好逻辑也好十分清晰。大家在工作中可以时常观察怎么样的邮件自己很容易理解作者的意图而什么邮件或者doc看了半天很累但没有什么收获，从中不停地学习和体会。
1.3 如果别人问的问题无法回答，一定要说自己无法回答，然后稍后达到答案之后再回答，不能随便回答。 确保自己的话永远是准确正确的。
2. 工作的过程中
2.1 无论工作的任务大小，都要好好理解所有的相关知识，也就是快速学习的能力，如果觉得那一部分有专家可以询问来快速理解就在这一部分可以去询问来得到所需要知识的pointer，这样会比自己在某个点上钻研好很多。这一部分要确保自己的理解是准确正确的。
2.2  在对工作任务有基本完整的理解之后就可以开始设计了，设计的过程中要遵循第一性原则，一切从实际的数据和情况来分析而不借助他人的中间结果。这也要求自己对前一步的理解是准确的，否则会出现一个很奇怪但并不是最好的设计。别人的设计可以参考，但要时常思考别人为什么这么设计而不是那么，我怎么样才能比他做得更好，切忌盲从。这一部分的要求是设计是要比较完整和没有明显的漏洞，对于一些明显的设计trade off 可以进行一定程度的技术分析，来应对他人可能的技术质询。不要抱有侥幸心理，不要选择自己有把握的设计，而拒绝去学习新的技术来解决问题，不要抱有侥幸心理，富有经验的工程师和老板会知道到底有没有花真正的时间在设计上。 这一部分需要征求他人的feedback来确保everyone is one the same page, 不会对你的设计感到不懂和恐慌。
2.3 然后对要做的事进行系统性的分割，确保每一个cl/diff/cr/pr都是比较有意义的，就算事后来看，每个cl/diff/cr/pr也十分系统性，可以放到表格中来看。
2.4 然后开始实施每一个cl/diff/cr/pr, 在实现的过程中，要确保他们都是比较清晰的，容易理解，并且就算每一行的comment也十分容易理解。
2.5 实现过程中如果有什么和设计不一样的地方，和设计没有考虑到的地方就要及时向上级汇报来征求意见来上级还是对整个项目有掌控, 这也是无法避免的，但不能很多，如果很多证明设计的时候出了问题。 这一部分应该是比较快的，如果设计的环节是比较成功的话。
3 然后项目顺利上线了就要后续跟进来维护，时刻考虑能不能优化之前自己的设计方案。

一切high level的工作原则，1. 不要走捷径，各种思路都要从最优最基本去思考而不是马虎. 2. 无论是doc还是cl/diff/cr/pr, 都要做到自己很proud的地步再给别人review, 而不是80%完成的状态. 3. 不要take risk, 或者极少take, 各种问题都要完整的技术分析. 4. 最重要的是要有系统性的思考，一个系统一旦很大之后就不那么显然，考虑问题要从全局来看而不仅仅是局部达到目标，要从全局思考，很多时候就会有超出预期的solution出来，这样也能impress他人。5. Take ownership，对每一个任务，一定要做到对end to end的掌握，包括所有的基本知识，绝对不能老板问的时候一问三不知或者问非所问.

说不上指导，但是highlevel原则1-3可能因为公司/组的环境，结果会很不一样：
1: 我自己被给过feedback说，不要太追求完美，task能做到七八成就行了。当时的context是我的productivity完全没有问题，但是同事觉得如果我干活糙一点可以做更多（后来我确实接受了建议，无论从project的结果还是perf review的结果来看，效果都是正面的）。当然我们的环境是fast iteration，事后想想确实最后改进的那两成没啥long term impact。
2: 我觉得大概有个框架的时候就开始给同事看，然后有了feedback再改进，这样推进速度会比较快。这样也比较容易检查和同事之间是否on the same page。当然这个的前提是和同事之间有trust。
.google  и3: 可能只是wording的不同，但我觉得take risk对长期发展是好的（比如进入自己不会的area，或者initiate不一定能做出来的project），前提是有支持risk taking的大环境。不好的是make assumption，然后不validate。
总的来说感觉你的approach比较保守，也许因为公司文化/行业里小错误比较容易被penalize。但是也许在宽容一点的文化环境里，可以更aggressive一点。

本文被选为09/13/2018全站置顶文章之一。
作者获得大米奖励。谢谢你的分享

感谢分享。
针对一条，我从印度同事中学到了不少，针对第二条，如果有很多印度同事在的时候，要注意了。

hxx800 发表于 2018-9-10 17:25
感谢分享。
针对一条，我从印度同事中学到了不少，针对第二条，如果有很多印度同事在的时候，要注意了。
...

你这里第一条和第二条是指什么？对不起我没有理解..

干货，感谢楼主分享！

yuanxiehuang 发表于 2018-9-10 17:35
你这里第一条和第二条是指什么？对不起我没有理解..

指的是1. 交流上  2. 工作过程中。

hxx800 发表于 2018-9-10 20:24
指的是1. 交流上  2. 工作过程中。

和很多印度同事一起工作的我 表示非常赞同 握手
看来你也是有很多故事的人哇……

大家都别光急着加分啊~还有给出一些提高的意见呢？我的思维上有没有什么缺点，有没有什么我miss的部分？如果下一步还要再继续提高我应该怎么做？

哈哈哈，欢迎feedback呀，这与我个人的性格比较有关系，我是属于干活比较糙比较快的情况，至于risk taking，我本身是极乐观的人，所以这些方面都是对我自己的本性的约束来纠正自己，你本身是phd，做的东西估计就本来就有这种极致的追求所以需要快一些糙一些，都是对的，最高的境界是收放自如，能根据项目和组来很好地调整自己工作的标准和risk tolerance，