描述你合作过最以客户为中心的人。

考察要点

这道题看似在问别人，实则在考察你自己的行为。它考察的核心是：

1. Customer Obsession (客户至上)：你是否能识别、欣赏并学习真正的“客户至上”行为？你对“客户至上”的定义是什么？它不是简单地听客户的话，而是深入挖掘客户未被满足的潜在需求，并为之创造价值。
2. Learn and Be Curious (好奇求知)：你是否能从优秀的同事身上学习，并将他们的优点内化为自己的行为准则和工作方法？
3. Ownership (主人翁精神)：即使问题最初不是由你发现的，你是否会主动承担责任去推动解决？

高分示范答案（STAR）

Situation（背景） 我在前公司（一家电商平台）担任搜索推荐团队的资深工程师。当时我们团队的核心目标是提升搜索结果页的点击率（CTR）。团队大部分成员都专注于算法模型的调优和 A/B a testing。但我观察到我们的一位产品经理 Anna，她的工作方式与众不同。

Task（任务） 当时，我接到的任务是优化一个特定品类（比如“运动鞋”）的搜索排序算法，目标是在一个季度内将搜索点击率提升 5%。然而，Anna 让我意识到，真正的任务应该是解决“用户搜了但找不到满意商品”的根本问题，而不仅仅是提升一个中间指标。

Action（行动） Anna 的“客户至上”行为深深影响了我，我采取了以下行动：

• 学习并深入一线： 我观察到 Anna 每周会固定花半天时间，不是开会，而是泡在客服工单系统里，阅读最真实的用户反馈。受她启发，我不再只盯着数据报表。我主动向 Anna 申请了客服工单系统的只读权限，并利用一个周末，筛选分析了近 500 条关于“搜索不准”和“找不到东西”的用户投诉。
• 发现真实痛点： 通过分析工单，我发现了一个高频场景：大量用户抱怨，在搜索“某品牌运动鞋”后，无法筛选出“当季新款”。他们只能一页页地翻，体验极差。而我们后台的“新品”标签是全局性的，无法与“品牌”维度做组合筛选，这是个技术盲点。
• 推动技术方案落地： 我整理了这些用户原话和数据，向团队证明这不是个例，而是一个普遍痛点。然后，我主动设计了一个技术方案：改造我们的倒排索引，为商品增加一个动态的时间戳属性，并优化查询引擎以支持多维度的组合查询。起初，有同事担心改动核心索引风险大、工作量高。
• 用行动化解阻力： 为了说服团队，我利用业余时间，花了两周搭建了一个最小可行性原型（MVP），并导入了部分真实数据。我向团队现场演示了在新旧方案下，搜索“耐克新品”的结果差异。看到原型效果后，团队的疑虑被打消了，最终同意将这个功能纳入下一个开发冲刺。

Result（结果） 新功能上线后：

• 针对特定品牌的“新品”筛选功能，其使用率在第一个月就达到了该品类搜索总量的 12%，远超预期。
• 更重要的是，相关品类的用户复购率在接下来一个季度提升了 5%，证明我们解决了真实的用户留存问题。
• 客服侧关于“找不到新品”的工单数量，在一个月内下降了超过 70%。
• 我从 Anna 身上学到：真正的客户至上，是主动走出自己的技术世界，去寻找数据背后那个活生生的人和他们真实的困境。

低分陷阱（常见扣分点）

• 只描述别人，没有“我”的行动：反例：“我的同事 Anna 非常客户至上，她经常看用户反馈，还和用户访谈，她真的很棒。”（然后呢？这和你有什么关系？）
• 把“客户至上”理解为“满足客户所有要求”：反例：“有个客户想要一个很奇葩的功能，虽然不合理，但为了客户至上，我们就加班帮他做了。”（这体现不出你的判断力和对更广大用户群的责任心）。
• Result 虚化，没有量化：反例：“我们上线了新功能，用户反馈很好，项目很成功。”（“很好”是多少？怎么衡量的？面试官无法评估你工作的影响力）。
• Action 停留在“想”或“说”，没有“做”：反例：“我建议团队应该多关注用户反馈，而不只是看数据。”（然后呢？你为了这个建议做了什么实质性的推动工作？）。

高概率追问（3 个 + 示范回答要点）

1. 追问：当同事最初反对你的技术方案时，你是如何具体说服他们的？除了做原型，你还做了什么？

   • 要点1（数据驱动）：强调你不是空口白话，而是展示了具体的、量化的证据。例如，“我把那 500 条工单分类整理成一个表格，用图表展示‘新品筛选’是 Top 3 的抱怨点，这比任何口头描述都有力。”
   • 要点2（风险管理）：表明你考虑到了他们的担忧。例如，“我主动评估了修改索引的风险，并提出了一个灰度发布计划：先在一个小流量的品类上线，验证稳定性后，再逐步推广到全站，把潜在影响降到最低。”
   • 要点3（寻求支持）：可以提及你争取了关键人物的支持。例如，“在团队讨论前，我先和我的经理以及 Anna 做了沟通，他们都认为这是个高价值的方向，这在会上给了我很大的支持。”

2. 追问：除了看客服工单，你还通过哪些方式去理解客户需求？

   • 要点1（数据分析）：提及对用户行为数据的深入挖掘。例如，“我会分析用户的搜索日志，看哪些搜索词的点击率为零，或者用户在搜索后快速离开了，这些都是潜在不满意的信号。”
   • 要点2（跨部门合作）：体现你主动链接其他团队。例如，“我定期会和市场、销售同学交流，他们在一线能听到很多我们工程师听不到的声音。”
   • 要点3（亲身体验）：展示你的代入感。例如，“我会强制自己每周至少花一小时，像真实用户一样在我们的 App 上购物，或者去竞品 App 上体验，寻找可以改进的地方。”

3. 追问：这个故事里，你最大的收获是什么？这个收获如何影响了你之后的工作方式？

   • 要点1（思维转变）：从“功能交付”到“价值创造”。“我认识到，工程师的职责不只是写代码实现 PRD，而是要对最终的用户价值负责。从那以后，每次接到需求，我都会先问‘我们为什么要做这个？它解决了谁的什么问题？’”
   • 要点2（工作方法改变）：将客户洞察融入日常工作流程。“我养成了一个习惯，在每个项目启动时，都会主动去寻找相关的用户原始反馈（录音、工单、评论等），而不仅仅是看产品经理提炼过的需求文档。这让我对需求的理解更深刻。”

故事复用建议

这个故事非常扎实，可以灵活调整侧重点，用于回答以下问题：

• Ownership (主人翁精神)：强调你如何主动发现非本职的问题，并承担责任推动解决。
• Bias for Action (崇尚行动)：强调你如何通过快速构建原型来打破僵局，而不是无休止地开会讨论。
• Deliver Results (交付结果)：强调最终实现的、可量化的业务和用户价值。
• Invent and Simplify (创新简化)：强调你如何通过技术创新（改造索引）来解决一个看似无解的用户体验问题。
• Dive Deep (深入钻研)：强调你如何不满足于表面数据，而是深入挖掘客服工单和用户行为日志。
• Disagree and Commit (敢于谏言，服从大局)：可以展开描述与同事意见不合时，如何有理有据地表达异议，并在团队决策后全力投入。