数据分析师或数据科学家岗位的简历与通用软件工程师简历的差异主要在于强调什么，而不是基本结构本身。倒序排列的工作经历、简短的个人简介，以及以结果为导向的要点仍然适用，但以数据为核心的简历会以一项分析回答了什么问题、以及它改变了什么决策来开头，并如实说明数据的规模与来源，而不是依赖产出这个答案的流水线或模型本身。一个做好的仪表盘、一个训练好的模型或一条干净的流水线，本身并不是简历上值得一提的成果；团队因此而做出的不同决策才是。
为什么数据密集型工作的重点会发生变化
通用软件工程师的简历通常凭借上线的东西获得认可：一个功能、一个服务、一个现在正在生产环境运行、用户能够指出来的系统。数据密集型工作的回报形式往往不同。一份领导团队用来在两个方案之间做选择的报告、一次改变了市场预算分配方式的用户细分、一次在问题波及下游系统之前发现数据集真实问题的检查，这些都不像一个上线的功能那样显而易见。这类岗位的简历必须明确写出决策本身，而不是指望读者把一张图表或一个模型和后续发生的事情联系起来。这种表达方式对分析师和数据科学家岗位尤为重要，因为他们日常产出的往往是对某人真正提出的问题的回答，而不是用户直接使用的功能。
写清项目回答了什么问题，而不只是用了什么工具
以工具开头的一条要点，比如"使用Python和scikit-learn构建客户流失预测模型"，在告诉读者工作为什么重要之前，先告诉了读者用了什么技术。以工作回答的问题开头的要点，则先把成果交给读者：多个入职步骤中哪一步最能预测客户会在两个月内取消，某项拟议的定价调整是否可能在某个地区减少注册量，两个相互竞争的产品改动中团队应优先做哪一个。工具仍然可以出现在这条要点里，只是位置靠后，等读者已经知道这项分析为何存在之后再提。这种顺序对数据密集型工作比对许多通用工程工作更重要，因为一项分析被设计来回答的问题，往往是团队之外的读者最容易看懂的部分。
如实描述数据：规模、来源与范围
如实说明一个项目实际处理的数据规模和形态，能让读者对量级有直观感受，而不需要一个凭空编造的精确数字。诚实的描述会写出你确实记得或能够核实的内容：大致涉及多少条记录或多少行，合并了多少个独立来源来构建数据集，数据回溯了多久，以及这项工作是一次性分析还是按计划周期性运行。如实说明范围，例如"合并了三个内部系统约两年活动周期的数据"，比起一个关于分析影响的、无法核实的编造统计数字，更经得起追问。如果一项分析确实改变了某个被追踪的指标，而这个数字现在依然能够指出来，那么它应该直接写进简历；如果没有这样的数字，范围和它促成的决策同样能撑起这条要点。
按流水线所处阶段对工具分组
数据岗位的工具清单往往同时横跨查询语言、建模库、可视化工具以及调度或编排系统，按每个工具在流水线中所处的阶段分组，摄取、转换、分析与建模、再到报告或可视化，比起一整行未经整理的清单，能让读者更快读懂候选人经验的整体形态。想寻找能够端到端负责整条流水线的人，读者可以从四个简短的流水线阶段分组中立刻看出这种形态；专门寻找建模经验的读者，也可以直接跳到那一组，而不必读过一个调度工具和一个可视化工具才找到它。
示例说明：围绕促成的决策写成的一条要点
示例说明，改写前后对比。改写前，以工具为主导："使用SQL和Python分析客户使用数据并构建流失模型。"改写后，以问题与决策为主导："分析了两条产品线约十八个月的使用数据，以确定哪一个入职步骤最能预测六十天内的流失；这一发现促使产品团队重新设计了那一个步骤，而不是整个入职流程。"改写后的版本没有编造任何百分比或这个人实际无法描述的结果，它写明了问题、数据的大致范围，以及这项发现促成的决策，这些都是这个人真正亲身经历过的事。
量化影响的原则依然适用
在简历的任何地方都适用的、对编造数字的谨慎态度，在这里同样适用：一个来自仪表盘或报告、现在仍能核实的真实数字值得直接写出来，而一个凭记忆印象四舍五入成的整齐百分比则不值得。在不编造数字的前提下量化工程影响对这一区别有更深入的讨论，同样以范围和决策为主的方法，用在数据密集型要点上和用在通用工程要点上一样有效。
立即开始撰写
CVBuilderKit的Developer模板围绕以项目和成果为主导的条目设计，既适合应用代码，也同样适合数据分析师或数据科学家的项目清单。从这个模板开始，或者从一个空白文档开始，在编辑器中撰写，让每条要点先写清项目回答了什么问题，再说明是什么工具给出了这个答案。