Oracle首席工程师:技术面试中,怎样的问题才是好问题?( 四 )


显然 , 我们的面试要尽可能避免这样的事情在真实世界中发生 。 我们要找的是软件工程师 , 不是只会刷题编码者 。
这也是我把这个案例放在开头 , 作为反面案例的原因之一 。 等等 , “之一”?!难道还有别的原因?
是的 , 这还没完 , 这个案例还有着其它弊端 , 我想再卖个关子——而现在 , 你可以想一想 , 再往下看 。
四、怎样的问题才是 “好” 问题?
终于要正面回答标题中的问题了 , 到底怎样的问题才能真正称得上 “好” 问题呢?
下面是我认为最重要的几条衡量标准:
1、从模糊到清晰
首先 , 这个问题在一开始要足够模糊 , 以便让候选人可以逐层递进 , 逐步细化 , 寻根究底 。
这个过程 , 其实就是将 “具体问题” 经过分析、归纳、思考、抽象并将其映射成为一个 “软件问题” 的过程 。
在问题变得清晰的过程中 , 理想的情况是 , 候选人可以表现出主动性 , 即候选人可以在多数情况下引领讨论的思路 , 而不是面试官 。 面试官需要顺着候选人的思路 , 逐步框定下问题的讨论范畴 , 并明确到其核心实现是确实可以用软件的办法实现的 。
在这样的状态下 , 候选人可以以自然的状态 , 具备相当自由度地发挥自己的能力 。 从这个过程中 , 可以观察得到候选人不同角度的特质了 。
通过这种方式 , 也可以很大程度避免了已经知道 “标准答案” 的面试官 , 由于思路的局限性 , 而给面试施加源自于主观偏好的影响 。
这就好像是开放世界的 RPG 游戏 , 有多个不同的路径都可以完成任务 , 玩家可以决策并决定主角的走向 , 但是这一切始终还要在游戏设计者的掌控之内 。 这当然是说的理想状态 , 有时候会有偏差 , 但我们朝着这个方向努力 。
所以这也对面试官驾驭不同的状况有着很高的要求 , 毕竟面试官要对这个问题前前后后足够的熟悉 , 以便应对各种不同的细化场景 。 有一个常见的方式 , 是可以从一个自己已经足够熟悉的问题开始 , 比如自己曾经多年工作涉及的某类系统 。
我来举一个具体例子 。 比如 , 有这样一个问题:
怎样设计一个流量控制系统?
这就是一个模糊到没法再模糊的问题了 。 不知你会不会产生下面这样的问题:

  • 什么系统需要流量控制?
  • 现在的流量是多少?
  • 需要支持到什么时间精度?
  • 流量控制的规则怎么定义?
  • 超过流量的请求怎么处理?
  • ……
其实 , 这些都或多或少是需要面试官和候选人一起逐步思考、分析和明确的 。 在这个过程中 , 可以考察到的内容太多太多了 。
事实上 , 针对不同程度的候选人 , 上述这个问题给出的最原始的模糊程度是不一样的 , 问题越是模糊 , 对于候选人的要求也就越高 。 对于一个工作十多年的 , 有着多年系统设计经验的工程师来说 , 上面这些问题大致都应该是他/她能够主动提问 , 或是主动引领以致明确的 。
值得一提的是 , 理想的问题里最好还有一些隐藏的 “坑” 。 候选人能否把这些坑识别出来 , 也是对于工程能力方面一个很好的考察点 。
比方说 , 优秀的候选人应该想到 , 流量控制可以基于绝对时间窗口 , 或是相对时间窗口来进行 , 但是要真正保护系统 , 相对时间窗口才是最理想的 。 当然在实现难度上 , 相对时间窗口往往会更难一些 。
而对于一个没有工作经验 , 并将要研究生毕业的候选人来说 , 问这样一个模糊的问题 , 往往带来了过大的难度 , 不但不容易推进面试的进程 , 还可能给候选人带来沮丧的心理 。 我们不希望看到 , 候选人拿到问题以后就懵了 , 如果发现候选人推进有困难 , 面试官需要介入并帮助 。
因此根据候选人的程度 , 这需要面试官主动回答这些问题 , 或是直接缩小或明确问题的范畴 , 当这个问题的范畴缩到最小时 , 这可以是一个存在多种解法的算法题 。


推荐阅读