Guangyang Li

为什么付费 Salary Negotiation 是个坑

Mon, 06 Feb 2023 00:00:00 +0000

整理文件的时候偶然翻到了去年购买的 Levels.fyi 的 Salary Negotiation 服务留下的记录。想来恐怕以后不会再用此服务，写一篇博文记录当时的经历，和我的评价。不巧最近又是 Layoff 季，我的 LinkedIn timeline 里主动被动换工作的朋友更新最近明显频繁了很多，记下这段经历希望也能顺便帮到没用过这个服务的朋友。

Levels.fyi 网站本身大名在外，毋庸赘言，简而言之就是看各公司各 level 的工资数据的。Salary Negotiation 是他们提供的一项付费服务，由在职 Recruiter 视频电话和邮件跟进的形式帮助求职人谈 offer TC，价格有 $650 和 $1887 两档。

我的使用经历

2022 年上半年我在骑驴找马换工作的时候收获了 3 个 offer，虽然知道 offer 需要 compete，但是从来也不知道该怎么操作。当年接我最初两份工作的时候都是对方发来 offer，我就屁颠屁颠地接了，吃了自作清高不看一亩三分地的苦果。这一次就准备“千金散尽还复来”，买了 $650 的服务就想看看这钱能比不 negotiate 会多多少。其实我并不追求顶包，生活里的各种交易我也喜欢一口价，甚至厌恶讨价还价。但是市场上的大部分人都会有讨价还价一轮，那么不还价的新人自然成了冤大头，这是我不想看到的。也是这种心态让我更愿意雇一个人替我写这些讨价还价的邮件。

提供的服务包括 1 个小时的视频面谈，和 1-2 个 follow-up meeting，所以这项服务以小时工资来算价格是很高的。

整个指导流程大体来说是比较模式化的。在第一场面谈里，对方详细计算了我当前工资的各个部分，和手里 verbal offer 的 TC，给谈判定一个目标价。这个目标价主要取决于有没有 compete offer 和 offer 公司的平均工资水平，基本是硬性的了。我认为这个目标价还算可靠有依据，因为这次给我分配的导师是一位主业在 Apple 做 recruiter 小哥，想必工作中已经接触过大量的面试者和他们的工资报价，确实省去了我一些自己刷论坛 dp 的精力。但是这个目标价显然也是高于实际可能的，讲价的时候是从这个价往下讲。之后介绍了谈判的大致流程和一些细节策略，并一性次给了三次讨价还价的模板邮件。这些知识虽然网上有不少文章有所讨论，但是平心而论对于我一个还价小白来说还是很有帮助的。

但是在之后的实际还价中，我和每位 HR 几乎都没有达到三轮还价，大概都是第二轮的时候对方强势回复不可能反复加价了，于是我也没有强行继续谈。最后的结果三家当然都比原始 offer 要高一些，多的大概能高 20%。但是有多少要归功于 Salary Negotiation 呢？只有天晓得了。

为什么你不需要买这项服务

有了 ChatGPT，何必还交钱让别人替你写邮件？

老实说这篇邮件和 levels.fyi 给我的模板邮件已经很相似了。ChatGPT 甚至包含了某种所谓谈判策略，报一个 “may not be possible” 的价格让对方还价。

实际上，你也并不需要这些言语上的谈判技巧。网上有太多教人如何讨价还价和如何应对的文章。例如我就可以在这篇 16 Negotiation Tactics Buyers Use (and How to Respond) 中看到好几条他们教的语言技巧，比如 “meet me in the middle” 和 “I can sign that today if …”。显然，这些来往的套话 HR 肯定是更熟悉了。而这些 negotiation skill 也很难在一小时内掌握熟练的。

更重要的是，这只是一个 1 小时面谈 + follow-up 而已，它既不是知识传授，也无法替你和 HR 见招拆招，更不能增加你的谈判筹码，而只能做流程讲解和技巧上的速成。而你真正需要的，是学习怎么玩这个真真假假的谈判的游戏，能说什么样的话，要有什么样的心态，双方预期什么样的套路。以下几篇博文都是比较经典的文章，我认为这些公开的文章要比付费服务有用太多：

Salary Negotiation: Make More Money, Be More Valued

How Not to Bomb Your Offer Negotiation

数据工程师（Data Engineer）们都在做什么？

Mon, 17 Jan 2022 17:03:49 -0400

数据工程师（Data Engineer，下称 DE）是属于软件工程师下的一个细分方向，但是随着行业需求的增多，这个岗位越来越引人注目。我在这篇博文会大致介绍其主要职责，行业内不同的细分方向，和解答在转型数据工程师时的常见问题。

那么 DE 是做什么的呢？这个岗位的核心职责是解决公司关于数据存储与处理的问题。随着企业数据解决方案从关系型数据库到分布式数据库，再到基于云的数据仓库/数据湖的变迁，对应的岗位也从数据库管理员、ETL 工程师等发展为数据工程师。现今所指的 DE 基本是指关于大数据处理的岗位。

具体而言，DE 的主要工作有两大类：

数据平台：建设与维护数据平台以提供储存、转换、分析数据的能力
数据业务：将处理数据的商业逻辑与业务流程转化为代码形式的数据管道，并在数据平台上管理数据的整个生命周期

但由于公司组织结构、规模、和选用的解决方案的不同，实际的工作内容可能是以上两类中的一部分，也可能是两类都包含。

例如，在 Facebook 和 Uber，DE 几乎只负责数据业务逻辑，大部分工作是在比较成熟的内部数据平台里实现商业指标的计算和处理流程。换言之，他们的主要工具是 SQL，核心任务是通过 SQL 建立起数据处理任务。所依赖的数据平台则是由软件工程师构成的其他部门来开发和维护。

而对于众多使用 AWS 或 GCP 等公有云的中小公司，通过云服务商购买了现成的数据平台解决方案，基础建设的难度大大降低。在这样的公司数据工程师们可以像搭乐高一样，通过选取最适合的云服务来搭建数据平台。这些工程师处于 DE 和 SDE 的交叉领域，可能既要负责数据平台的基建，又要处理数据处理的业务逻辑。

我曾工作过的另一家公司 Expedia 则处于一种中间情况。由 SDE 们维护一套开源数据湖组件，各业务线的数据组自行在 AWS 上部署这套工具，建立与维护专门服务该部门的数据平台。

数据平台

搭建数据平台具体包含这些工作：

规划稳定且可拓展的数据储存方案和数据处理架构。数据来源主要是批数据还是流数据，数据的输出是需要实时还是定时更新，数据的增长速度有多快，要根据这些具体的需求和场景建立适当的数据解决方案。
选择合适的数据编排（Data Orchestration）工具建立可靠的数据管道，最常见的工具是 Airflow。
提供数据平台的支持和管理工具，包括数据目录（Data Catelog）、数据沿袭（Data Lineage）、元数据管理、权限管理、状态监测与报警等等。这些工具可能是自行开发，也可能是选购第三方服务。
提供数据质量管理工具，能够监测数据的新鲜度、准确度、完整度等指标。
提供数据查询引擎和查询服务或界面，确保下游团队可以按照他们不同的需求来获取数据。
Terraform、Ansible 等运维自动化工具，和 AWS CloudFormation 等自动化运维云服务。
云服务选型。了解市场上的云提供商的功能，和主流的 SaaS 数据服务，考察哪些值得被引入公司的数据平台。

这些工作内容因公司的规模与技术选型而可大可小。对于使用私有数据中心的公司，数据平台的各个部分都很可能需要开发自己的内部实现，那么每一个部分都可能是由一个团队来完成。而对于已经积极拥抱云服务的公司，几个人的小团队也可以完成所有这些内容。

数据业务

有了数据平台，下游组的 DE 就可以在平台上运行具体的数据任务。要将商业上的需求转化成数据工程的任务，具体包括这些工作：

数据指标的构思和落地。数据指标通常是由下游的分析师提出，但是如果理解了如何计算这些指标，和为什么要计算它，这对 DE 将商业需求转化成代码会有极大帮助。
数据建模。根据数据输入输出时的各种需求创建相适应的数据模型。
对各种格式的来源数据的处理，和进入数据平台后的数据清理、标准化、转换等处理。
处理程序和查询语句调优。最常见的是 SQL 调优，根据查询引擎的不同，有着各异的调优方式。处理程序调优也是由平台选用的工具而定，常见工具包括 Spark、Hive、Flink、Kafka 等。
监测任务状态。比如上游数据库是否稳定可用，平台内各服务状态监测，数据质量监测等。

要注意的是，实际工作中数据平台与数据业务两个方向的职责范围并没有明确的区分。无论是在大小公司，DE 的实际职责可能是上面任意几点的组合。

在前文我泛泛地描述了数据工程师职责范围，但对于有意转往这个方向的朋友恐怕描述地太粗糙了。因此我也尝试回答一些想换方向的人可能会问的问题：

数据工程师需要的编程能力高吗？

DE 需要多少编程能力主要取决于团队对这个岗位的需求。简而言之，是这个岗位更偏平台，还是偏业务。

对于需要自行开发数据平台各个组件的团队而言，他们对数据工程师的编程能力基本和软件工程师无异。这类工程师的核心产出是一个供内部使用数据的服务或软件。

但市场上大部分的 DE做的是数据业务的工作，对于编程能力的要求略低于软件工程师，但对使用 SQL 处理数据的能力要求会高很多。他们典型的编程场景是数据处理任务和数据任务编排（Data Orchestration）。此外，DE 岗位通常对大数据处理的经验也有要求，因为实际工作中有许多项目依赖成员对分布式工具的理解。这些经验的积累往往也与代码阅读和编写能力息息相关。

数据工程师的 On-call 通常是什么内容？会不会比 SDE 轻松？

对于数据平台方向，其本质是维护一套供内部人员使用的各种数据工具，那么他们的 On-call 就是维护这些工具的正常使用，处理用户提交的问题。因为使用者都是内部用户，沟通或测试起来都要比外部用户容易得多，他们通常也不会产生千奇百怪的软件输入，On-call 压力也就比较轻松。

对于数据业务方向的 DE，具体内容和压力取决于其维护的数据在整个公司中的位置。公司的业务线如果多的话，通常中上游部分有专门的数据组管理核心数据，下游各业务线也有各自的组管理其业务数据。那么可想而知，核心数据组的压力远大于业务组的压力。上游的组只能对数据提出严格的 SLA，例如数据新鲜度比较高的 SLA，才能确保下游数据的可用性。而其 On-call 内容通常就是保障数据任务的正常处理，出现异常就及时寻找替代方案进行 backfill，避免违反 SLA。

下游的业务组的压力取决于其终端用户，也就是数据消费者。例如 BI 组，其数据产出是服务于内部 BI 分析的，像供 Business Analyst 们在 Tableau 上做数据可视化使用。这些用户对实时数据的需求度一般比较低，对数据可用性的要求也比外部用户低，可说是 On-call 最轻松的组。但如果终端用户是外部用户，例如政府监管部门，可能会因数据延迟、缺失而导致罚款或吊销牌照，那么就需要足够的人力保障数据可用，其 On-call 压力在 2B 产品中应该算比较高的。

数据工程师的职业发展有哪些选择？

作为软件开发行业中的一个子类，DE 的职业发展和 SDE 没有太大区别。对于主要从事数据平台开发工作的工程师来说，可以深入数据平台的架构，成为数据平台架构师，或者转向为 SDE 做更加 infra 的工作。对于主要做数据业务的工程师来说，除了一样的转型为 Data infra 方向的 SDE，还可以在各种数据使用场景上深挖，例如转型为 Machine Learning Engineer，Data Vidualization Engineer，和 Data Scientist 等。

如果是转型管理岗位，数据平台组是一个不错的起点。随着数据驱动决策的流行，数据平台正在成为核心部门。相较业务部门而言通常更为稳定，且做的事情往往有更大的影响力。

企业大数据平台建设思路

Mon, 27 Sep 2021 17:03:49 -0400

为什么需要数据平台

数据平台（Data Platform）不是个新概念。工厂流水线上的传感器会不间断地生成数据，营销公司每分每秒都会有销售数据。采集和处理数据的需求由来已久。

在以往，企业会开发或购买一套数据解决方案来应对这一需求。尽管这些传统方案也能连接如 ERP、CRM 等企业内部系统的数据，并提供数据分析的能力，但它们难以适应快速增长与变化的数据，和企业内新的数据使用需求。

现如今，随着更多数据迁移上云，企业更倾向于建立专门的数据部门建立一个或多个数据平台，为企业提供一个适应更多更复杂的数据，和多种数据使用场景的基础服务。本文所描述的数据平台，也是指这种能够处理海量数据、使用场景复杂的大数据平台。

企业的数据需求

一般企业对数据有两大类主要的使用需求：一是通过数据指标、报表等商业智能分析辅助决策，二是通过数据挖掘优化业务。

商业智能分析（BI，Business Intelligence）即是指通过计算指标、各类数据图表与报告等形式，掌握企业在财务、销售、生产等各方面的经营状况，从而辅助决策。

数据挖掘优化业务，包括建立数据应用辅助业务部门工作、使用机器学习方法改进生产，或改善用户体验等等。这类需求实现的是，将通过数据得到的结论自动地反馈在业务提升上。

在企业数据规模不大时，这两类需求可以通过低代码工具，例如 Excel，就能够实现。然而当数据规模和复杂度都飞速增长后，企业必须利用新的工具来掌控与使用大数据。数据平台正是大数据时代的这一解决方案。

数据平台解决的问题

在技术上，数据平台解决的是：

处理规模庞大（包括纵向与横向），来源多样（数据库、数据流、文件等），格式复杂（结构化、非结构化、半结构化）的数据
高复杂度的数据处理，如需关联多个多来源的数据表、数据任务依赖关系复杂等
同时支持多种使用场景，例如既允许运营部门实时监测商业指标，又支持数据挖掘团队快速导出大量数据

在业务上，数据平台可以实现：

关联企业内跨系统、跨部门、跨平台的数据，解决数据孤岛问题
将商业状况量化为易于跟踪的数据指标，为业务决策提供数据支持，实现数据驱动业务

如何建设数据平台

数据平台上云

对于大部分企业，尤其是中小型企业，数据与软件上云是大势所趋。云服务的优势本文不在赘述，这里着重强调几个基于云的数据平台的优势：

通过存算分离、即用即付、无服务器计算等模式实现资源灵活扩展和节省成本。数据平台所需的计算能力有时起伏很大，且算力需求与数据规模可能并不同步增长。能够按需配置资源的云服务将极大节省成本。
节省服务器软硬件成本和运维成本。对于非互联网行业的一般企业来说，通常没有为了数据平台而自建或租用机房的必要。相比于维护传统机房，云上运维更能节省软硬件投资和维护成本。
通过云服务实现更容易的合规。许多云服务商提供了针对数据合规的技术解决方案，以满足 GDPR、HIPAA 等要求。使用这些服务可以避免为了数据合规而产生的时间、人员资源、财务资源上的浪费。

此外，许多云服务商针对数据平台提供了更现代的进阶功能，例如：

自动化与可视化的数据发现和元数据管理
自动化的数据标注（Data Tagging）与管理
自动化的数据质量评估和监控
自助式的数据分析接口

这些功能大多是基于云的规模效应等特性而开发，因而使用成本要比企业自行开发或另外购买低很多。

除了公有云运营商提供的数据服务，还有专注于某些功能的 SaaS 云服务商，例如提供数据仓库服务的 Snowflake，提供数据湖与数据管理服务的 Databricks，提供数据湖引擎与自助分析服务的 Dremio 等。它们大多可以运行在多种公有云上，为数据平台建设提供更丰富的选项。

对于有极强的数据安全需求的企业而言，建立自有数据中心和数据平台仍是必要之举。但自建与上云并不是非此即彼的二元选择。包括 Google Cloud，AWS 和 Azure 等几大云服务商都有提供混合云解决方案，将数据平台扩展到云。通过这些混合云解决方案，私有数据中心可以和公有云计算环境结合在一起，实现“鱼与熊掌”兼得。

集中式还是去中心化模式

数据平台的作用之一是关联企业内分散的数据，因此它有着天然的中心化属性。

对于中小型企业，和业务范围单一或业务流程成熟的大型企业而言，中心化的数据平台可以将企业的所有数据涵盖其中，极大程度地将各系统、各部门的数据联系起来，并且避免了不同部门间的重复建设，节省了资源。

但对于品牌多样、业务复杂的企业而言，部门之间关联的需求可能较小，这种情况下，中心化数据平台带来的价值也就不那么高了。例如，企业有多个品牌线独立运营，或者有多条业务线分属不同行业时，都可能更适用于各部门独立建设数据平台。总而言之，建设一个还是多个数据平台，取决于企业自身的结构与规模，和跨部门数据关联之后能否产生更大价值。

不过，即便企业内共存了多个数据平台，仍然可以通过共用相同的云基础设施、选择相似的技术方案等方法，降低其维护成本。

此外，建设多个数据平台并不意味着数据从此分开。当多个数据平台之间重新有了关联起来的需求时，还可能通过数据网格（Data Mesh）架构和数据联邦（Data Federation）的方法将分散在各业务线的数据集成在同一个系统下。这样数据消费者无需连接到各个数据平台，也可以同时获取来自多个数据平台的数据。