前些日子看了奥斯卡电影CODA, 感受到聋哑人在生活的艰难和委屈. 不知怎么的, 把我带回那个初来乍到的年头. 2010/01/11, 我第一天到美国, 错过报道时间一周, 面临被退学的危险, 半夜的航班, 行李全部因为航班问题丢失. 连话都说不明白的第一天, 我是这么过的:

刚来美国的时候常算时间: 还有几个月放假, 还有几个月回家? 那些日子很勇敢: 有语言屏障, 对未来迷茫, 偏偏因为刚刚出国, 天真无邪, 无知也就无所畏惧. 疏离感是后来才慢慢出现的, 一开始并没有. 在宿管老师跟导师面前, 我没想着遮掩自己的愚蠢, 用我的破碎英文尬聊.

宿舍在哪? 办理住宿的学生中心在哪? 下一节课的教学楼在哪? 怎么选课? 大一报道迟了一周, 什么课都没了, 我算被退学么? 我行李丢全部丢了, 现在该怎么办? 就是这些蠢问题, 我一遍遍解释着我的情况, 一边担忧: 是不是我这就算废了, 是不是明天就得做飞机回上海!?

第一天早上8点, 我先到了宿管老师那, 他看我一脸懵逼, 就明白了又是个糊涂蛋. 他说, 第一件事, 去找我的导师, 算是正式报道; 另外得在那马上选课, 已经错过了开课, 得马上解决. 第二件事, 去国际学生中心报道, 还有些国际学生特定的事情在那解决.

现在我记不清我是怎么被他送到导师那里, 不记得宿管老师的车长什么样子, 只记得他好像有小胡子, 很干练, 不像是我在国内大学遇到的宿管大爷, 而更像是个什么主任的形象. 这是我来美国的早上做的第一件事情: 解决还没见着老师同学就被退学的危机.

导师很和蔼, 胖胖的一个光头大叔. 他听我解释了为什么迟了一周报道. 我也不太确定, 我是不是聊明白了, 大致就是: 中介给我说错了时间, 于是我迟到了, 真不好意思, 请帮帮我! 现在回想, 我猜导师可能也懵逼, 什么是留学中介? 为什么你自己的事情是别人安排的?

不停折腾. 这可不, 得更新一支播客 - 这一次讲的是西雅图脱口秀的故事.

就现在的用户体验来看, 小宇宙 是最好用的. 页面简易, 支持RSS Feed. 播客就收录在这里: https://www.xiaoyuzhoufm.com/podcast/626ef6323e8abf901a68d8bd

我多年以来没有搞明白的播客怎么上传的, 可能是我老了? 我一直觉得, 应该到各个网站, 去手动上传播客, 因为…图片,视频, 都是这么上传的嘛 lol

但播客却不是这样. 一般的播客, 都是自己找一个hosting service, 然后上传声音文件, 然后产生一个RSS Feed. 这个RSS Feed就可以被接入到各个平台, 比如小宇宙 , Apple Podcast, Spotify.

一次上传, 所有地方都可以播放. 需要付费的, 就只是那个hosting service.

这么多年一直被固有的认知所限制, 还好我是个知耻后勇的人.

此外, 还用了一个新工具, 叫riverside.fm. 这个玩意儿也挺有意思: 自己开一个’studio’, 可以视频接线进来, 就想视频聊天一样. 如果开始录制, 每个人的声音/视频, 会分别录制然后上传到服务器. 最后我只要下载几条分别的音轨, 最后合成视频/podcast就好了.

我正在征集podcast话题. 如果有兴趣, 有想法的朋友, 可以留言, 未来我们在线聊聊.

Spotify

①拒了一些Offer

上一次的文章里面, 我们聊了几个公司的区别.

今天用视频, 深入聊聊, Uber的那个offer是怎么攒出来的:

② I Failed To Quit FAANG

Maybe I’m Culturally Wired This Way?

We are obsessed with FAANG companies. For the past 6 years, people come and leave, but I’m strapped in. I’m not able to quit. My self-diagnosis? Financial stability, prestige, and caliber — may be due to all of them, but behind the scene, what really dominates my decision is my culture and my education.

你恐怕会想, 说的是工作能力缺失的故事? 恰恰相反, 今天说的是那个实力全组最强的人, 那个全队的瓶颈.

THE STORY

17年, 在亚马逊工作了一年多, 我接手了一个中型的项目, 重置一下我们内部的一个管理网站. 想法很简单, 就是重做网站, 加上一些新功能, 再保证未来可以添加新功能.

老网站呢? 是老古董了, 当年别人用Ruby on Rails写的, 跟现在的API不合拍, 也很难用.

难度呢, 也不算大, 但是有些繁琐 - 它是个大而全的东西, 为了做成一个功能, 要往回推好几步, 把后端的API, 搜索引擎都要做了.

当时的我已经有切割/分配任务的习惯, 然而还是自己承担了最繁琐的部分 - I can I up 嘛.

我记得是在一个炎热的7月底, 因为种种原因, 当时需要在短时间内完成更多的功能:

• 我觉得, 这时候已经来不及了, 再教别人, 哪里够时间, 自己上

• 还有新功能要加, 行, 来吧, 不用别人, 我来

• 需要加班, 怕什么, 为了升职, 为了变成组内最强, 我来

• 那么我整个8月, 就在每天1-2点午夜冲刺, 不亦乐乎

最后项目的结果是不错的, 我也顺利成章地变成这个项目/网站唯一的内行. 我觉得没问题, I can I up嘛

近一年来, 我在琢磨, 什么是出色的导师(Mentor)? 如何到达那一步?

导师与老师的角色有很大的区别: 前者似乎更多在提出问题, 而后者更多在解答问题. 把我们放在 1:1 会面的语境里, 导师也许更多是用问题来帮助对方自己找寻答案, 而老师会直接有效地教会一件事的来龙去脉.

我的工作经验里, 当需要我输出的时候, 通常我在扮演一个老师的角色. 但现在我很想改变这个状态.

老师的角色

第一份工作, 那时候我刚毕业. 半年以后, 我就接到了'教课'的任务.

我们的项目要跟许多其他公司合作, 我们管他们叫 partners, 合作商. 他们需要学习我们提供的系统以及工具. 我的项目, 简单而言, 就是手机端的控制系统; 那么 partners 要学会如何使用, 以及如何配置. 我需要的'教'的, 就是这一部分.

做老师的体验挺好的, 我有备课, 做好了 PPT, 提前询问好他们可能会不懂的地方, 着重讲解, 我也对可能收到的提问做了预设与回答.

这个课是 80%的单向输出, 20%的提问. 台下是一片头发灰白的大叔大爷, 有些人是真的需要学会, 有些人是带着理解的心态.

控场不难, 1/ 把握时间节奏, 2/ 对大爷的插科打诨有做心理准备. 3/ 准备几个'自我澄清'类的笑话, 比如说: 你看我长的那么年纪小(asians doesn't age), 其实我是个高中生(我当然不是); 大家笑. 你看我讲课英语还成, 那你是没跟我聊天, 我极限就是讲 2 个小时; 大家笑.

最近有两个美国朋友, 先后跟我联系, 问我当年面试的经验. 我发现他们有个共同的特点, 就是很难接受一个'慢慢来'的设定 - 我不知道是何原因, 也许是直男, 也许是缺乏面试经验. 既然他们问了我意见, 那我就耐心解释, 为什么面试的时机很重要.

面试最佳的时机

当然是headcount刚放出来的时候

5个卓绝的工程师去抢一个位置, 会比同样5个卓绝的工程师抢十个位置, 要难的多!

这是个再简单不过的道理, 但是对于一个正要鼓起劲来披荆斩棘的人来说, 要让他最先考虑的是取巧, 是挑合适的时机, 似乎就违逆了他"不管什么困难, 谁也挡不住我!"的自尊心.

很多人会轻视战略, 认为自己要自己能力强, 谁也挡不住.

但是他们是我的好朋友, 我们耐心的聊聊.

那么什么时候headcount放出来了? 许多公司都是年初放出来新的位置. 为什么? 一年的财报过了, 马上准备钱, 计划公司下一年的花销, 那么当然是在年初的时候, 有新的位置放出来. 这是很多公司的习惯操作. 有些公司也许fiscal year(财年) 不在年末结束, 那么可能有些差别, 但是大部分公司都遵循这样的规律.

年中是为什么? 我不知道具体缘由, 但我估计, 半年会有一些计划的调整, 会放出新的工位. 其次, 年中, 很多大学都毕业, 不论是提前敲定过offer还是在毕业季找工作, 都会有大批职场新人涌入职场 - 大家想一想供求关系, 就能明白, 年中也是headcount打开的时机.

我们如何调整面试时机?

我一般计划6个月的时间准备: 看书/算法题/系统设计/第一轮面试/第二轮面试.

如果我是要在年初, 比如2月拿到offer, 那么我会在去年的7-8月份开始看书准备. 知道我2019 7月在图书馆的朋友们就明白了我当时在干什么.

那么我再走一遍流程.

1. 看书, 我看了cracking coding interview, 主要看她的思路, 知识点总结. 里面的题目也不错, 值得看一看. 这段时间是复习基础知识, 所以给足1个月时间 (我们在上班的人, 1个月差不多够了; 学生朋友的话, 可以过的快一点). 我并没有把上面题目全部做完, 但是如果给我更多时间, 我会选择做完/看完. (时长: 1个月)

2021三月底, 我用视频记录了来到新公司的沟通瓶颈. 因为语言环境的改变, 知识领域的变迁, 我们势必会在新公司进步缓慢. 那期视频, 以公司会议为切入点, 聊了三个可攻可守的角度: 1/ 把控会议的开头, 2/ 提前了解沟通的对象, 3/ 会议后总结跟进.

话语权的建立, 填坑

我是2020年挪的坑. 也许是疫情阻碍了进一步交流, 直到次年三月, 我还在等待与组员的无缝沟通.

我还在寻找自己的话语权.

最近几个月的磨合中, 渐渐有成效. 倒不是我的表达能力突飞猛进, 也不仅是高效的会议帮我赢得大家的尊重. 促使现状改变的, 是项目职责外, 我遇到了可以填的坑.

• 比如代码结构有缺失, 那么从从根源找到问题, 出一个万全之策

• 比如运行速度不够快, 那么就去解决速度问题

这些机会有时会被旁人点拨, 也需要自己够胆, 够时间.

一旦顺利填坑, 在这个我们研究透的领域, 我们就是绝对的主角. 此外, 学到的就要教人: 若别人在我们的提点下进步, 还能进一步巩固我们的话语权.

冷静, 保持中立

在技术讨论里, 我们都曾遇到这样的场景: 我们准备了设计文稿, 苦口婆心地标注各类方案, 列举需要大家回馈的话题…

会议一开始, 就变成了两方的争斗. A坚持最正确的工程理念 best practice, "武林至尊，宝刀屠龙!", B觉得自己的设计更胜一筹, 快准狠 high efficiency, "倚天不出，谁与争锋!"

夹在中间, 我很想说, "什么有的没的, 这些我早就考虑过了, 你们到底看文档没有? 玩去!"

但是, 喝住了A, 等于站了B的立场, 反之亦然.

在计划项目的时候, 我通常会把任务分析透彻, 描述得通透, 然后再发出去给别人做. 仿佛写入的细节越多, 接到项目的人成功率就越高.

逐渐, 我发现工作中有两种人: 1/ 不需要你的分析, 他也很快琢磨明白. 2/ 你分析得再透彻, 他还是很混乱, 甚至看不懂任务明细.

咱们今天避开后者, 不讨论. 失败的理由千千万, 不稀奇.

我最近在权衡: 当遇到了第一种人, 效率高, 反应快, 该如何培养这样的工程师? 我大致的想法是:

遇到骨骼清奇的人才

• 1/ 用两到三个项目来磨炼

• 2/ 而后让他单独带一个项目

这些项目平均而言1 - 1.5 年可以轻松完成的. 遇到高效的人, 可能会加快进度.

计划项目的想法

• 如果机会给的太慢: 即便有"卓越的表现"也会随着时间的推移而变成"稳定发挥", 可能会打击积极性

• 如果机会给的太快: 经验不能够支撑他独当一面, 可能适得其反

假设每个项目需要三个月, 这里写下一些潦草的计划, 帮助我们观察工程师的成长进度. 这里我们说的新人, 包括"刚毕业的新人", 以及"跳槽的新人".

项目A: 引导

• 需要其他工程师的直接引导, 帮新人找足资料

• 项目: 细节全部标明, 手把手带上路. 不会有太多挑战.

• 引导: 在这一阶段, 教他做项目, 写代码的基本规范(每个组每个公司规范不同)

• 期待结果: 不懂的问题全部问清楚; 按时完成.

项目B: 协助

• (如果项目A做的不好, 继续第一个项目的策略, 但注意, 新人进度可能有些慢了)

• 项目: 简略细节描述; 要求他自己研究余下的细节

COVID 元年, 我拿了 4 个 offer: Google, Facebook, Uber, Asana. 其中 Uber可圈可点, Offer最为阔气, 忍痛拒绝.

这篇News Letter, 回顾了我最近一次面试的心态, 经历, 和对每个公司的看法.

首先, 简略描述我在亚马逊的 4 年, 以及 2019 年底准备面试的状态.

5 YEARS AGO

接offer, 是我生日(3/20)的前两天. 在亚马逊的第一天, 是5/23/2016. 现在想起来, 很美好.

2016年时, 拿下Amazon的工作. 我还记得那时拿到offer的彷徨, 忐忑, 还有和中了彩票一般的欣喜, 以及入职后的Imposter Syndrome (水货综合症).

虽然不是毕业第一份工作, 但进入亚马逊是入行的第一次认证: “别人可以, 我也能行!”

那时高兴地能飘起来.

在西雅图这座春雨洗过的城市里, 五月, 万物生长, 泥土清新.我仿佛被种进一块肥沃的土地, 终于有个地盘给我成长.

对, 没错, 就是那种感觉, 一切都为你准备好了, 全是新的, 就等你使一把劲.

2 YEARS AGO

人要是不动, 那么迟早有天是要平庸的.

我的人生在2018年稍微失控, 而后整个2019年都在寻找自我的怪圈里. 为了保持心态健康, 也为找个分散精力的事情, 我开始做视频. 一做就是两年, 斜杠程序员土汪: B站, YouTube.

我曾酷爱文章. 续过人家的小说, 编过自己的故事, 琢磨过用字, 也自诩高明地打过笔仗.

后来我写代码了. 代码无情, 有结构但没故事, 有语法但没偏好. 代码的完成意味着一个过程的结束, 而非拉开一场演出的帷幕. 这些都跟写文章写小说差之千里.

生活中我逐渐远离了写作; 我想, 除了入了行的人, 大家可能也都远离了超过5分钟的文字. 随着表达工具的延展, 文字不再具有往日的冲击力. 如果能通过图片在0.1秒内抓住你的眼球, 文章可能需要你阅读至少5分钟.

码字的年岁见长, 工作中逐渐形成另一套写作的天地: 既要严谨的逻辑, 也得在情理中折服众人. 这中, 除了对文字的权衡, 也有对观众的把握, 还要对结构深思, 配上那0.1秒的冲击(图片), 最后需要作者现场的表演来完成文档的使命.

这就是表达工程思想的必经之路: 文档. 可能是工程设计文档, 可能是项目计划文档, 可能是教程文档…总而言之, 能把文档写得漂亮高效, 整个人都觉得神清气爽.

抛砖引玉, 今天我们聊聊写文档的结构.

平时我都在英文环境下做文档, 那么就以此为大纲, 然后加以解释.

假如说, 今天我要写一份教程文档, 譬如一个项目完结了, 我们要记录它的架构, 方便后人理解.

Overview 概括

这部分, 一定要简略: 不需要看你文档的人, 看完这一段可以离开. 需要看文档的人, 让他知道你到底要表达什么.

1/ 简短描述这个文档的意义! (很多人会忘记这一点, 并不是所有人都能立刻明白你的文档作用为何)

2/ 简短描述这个项目是什么

(举例) This document covers the technical design of the chat feature on WeChat. The chat feature allows two or more users to send text messages over the internet instantly.