0%

有一个问题困扰了我很久:为什么公司里的团队要互相卷? 明明 X 团队已经造了轮子,为什么 Y 团队常常视而不见,吭哧吭哧地继续造?而且领导似乎也默许这种游戏规则?本来产研资源就贵,为什么要浪费在相似的工作上,而不节省资源去专心做业务?最近在这个问题上稍微有点心得,就先记录于此。

阅读全文 »

多数人高估他们一年能做的事,却低估他们十年能的事(Most people overestimate what they can do in one year and underestimate what they can do in ten years)。

大概在两年前,我开始酝酿「赤道计划」:在人生结束之前跑完 40075 公里,这个距离正是赤道的周长。毛主席的「坐地日行八万里,巡天遥看一千河」也来源于它。如果每两天跑一次 5 公里,大约需要 44 年。

阅读全文 »

每个互联网公司内部都有一些 Web 界面是为工程师开发,比如 CMDB、容器平台、应用发布系统、可观测性平台、配置中心、数据库管理平台等等。这些界面往往设计风格不一致,功能简陋,易用性差强人意,简单概括就是「能用,但既不好看,也不好用」。

阅读全文 »

平时,我习惯在跑步、散步或通勤时做一些口语跟读练习。散步或通勤时还好,在手机上来回播放、暂停音频即可,但这种方法不适合在跑步中使用。另外,北京入冬后,在室外这么干容易生冻疮。于是我就想:能不能让音频自动地播放一句,停留一段时间让我跟读,然后再播下一句?

阅读全文 »

前言

从 2022 年 10 月中旬开始到 12 月中旬,日拱一卒,终于把「Software Engineering at Google」通读了一遍。书中介绍的是每个软件公司都会遇到的问题:如何培养好的工程师文化?如何共享知识?如何组建和带领工程师团队?如何长期维持软件质量?等等。同样的问题,在不同的规模、时间范围下的挑战不同,思考角度、解决方案、落地周期也都不同。这本书介绍的正是这家拥有超过两万名工程师的软件公司在这些问题上的思考。

在过去的工作经历中,我作为新人、下属、导师与不同类型的工程师有过不同程度的合作,他们之中既有顶尖的工程师,也有敬业的技术经理;既有人菜瘾大的码农、也有性格孤僻的极客;既有刚毕业就躺平的新人、也有工作十多年依然精力充沛的老兵。在这些合作经历中,我最大的感触就是:一名优秀的工程师,在技术层面外,还得是半个心理学家,既要熟练控制计算机、也要擅长与人合作。书中多处阐述工程师容易陷入的思想误区,它们或多或少地会阻碍工程师们成长,我也是其中之一。今天恰好借着看完这本书的契机将关于它们的思考记录下来。

阅读全文 »

可能是太想排到车号了,最近上下班路上总是盯着过往车辆的号牌。盯着盯着就会下意识地思考:「怎么用上面的数字经过加、减、乘、除得到 24」,比如下面这个车牌:

阅读全文 »

没有屏蔽我朋友圈的人估计都知道,我有一只帅气的猫叫郑小钱,一个可爱的女儿叫郑天晴。小钱已经快 5 岁了,天晴刚刚 1 岁 3 个月,她们和我 (爸爸)、我媳妇 (妈妈) 以及我妈妈 (奶奶),4 人 1 猫生活在北京租住的一套小房子里。

都说养猫是养娃的演习,这话颇有道理。二者的确有很多相似的地方,比如我们会忍不住给她们买玩具,花时间陪她们玩耍,给她们准备饭菜与零食,管她们拉屎撒尿。最有意思的,也是我和媳妇经常讨论的一点就是「她们跟谁关系最好。」她们不懂任何人情世故,却好像知道所有人情世故。

阅读全文 »

在伴鱼的三年,我作为面试官参与超过 100 场面试,遇到许多风格各异的候选人;最近的两个月里,我也作为候选人参与将近 30 轮面试,见过不少形形色色的面试官。在参与这些面试的过程中,我心中逐渐累积了一些对面试的看法,本文我想站在面试官的角度,谈一谈面试官毁掉技术面试的三大法宝。

阅读全文 »

在最近的工作中,为了做数据分析,我开始写一些复杂的 HiveSQL。每次执行 HiveSQL 时,都会看到 Map/Reduce jobs 被调度、执行,直到最后展示出数据。渐渐地我心中多了两个疑问:

  1. MapReduce 引擎如何工作?

  2. SQL 是如何被翻译成 MapReduce job 的?

为了解决这两个疑问,我用比较熟悉的 Go 语言实现了一个玩具版本的 MapReduce 引擎,然后基于此实现基本的 select,join。

本文相关的源码放在仓库 ZhengHe-MD/pset · GitHub 中,欢迎查阅。

阅读全文 »

最近,我们在公司内部做了一些 Hacking Growth 方向的探索,我们团队俨然成了增长团队,从用户增长、转化的各个环节上尝试不同的策略,拉新、激活、留存、促活、商业化,整个核心流程是一个大漏斗,不同的阶段和渠道又可以拆分成不同的小漏斗,哪个环节损失大就优化哪个。但无论做何种尝试,都绕不开 A/B 测试。

对于一名工程师,我认为 A/B 测试有两个角度值得了解:

  1. 如何搭建一个 A/B 测试平台,支持流量分层、转发,让不同实验共享流量;

  2. 如何动手做一个 A/B 测试,并能合理地解读统计结论,指导后续生产实践;

对于前者,业界已经有许多最佳实践,比如之前引我入门的这篇论文 Overlapping Experiment Infrastructure,以及伴鱼的小伙伴们写的两篇实践总结 [1]、[2];本文想聊的是后者。

1. 一次实验

在互联网场景中,无论是拉新、激活、留存、促活还是商业化,所有的 A/B 测试都可以用一个公式来概括:

💡 方案 A 的转化率比方案 B 的更高吗?

为了后续的讨论能更具体一些,我们先看一个实际的测试场景:假设我们需要给某个用户群体拨打 AI 电话,之前一直在使用家琪的声音拨打电话,现在供应商新推出了小红的声音,我们想知道小红的声音是否有更好的表现。于是,在其它条件相同的情况下,我们分别用小红和家琪的声音给若干用户打了电话,这次的实验现象如下表所示:

实验现象 小红 家琪
接通 3469 2798
意向 98 43
意向率 2.83% 1.54%

套用刚才的公式,这个 A/B 测试就是:

阅读全文 »