正如我们在行为面试准备概述中提到的,解决问题和追求结果是准备的8个主要问题类别之一。
在本指南中,您将学习如何解决它们:
- 详细的评估标准
- 将可能的问题抽象成常见主题
- 建议的答案框架
- 后续问题的可能性质
- 示例问题和答案
详细的评估标准
解决问题和追求结果被归为一类,因为它们本质上高度相关。在描述解决问题或实现某些结果/目标方面的经验时,也可以推断出他们的心态或这样做的动力。
在对该类别下的候选人进行评分时,面试官通常会关注以下标准:
- 确定最佳解决方案并执行
- 确定正确的问题
- 确定最关键的目标
- 足智多谋和数据驱动的思维方式
- 创造力和创新
- 确定权衡和可持续的解决方案
- 衡量结果、迭代和跟进
- 结果导向的心态
- 尽管存在障碍或障碍,仍积极主动地取得进展
- 影响他人实现目标
- 平衡分析与果断行动
将可能的问题抽象成常见主题
正如我们在行为面试准备概述中提到的,为每个现有的行为问题专门准备答案是不切实际的。但是,通过将特定问题归入相似的主题,并准备涵盖大量问题要求的案例,我们可以将需要准备的案例数量减少到大约3-5个。
可以提出的解决问题和追求结果的行为问题类型实在太多了,例如:
- 您能否告诉我您曾经使用数据来驱动工程决策的经历?
- 您能否提供一个您必须在项目中排除故障并修复复杂问题的例子?
- 您能否描述一下您曾经创造性地解决了一个工程问题或实现了有意义的指标改进的经历?
- 您能否描述一下您曾经必须做出重要的工程决策以及您如何在权衡之间做出决定的经历?
但是,当我们查看该类别下的 80% 的问题时,问题通常会询问如何解决问题或有效解决问题所需的特定特质,例如创造力、使用数据或权衡评估。问题的根源或目标,以及候选人在面对障碍时是否具有韧性,也可以从对这些问题的回答中推断出来。
建议的回答框架
和往常一样,我们推荐使用 STAR 格式 作为最简单、最有效的框架来构建你的故事。
尽管问题可能性很多,但我们可以通过思考一个稳健的解决问题的过程来抽象出所有解决问题行为问题的要求:
- 问题识别:从表面症状中识别出要关注的正确根本原因或根本问题
- 指标/目标设定:确定解决问题(如果有)时将标志成功的关键指标
- 信息收集:从不同来源收集信息的资源能力和数据驱动的思维模式(使用数据来驱动决策)
- 解决方案头脑风暴:创造性地生成解决根本原因的解决方案
- 解决方案评估:评估每个解决方案的权衡,并选择最佳方案
- 监控和调整:通过衡量关键指标来监控解决方案的有效性。如果需要,调整策略
因此,您只需要确保您的准备好的故事或项目至少涵盖了上述所有步骤。通过这样做,该故事可以重复用于解决问题下的所有相关特征,例如数据驱动的思维模式、资源能力、创造力和与用户反馈合作。
当然,你可能需要根据故事的细节来侧重于特定问题中提出的具体方面。
我们建议您也选择可以同时用于获取以下信号的解决问题的故事:
- 主动性/积极性:您主动调查问题、收集信息并解决问题
- 领导力:您主导了解决问题的过程
- 团队合作:您必须作为团队的一员来解决问题
案例故事
这是一个使用STAR格式的案例故事。
情境:我是一家销售奢侈品的电子商务网站的技术负责人。该网站是作为Angular 1.5单页应用程序构建的。近年来,该产品已经显现出它的老化——开发人员的体验并不好,而且网站的性能很差。初始加载速度超过3秒,转化率约为0.8%。
任务:我的任务是提高网站的性能和转化率。
行动
- 问题识别
- 转化与网站性能和用户体验相关
- 过去几年,由于没有专人监督网站的整体架构和跟踪性能指标,网站性能一直在逐渐下降
- 用户体验有一段时间没有被关注了
- 信息收集
- 查看了过去一年中错误的性质,根据其根本原因进行分类,以确定热点和主要问题区域。
- 收集了团队关于改进领域方面的反馈。
- 与产品经理一起,与团队进行了一次头脑风暴会议,以思考改进方法。
- 为了改进,首先我们需要知道我们做得如何:
- 再次检查我们的性能和转化跟踪是否正常工作。
- 开始跟踪来自Lighthouse和Core Web Vitals的新指标。
- 与数据科学家合作,提出了性能和转化的仪表板,并获得了一些见解:
- 确定了一些国家的转化率较低。
- 与桌面用户相比,移动用户的转化率较低。
- 与用户体验设计师和用户体验研究人员合作,以确定网站上端到端购物体验中的问题。
- 用户界面元素之间的间距太大,需要大量滚动,这影响了跳出率,因为一些用户懒得滚动。
- 解决方案头脑风暴
- 用户界面:服务器端渲染对其性能和SEO有益至关重要。围绕良好的性能做出选择。
- JavaScript框架:从Angular.js 1.6迁移到Angular 17是一项巨大的工程,而且由于Angular 17是一个完全不同的框架,因此停留在Angular上并没有节省多少时间。
- Next.js:我们的一些开发人员具有使用React和Next.js的经验,作为构建SSR(服务器端渲染)应用程序的元框架正在迅速普及。我们确实希望Next.js提供的快速初始加载和类似应用程序的导航行为。
- Svelte:响应式模型很有吸引力,并且与React相比,编程模型更容易理解,但是生态系统比React小,并且没有那么多用Svelte构建的成功的电子商务网站的例子。
- 样式:由于多年来添加了许多类并且难以删除,样式表变得非常臃肿。
- Tailwind CSS:Tailwind CSS是最热门的CSS方法之一,其原子CSS方法可以很好地扩展到不断增长的代码库。
- Styled Components:CSS-in-JS也是我们正在关注的,但是Styled Components与React相关,并且运行时样式注入对性能不利。
- 以性能为中心的思维模式:阅读了许多关于web.dev和其他电子商务公司工程博客的性能案例研究,收集了一份重要的性能技术和流程清单:
- 为每个页面设置性能预算(低于300kb)
- 将性能基准测试作为CI的一部分运行——在合并Pull Requests之前和持续进行
- 延迟加载非关键组件
- 延迟加载低于折叠的内容
- 在页面级别而不是单个捆绑包上拆分JavaScript(由Next.js处理)
- 对图像使用WebP格式
- 在CDN上托管图像
- 图像的自适应加载,以便移动设备加载较小的图像
- 合并重复的JavaScript库(data-fns和moment.js),切换到
lodash-es
,删除了所有jQuery的用法 - 查看数据以识别较少使用的功能并将其从代码中删除,从而将产品详细信息页面上的JS大小减少了200+kb
- 搜索引擎优化(SEO)
- 使用Ahrefs等SEO工具持续监控SEO
- 与营销团队合作,确保营销文案包含Ahrefs显示的重要关键词
- 调整页面URL以包含SEO关键词
- 用户体验改进
- 单页结账体验,而不是两页结账,以减少点击次数
- 减少许多用户界面元素的高度
- 修复不会被错过的结账按钮
- 付款改进
- 分析了Stripe结账数据并实施了特定于国家/地区的地址字段
- 最初只有一个可用的付款方式——信用卡。 寻求数据科学家的帮助,以评估新付款方式的受欢迎程度以及它们是否值得添加。 后来我们还添加了PayPal、Google Pay和Apple Pay付款方式
- 用户界面:服务器端渲染对其性能和SEO有益至关重要。围绕良好的性能做出选择。
- 解决方案评估
- 元框架:选择Next.js,因为它由一家公司支持,有许多可用资源,并且拥有最大的社区。 React也是最受欢迎的JavaScript库,也最容易招聘
- 样式:Tailwind,因为它是一个可靠且面向未来的选择(与React的发展方向兼容)
- 监控和调整
- 在为期2个月的时间内,在A/B测试的背后推出了新网站,同时监控性能和转化率。
- 以前转化率较低的国家/地区,转化率提高了近50%。
结果
- Lighthouse分数提高到92
- 加载速度提高到1.5秒
- 转化率提高到2.5%
- 最近的调查显示,开发人员的速度有所提高,现在更容易将人员招聘到团队中,因为更多的人比其他框架更了解React
显然,整个故事作为对单个问题的回答过于详细;您绝对不应该像列清单一样列出您所做的所有具体性能改进! 旨在通过简要介绍“行动”部分中的每个阶段,并深入研究展示该特定场景所需信号的部分,从而实现广度和深度。
可能的后续问题性质
正如我们在行为面试准备概述中提到的,鼓励面试官更多地依赖后续问题来真正了解候选人的思维过程和动机,这些通常属于以下类别:
- 你认为你为什么做了(插入操作)?
- 你为什么不做(插入操作)?
- 事后看来,你将如何做不同的事情?
对于解决问题或追求结果的问题,面试官很可能会探究问题,以帮助他们更多地了解:
- 任务/问题/目标的来源(主动性和主动性的理解程度):
- 项目或任务是你发起的吗? 程度如何?
- 潜在的想法来自你,还是仅仅是执行计划?
- 你是如何获得利益相关者的支持,甚至开始着手这项工作的?
- 候选人的角色和实际贡献:
- 是否有一个团队参与解决问题或实现目标?
- 哪些行动是你自己主动发起的或完全由你贡献的,其他人做了什么?
- 你是如何帮助其他参与者实现目标的?
- 确定要解决的问题或目标:
- 是否有原因导致优先解决或完成这个特定的问题或目标,而不是其他问题或目标?
- 是否有另一个问题或根本目标应该更重要?
- 这个问题是否已经被公司内的另一个团队解决了? 为什么必须重新发明解决方案?
- 选择适当的指标/目标,以及它们是否在发布后进行了衡量:
- 是否设定了任何定量或定性目标,以及如何决定的?
- 它们是如何在发布后衡量的,结果是什么?
- 如果一个问题得到解决,采取了哪些措施来确保同样的问题不会再次发生?
- 使用足够的信息来驱动决策:
- 你依赖什么类型的研究或数据来做出决策/选择要解决的问题?
- 你花了多少时间进行研究和收集信息?
- 你是如何平衡收集信息/计划和实际执行计划的?
- 选择正确的解决方案:
- 考虑了哪些其他解决方案,以及每个解决方案的优缺点是什么?
- 为什么选择了最终的解决方案?
- 谁提出了解决方案的最初想法? 它们是如何产生的?
示例问题解决问题和答案
上面的示例故事也可以通过提取相关部分来定制,以回答具体问题:
你能告诉我你曾经使用数据来驱动工程决策的经历吗?
详细说明关于转化表现的部分。
你能提供一个例子,说明你曾经不得不排除故障并修复项目中复杂问题的经历吗?
详细说明关于调查转化率低下的原因的部分。
你能描述一下你解决工程问题或实现有意义的指标改进的经历吗?
详细阐述关于迁移到服务器端渲染和应用现代性能技术的部分。
你能描述一下你曾经不得不做出重要的工程决策以及你如何在权衡取舍之间做出决定的经历吗?
详细说明关于选择要迁移到哪些框架以及做出这些决定的原因的部分。