数据仓库工程师入职首90天快速上手与绩效达成检查清单

"答得最好的人，往往第一个被筛掉。"

这不是在说面试。这是入职第三周周一早晨的站会，你的manager突然在Slack私信你："昨晚ETL job挂了，你来看看。"你打开Airflow，DAG全是红的。你花了四小时修复，却在下午的架构评审会上被问住："这个模型的grain是什么？你为什么选SCD Type 2而不是快照表？"你意识到，面试时背过的Kimball维度建模，和 production 里每天下午三点准时炸掉的job之间，隔着一整个太平洋。90天后是绩效评估，而你的OKR里写着"建立可信赖的数据底座"——但你甚至还没搞清哪个schema是trash，哪个是single source of truth。这篇文章的判决是：大多数新人把前90天浪费在"熟悉技术栈"上，而真正的考核从第1天就已经开始，只是形式不是考试，是信任积累。

一句话总结

数据仓库工程师的前90天不是学习期，而是信任窗口期。你的技术能力在入职前已被验证，入职后考核的是判断力——在信息不完整时做出正确决策的能力，在优先级冲突时捍卫数据质量底线的勇气，以及在组织噪声中识别真正业务问题的直觉。不是"把模型跑通"，而是让下游团队在没有你的情况下也能信任数据；不是"完成ticket"，而是在第30天就能独立判断"这个需求不该做"并给出替代方案。绩效达成的标志不是output数量，而是你的manager在quarterly planning时开始问"你觉得"——这三个字意味着你已从事务执行者转变为决策参与者。

适合谁看

三类人需要把这篇文章放进收藏夹。

第一类是刚拿到数据仓库工程师offer、正在焦虑"入职第一天该装什么软件"的人。你们的base通常在$120K-$180K，RSU $30K-$80K/年，bonus 10%-15%。总包落在$160K-$250K区间。你们的雇主可能是Snowflake-native的SaaS公司、正从Hadoop迁移到云仓的Fintech、或是数据平台团队刚成立两年的电商平台。你们的技术背景可能是从数据 analyst 转 engineering，或是从backend engineer 转 data infrastructure。

第二类是 hiring manager 或 buddy system 的设计者。你们在反思：为什么去年招的三个senior，有两个在6个月内离职，一个虽然留下但始终没能独立own一块业务。答案通常是入职设计的问题，不是招聘的问题。

第三类是正在面试、想反向评估雇主的人。如果对方说不清"前90天的成功标准是什么"，这个offer需要重新谈判。

不适合谁：还在刷LeetCode准备面试的人。这篇文章假设你已经通过了4-5轮技术面试，包括一轮live coding（通常是SQL优化或Python ETL）、一轮system design（设计一个从0到1的数仓架构，考察星型模型vs雪花模型、CDC机制选择、分区策略）、一轮hiring manager面（考察stakeholder管理和冲突解决），以及一轮culture fit。每轮45-60分钟，system design可能拉长到90分钟。整个流程2-4周，快的有一周发offer的，慢的有拖两个月的。

为什么"熟悉环境"是最危险的陷阱

不是技术栈不熟悉导致失败，而是对"熟悉"的定义错了。

错误版本的新人：第一周安装IDE、配置VPN、跑通local environment，第二周开始接第一个JIRA ticket，第三周发现权限没开齐、数据访问要审批、一个字段的定义问了五个人得到五个答案，第四周终于把第一个PR merge进去，但发现下游团队已经在用旧数据做决策了。第60天，manager在1:1里问"你觉得这块业务怎么样"，你只能回答"还在了解"。第90天，绩效评估写的是"需要更多时间ramp up"。

正确版本的新人：第1天，不是配环境，而是约五个30分钟的1:1——你的manager、直属senior engineer、两个下游数据 consumer（可能是BI analyst或product manager）、一个平台/infra团队的联系人。第3天，你已经能画出数据流图：raw zone → staging → mart，每个stage的owner是谁，哪张表是每天上午9点前必须ready的（因为CEO的dashboard依赖它），哪个job是"没人敢碰的legacy"（通常是一个500行的Spark job，作者三年前离职）。第7天，你发现第一个真正的问题：某个核心fact table的grain不是你以为的transaction-level，而是已经aggregated到daily，导致一个看似简单的"去重"需求实际上需要重构整个pipeline。你把它写进running doc，在weekly sync上提出，而不是默默接受ticket里的假设。

这个区别不是努力程度的区别，是框架的区别。不是A，而是B：不是"我先学会，再做判断"，而是"用判断驱动学习"。

具体场景：某Fintech公司的数仓团队，新人Sarah入职第一周被分配"熟悉lending业务的数据模型"。她花了三天把ER图从头到尾看了一遍，记了二十页笔记。同周入职的David，第一天就去找lending PM喝咖啡，问的是"你们上周的decision meeting，数据出了什么问题"。PM说，他们一直怀疑某个risk score的recency有问题，但data team没人能回答。David第二天花了四小时追根溯源，发现score join的是三个月前的feature table，而不是 daily refresh。他把这个问题和fix方案一起发到lending-data频道，@了data science lead和PM。第30天，David被邀请参加lending的weekly business review，Sarah还在"熟悉环境"。

这个案例的判决是：数据仓库工程师的核心价值不是建模能力，而是成为"业务问题和技术实现之间的翻译官"。前90天的每一分投入，都要能回答一个问题：这件事如果我不做，三个月后会怎样？如果答案是"没什么影响"，那你正在做的事情可能是错的。

绩效评估到底在评什么

不是代码产出量，不是closed ticket数，不是PR merge频率。

打开任何一家公司的performance review form，数据仓库工程师的评估维度通常是：technical excellence、business impact、collaboration、growth。但真正的权重不是平均的。前90天，technical excellence是baseline假设（你已经被hire了），growth是观察项（还看不出），business impact和collaboration才是决定你是"meets"还是"exceeds"的杠杆。

不是A，而是B：不是"我完成了多少任务"，而是"我阻止了多少错误决策"。

具体insider场景：某电商平台的hiring committee review。Candidate A，入职60天，closed 15个tickets，代码review反馈全是nit（变量命名、空格）。Candidate B，入职60天，closed 8个tickets，但其中一个是block了product team上线的data quality issue——她发现new feature的tracking event和existing event有naming collision，会导致归因模型double count。她在ticket里写了impact analysis：如果上线，Q3 GMV report会高估12%，涉及$2.3M的budget allocation。Product team最初push back，认为会delay launch。她提出了hotfix方案，只delay两天。HC讨论时，engineering VP问的是"为什么我们的data quality check没 catches 这个"，而不是"为什么她只closed 8个tickets"。最后评级：Candidate B exceeds，Candidate A meets。

这个场景揭示的判决：数仓工程师的绩效评估，本质是"信任账户"的充值记录。每一个被阻止的错误决策，都是大额存款；每一个按时完成的ticket，只是小额日常交易。前90天的目标，是让manager在quarterly review时能讲出至少一个"她阻止了什么"的故事。

第1-30天：建立"数据地图"而非"技术地图"

不是把数据血缘工具跑一遍，而是建立"谁在什么时候因为什么依赖哪张表"的完整认知。

具体执行：创建三个文档，权限设为team可见。

第一个文档："Critical Path Inventory"。列出所有business-critical的数据资产：每张表的最终consumer（是人，不是team）、SLA定义（是"上午9点前"，不是"daily"）、failure的escalation path（谁会在什么时候打电话）、last known issue（哪怕是你入职前的，从on-call log里翻）。这个文档的价值不是信息本身，而是让senior engineer看到你在用他们的语言思考。

第二个文档："Definition Disputes"。记录所有你发现的不一致定义。比如"active user"在product analytics里是DAU，在finance report里是MAU with at least one transaction，在marketing dashboard里是"engaged"（定义更模糊）。不要试图统一它们——前90天你没有这个authority。但要让所有人知道你知道，并在每次涉及这些metric的conversation中，成为那个问"which definition"的人。

第三个文档："My First Fire"。记录你参与或观察的第一个incident，无论大小。不是写postmortem（那是on-call engineer的事），而是写你的learning：什么信号被忽略了，什么检查能更早发现问题，为什么现在的monitoring没 catch。这个文档在第60天回头看，会是你成长曲线的硬证据。

不是A，而是B：不是"我懂了"，而是"我能指出哪里不懂，并且知道该问谁"。

第31-60天：从"执行者"到"质量守门人"

这个转折点通常以一个具体事件为标志：你第一次说"不"。

场景：Product manager在JIRA里建了一个ticket，要求"把user table和order table join起来，加一个lifetimevalue字段，今天下午要"。错误版本的新人：开始写SQL，发现user table有12个版本（mobile signup、web signup、organic、paid、merged account...），order table的currency有四种且没统一汇率，lifetimevalue的定义是GMV还是net revenue不明确。六小时后交付一个看起来对但没人能verify的query。

正确版本的新人：回复ticket，不是"这个需求有问题"（对抗性），而是"为了今天下午交付，我需要确认三个假设：[1] user definition用哪个版本 [2] currency统一用USD还是保留原币种 [3] lifetime_value是GMV还是net revenue。如果[1]用merged account deduped、[2]USD EOD rate、[3]GMV，预计2小时交付；如果[3]改net revenue，需要加COGS table access，明天上午交付。请确认。"这个回复的隐藏信息是：我懂业务复杂性，我能管理期望，我不是一个只会执行的工具人。

不是A，而是B：不是"我做不到"，而是"我能做到，但需要明确边界条件"。

具体insider场景：debrief会议，讨论一个delay了三次的project。Data engineer Mike说："product team老改需求。"Data engineer Lisa说："我第一次就列了五个assumption让他们confirm，他们confirm了三个，两个说'你决定'。我把那两个的decision和risk写进ticket comment，cc了他们的director。后来改需求时，director说'我们不是confirm过了吗'。"Project manager补充："Lisa的版本，我们delay是因为业务优先级变化，不是scope creep。Mike的版本，我们连最初要什么都不知道。"Lisa在第45天被promoted到senior。

第61-90天：建立"可传承的判例"

前60天你积累的是个人信任，第61-90天要把它转化为组织资产。

具体标志：你开始写"decision record"——不是技术文档，是"我们为什么没选那个方案"的记录。比如："2024-03-15，评估了SCD Type 2 vs daily snapshot for customer_attributes。选snapshot因为：[1] 历史查询模式是point-in-time，不是temporal trend [2] 团队MySQL背景，Type 2的query pattern learning curve太高 [3] storage cost < engineer time cost at current scale。Revisit when row count > 50M or query latency > 2s。"

这个文档的价值在第180天、第365天会显现。当新的人问"为什么不用Type 2"，当scale真的突破阈值，当manager问"这块的业务逻辑谁最清楚"——你的名字会和"清晰思考"绑定。

薪资预期的现实校准：第90天通常是第一次informal check-in，正式review在第6个月。但如果前90天没有"exceeds"的信号，6个月review很难翻盘。Base $120K-$180K的band内，第6个月通常没有raise，但前90天的表现决定你是否进入"high potential" pool，这直接影响第12个月的promotion timeline和RSU refresh。RSU refresh的差距可能是$20K vs $60K，不是小数字。Bonus是滞后的，通常基于calendar year performance，但allocation percentage在年初就已由前一年rating决定。

准备清单

  1. 入职前一周：向recruiter或hiring manager索要"前30天必读"——不是onboarding doc，是最近一次postmortem和current quarter的OKR。如果得不到，这是第一个red flag。
  1. 第1天：约五个30分钟1:1，优先级：manager > 直属senior > 下游consumer ×2 > infra contact。准备同一个问题："如果我只能做一件事让这块数据更好，应该是什么？"
  1. 第3天：画出第一张数据流图，贴在工位。每天update一个节点。第30天，这张图应该能回答任何新来的人的80%问题。
  1. 第7天：找到第一个"definition dispute"，记录，但不急于解决。你的角色是arbitrator，不是dictator。
  1. 第14天：完成第一个不借助senior的独立判断——可以小，但必须完整：发现问题、分析impact、提出options、recommend one with trade-offs。
  1. 系统性拆解面试结构（PM面试手册里有完整的数据工程岗位ramp-up框架实战复盘可以参考），重点看"前90天信任建立"章节的技术-业务翻译案例。
  1. 第30天：向manager提出第一个"不该做"的判断，附带替代方案。这不是show off，是建立"invested in right outcome"而非"compliant"的形象。
  1. 第45天：完成第一个"质量守门"事件——阻止或修正一个可能产生错误数据的决策，留下书面记录。
  1. 第60天：建立第一个"decision record"，主题不限，但必须是"我们考虑过X，选了Y，因为Z，revisit条件是..."。
  1. 第75天：找一个跨team的presentation机会，不是showcase你的work，而是teach一个你发现的pattern或lesson learned。
  1. 第90天：整理"trust account"证据包——三个你阻止的错误决策、两个你clarified的定义、一个你建立的decision record。这是self-review的弹药，也是manager帮你fight for rating的素材。

常见错误

错误1：把"问问题"当成"好学"的唯一形式。

BAD：每天Slack上问senior "这个字段什么意思""那个job怎么跑"，问题碎片化，没有context，对方需要花20分钟reconstruct你的situation。

GOOD：每周整理一个"batch question list"，按主题分组（如"user identity resolution"），附带你已做的research和remaining uncertainty。发给senior时写："关于[topic]，我查了[doc/code]，理解了[abc]，不确定的是[xyz]，想约20分钟对齐。"不是减少提问量，是提高提问的"信息密度比"。

错误2：急于"留下技术印记"，在不了解政治地图时重构legacy。

BAD：第30天提交PR，要把一个运行两年的Spark job迁移到dbt，理由是"modern stack"。PR description写满了技术收益，没提：这个job的owner是即将review你的architect，下游有三个dashboard依赖它且没有test coverage，migration期间正好赶上monthly close。

GOOD：第30天，提交一个RFC（Request for Comments），标题："Evaluating dbt migration for [job name] — 30/60/90 day view"。内容：current state pain points（从on-call log里找evidence，不是"我觉得"）、proposed approach（phased，with rollback plan）、risk mitigation（stakeholder sign-off checklist）、decision deadline（suggest第60天go/no-go）。即使最后没迁移，你建立了"technical change management"的reputation。不是A，而是B：不是"我技术牛"，而是"我能让技术变化安全发生"。

错误3：忽视"非技术stakeholder"直到被迫对接。

BAD：第45天，first business review meeting，PM问"这个数为什么跌了"，你回答"我看看"，然后现场写SQL，会议室沉默15分钟。

GOOD：第45天之前，主动约每个你支持的business team的analyst喝咖啡。问的不是"你们需要什么数据"，而是"你们上次被challenge的决策是什么，数据帮上忙了吗"。你会听到："我们其实不知道该信哪个dashboard"，或者"CEO问了一个问题，我们花了三天才发现两个team的definition不一样"。这些信息不会出现在任何技术文档里，但会定义你工作的真正优先级。不是A，而是B：不是"我支持业务"，而是"我理解业务的疼痛，并用数据工程能力缓解它"。

FAQ

Q1: 如果入职发现团队没有data quality framework，我应该在90天内建立吗？

判决是：不，除非你被explicitly hired to do so。前90天建立framework的尝试，90%会失败，因为你会同时对抗技术债务、组织惯性、和"新来的想改天换地"的perception。正确策略是：先成为"质量问题的可靠reporter"。每次发现数据异常，记录：影响范围（哪些dashboard/决策受影响）、root cause（是pipeline bug、source change、还是definition ambiguity）、detection gap（为什么现有机制没 catch）、prevention suggestion（不是"我们需要framework"，而是"这个check可以加在这个job的这里"）。攒够5-10个cases，在第60-90天以"pattern I've observed"的形式present给manager和senior engineer。如果consensus是"确实需要systematic solution"，这时候你naturally become the lead。案例：某SaaS公司新人，第45天发现客服团队每周花四小时manually reconcile两个系统的ticket count，因为integration有race condition。他没有提"我们要建data quality framework"，而是写了一个15行的Python script做自动校验，发到客服team的Slack channel。第70天，customer success VP在all hands上 mention 了这个"小工具"，engineering director问他愿不愿意scale到全公司。第90天，他的OKR里多了一条"foundational data quality infrastructure"，headcount也加了。

Q2: Manager前30天不给clear direction，只说"你先看看"，怎么办？

这是最常见的ramp-up trap，尤其是对海外背景或high-context culture不适应的人。判决是："看看"不是指令，是测试——测试你是否能自己定义优先级和成功标准。不是A，而是B：不是等clarity，而是创造clarity。具体做法：第7天，向manager提交一个"我的前30天计划"draft，包括：我计划了解的三个业务领域、每个领域的success criteria（不是"了解lending"，而是"能独立回答lending team关于portfolio performance的常规数据问题"）、我需要access的资源、我计划deliver的一个quick win（越小越好，最好是2-3天的project）。问的不是"这样可以吗"，而是"这三个优先级里，如果只能成一个，哪个对你的Q1 goal影响最大"。这个framing把burden从"你告诉我该做什么"转为"我propose，你arbitrate"，这正是senior engineer的工作模式。案例：某Fintech新人，manager前三周都在travel。她发了三次计划draft没回复，第四次直接约15分钟phone call："我拟了两个option，A是深入credit risk模型支持Q1 regulatory filing，B是优化marketing attribution的latency支持campaign launch。我倾向于A因为和你上次提的regulatory priority一致，但需要你的sign-off on access request。如果这周不能decide，我需要先start B因为deadline更紧。"Manager当天回复，并apologize for delayed response。第90天review，manager的feedback是"她drove her own onboarding"。不是"她需要direction"，而是"她创造了direction"。

Q3: 第90天绩效评估前，如何准备self-review才能最大化rating？

判决是：不要写"我做了什么"，要写"我改变了什么"。不是A，而是B：不是activity log，而是impact narrative。结构：每个achievement用"Situation-Complication-Resolution-Impact"框架。Situation不是背景介绍，是stakes——"Q1 regulatory filing依赖的NIM calculation，有三个相互矛盾的source of truth"。Complication是你的具体obstacle——"两个team各自defend自己的definition，legal要求72小时内resolve"。Resolution是你的action，要具体到decision making process——"我proposed freeze on new definition proposals，convened cross-functional working session，identified root difference in accrual timing，recommended and got sign-off on monthly average balance method"。Impact要quantify if possible，但qualitative也接受——"filing submitted on time with zero revision cycle，vs. previous quarter's 3 rounds"。准备三个这样的narrative，分别对应technical excellence、business impact、collaboration。如果有一个narrative横跨两个维度，那是你的lead story。第90天review通常只有30-45分钟，manager已经form opinion，你的目标是provide language that helps them advocate for you in calibration meeting。不是defense，是offense——给manager ammunition。案例：某候选人self-review写了"completed 12 tickets，participated in 5 sprint ceremonies，attended onboarding sessions"。Manager在calibration meeting几乎无法speak to her contribution。重写后："prevented $2.3M misattribution by identifying event naming collision（business impact）；established decision record pattern now adopted by 3 other teams（technical excellence & collaboration）；onboarded 2 new hires on data lineage tooling（growth）。"Calibration后rating从meets上调至exceeds。不是文字游戏，是framing power。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。