B端产品面试技巧：业务调度设计的逻辑测验及分析

B端产品面试技巧：业务调度设计的逻辑测验及分析个人一直觉得产品面试是一件非常有挑战的事情，今天选择从一个角度分享B端产品的面试技巧。这是一道笔试的面试题，这道源自于老狗某日在等电梯时的突发奇想。一栋楼内有N部互相关联的电梯，当任一楼层内的用户，按下呼叫键（上／下）后，系统对接载乘客需求的响应逻辑该如何设计，目标是让电梯实现高效且合乎我们日常使用体验。这个问题，通常情况下，请作为笔试题，并给候选人至少30分钟以上思考时间。老狗当初冒出这个想法的时候，自己考自己，花了几天时间才把逻辑给抽象出来，从我实际面试经验来看，如果这个问题在当面沟通时抛给候选人的话，实时能够描绘出逻辑的人，基本为零。但这绝对是一个值得去琢磨的问题，对于提升自己的逻辑性有非常大的帮助。这个问题的本质是什么？这个问题本质上，我把它定义为“业务调度设计能力”。在B端产品经理的专业能力树中，业务调度的逻辑抽象能力，我认为是极其重要的一项基本能力，带大家一起分析下这个问题。最熟悉的场景，却不曾思考过的复杂逻辑。问题中，包含了非常多的变量：楼层数是变量；电梯数是变量；呼叫电梯的人，所处的楼层是变量；呼叫电梯的人，往上/往下的需求是变量；呼叫电梯的人，与电梯轿箱的相对位置是变量；呼叫电梯的人，往上/往下的需求，与电梯运行的相对方向，也是变量；目标是高效的接载逻辑，高效背后代表了以下诉求：较低的使用能耗；运行过程中尽可能多的进行接载送达；满足整体的快速接载及送达；在逻辑高效的基础上，确保逻辑架构的合理，便于扩展其他分支逻辑，比如：考虑轿箱内乘客的体验，当前楼层距离呼叫楼层过近时，不能瞬间停靠，需要排除；某一轿箱故障/检修时，需要排除；某一轿箱满载时，需要排除；某一轿箱长时间停滞时（被人卡门），是否要排除候选；更多；所以，如果你是电梯软件系统的产品经理，你认为接载的业务调度逻辑该如何设计呢？一、如何设计？业务调度的逻辑思考：依据效率优先原则，优先考虑优先条件全部满足的场景。其背后的逻辑，与我们赶火车时的逻辑非常类似：当我们要从杭州去上海的时候，假设每趟火车的时长都一致的情况下，我们应该如何选择火车？赶火车时的常理思维：选择当前所有已发列车中，最快到达杭州站的火车且往上海去的，然后顺路上车是最快的。相对我而言，虽然发车但反向开走的火车，我都会排除掉。如果没有向杭州来且往上海去的运行中的火车，则我会考虑未发车的火车。电梯场景下的业务调度设计：电梯按下呼叫按钮瞬间，我们需要选出一个目标电梯来接载。在触发按钮的状态下，电梯可以分成“运行状态”，和“静止状态”两个分类：为了节能，我们优先考虑运行中的电梯；为了考虑具备接载的可能，选择距离最近，且顺向的电梯即为目标，若逆向直接纳入排除列表，再选择下一个距离最近的继续判断是否顺向……若运行中的电梯，没有找到顺向者，则考虑静止状态的电梯；为了节能，优先考虑距离最近的电梯且未被排除的电梯，即为目标；若都没有合适的电梯，则系统等待当前电梯任务结束后，再重新判断；核心解决思路：抽象出最关键的调度核心逻辑，同时考虑逻辑扩展的可能性。二、供参考的个人答案选出当前距离任务楼层最近，且，未被排除的电梯（被排除的可以状态很多：如满载超重、故障代码、人为卡门超时、维修暂停、节能暂停等……），判断是否有可选电梯；若有电梯，则判断该电梯是否正在执行运输任务；若是（执行中），则判断是否执行顺向任务；若是（顺向），则将任务插入该电梯运行队列，实现接载（此处可以有扩展逻辑，如顺向，但距离过近则排除等）；若否（反向），则列为“排除电梯”，并重新执行逻辑1；若否（未执行），则将任务插入该电梯运行队列，实现接载；若无电梯，则等待空余电梯通知，通知发生时，清空排除电梯清单，重新执行逻辑*所谓“顺向”的判断逻辑：呼叫指令的发起楼层，位于电梯当前楼层至行驶方向终点间的楼层间隔内（即避免方向相同，但“已过站”的问题）。三、延展思考业务调度设计过程中，高效判断逻辑，严谨的闭环设计是核心重点。其实除了电梯，还有其他很有意思的调度设计思考题。比如火车的车票，应该如何进行售卖及控制（多个站点停靠，多位置，需求只占中间的