作家先容熊燚，别名四火，现于西雅图 Oracle 任首席软件工程师一职，讲求研发云基础设施的散播式责任流引擎。曾先后任职于华为、亚马逊，作念过多种类型的研发责任赌钱赚钱app，从大小网站到高可用作事，从数据平台到可视化系统，他带领团队攻克过数个姿色难关，在全栈之路上具有丰富的实战教训。

其实很久以前就想谈一谈这个话题了，但是最近才有了满盈的动机。因为从最近参加的许多 debrief 来看，我认为身边大多数的软件工程师口试中，在通逾期候问题来考试候选东说念主这方面，许多王人作念得不够好。

比喻说，我看到一些对教训丰富的软件工程师候选东说念主的口试，不少口试官依然是粗糙地扔出一说念算法题让作念了事，况且将能不大要比拟泄漏齐全地把代码写出来行为裁定工程师级别的最热切的尺度。这样的作念法我认为詈骂常失当的。

滥觞我要明确的是，这个“问题”指的是时候口试中俗称的 “主要问题”。具体来说，即是口试官会拿出一个问题和候选东说念主筹商，并通过两边的相互疏导和问题发散来达到考试的方针。因此，这个 “问题”从某种角度来说，更像是一个 “话题”。这个经由每轮口试中平淡会执续几十分钟，接下来的内容，王人是竖立在这种口试作风和形式之上的。

其次，行为一个 disclaimer，我想说，以下内容来自于我的相识，况且是针对于时候口试这一个忐忑范围内的相识，是以天然带有主不雅的倾向性和解析的局限性，它并不来自任何公司或组织的尺度。

底下我就来尝试把这个问题阐述注解晰、讲绝对。我认为这并不是一件容易的事情，如果你对其有不同的观点，接待和我一说念筹商。

一、典型案例

我先来举这样一个典型的例子，这内部包含了若干个值得商榷的方面，你可以望望是不是似曾相识：

在和候选东说念主研究完姿色和履历以后，口试还有 40 分钟，于是口试官问：你能否达成一个 LRU 队伍？于是候选东说念主想了一下，就启动作念题了，也即是在白板上大写特写，于是口试官也就启动忙我方的事儿了。比及 40 分钟后，候选东说念主写了一白板，但是显着，他在这经由中遭遇了一些欺压，临了天然达成了，但是代码写得有些复杂，也遗漏了两、三个热切的 corner case。于是口试之后，口试官在考语中写说念，“候选东说念主能力一般，算法题达成起来跌跌撞撞，临了的代码偏肥壮，而且有显着的 bug”。

在往下阅读以前，请你想一想，这样的口试方式有哪些值得商榷的地方？

二、时候口试的方针

好，我先卖个关子，先不回话上头的问题。而是先谈一谈，对于软件工程师候选东说念主来说，咱们为什么要进行这样的时候口试？

事实上，许多考试项完全不需要时候口试这样贫乏的阶梯，就可以很容易、高效地达成；而底下我说的这些方面，王人是对于软件工程师来说至关热切的方面，而时候口试是合理考试的独一可行阶梯。

1、时候能力方面

平淡不同轮次的口试会考试不同的时候点，因为这对于不同的团队和职位，王人是不一样的。

例如，对于某业务平台团队的一个高等工程师这个职位来说，五轮口试中：一轮考试姿色和教训；一轮考试系统想象；两轮考试照看具体问题的想路和递次，很是包括算法和数据结构；还有一轮考试面向对象想象等其它内容，这其中，后三轮王人包括白板编码的考试。

对于一个有教训的工程师候选东说念主来说，我认为这是一个比拟立体、概述，亦然一种比拟合理的时候考试点的鉴识形式。

这五轮中有四轮王人会耗尽无数的时候，同期通过我今天谈到的时候问题，来对候选东说念主进行时候能力方面的评估。这里，有这样几个非往往见的时候方面的考试项：

分析问题，整理需求的能力：一启动问题可能显得很迂缓，但是优秀的且有教训的工程师可以识别出中枢的诉求。这个 “识别” 的能力，下文我还会胪陈。这里的诉求可能有多个，但是辩论到时候的联系，口试经由中往往只会从某个角度阴事其中的一两个；凭证需求来想象系统的能力：这里既包括功能性需求，又包括非功能性需求，前者是必须要波及到的，但是后者也频繁放在一说念考量。其实这一丝可大可小，它无意指系统想象中功能是否得到达成，况且这个经由中，可能会波及到系统的推广性、可用性、一致性等等其它方面；将中枢逻辑达成的能力：如今，考试比重容易被高估的算法和数据结构就大体上属于这一部分。它也分为功能和非功能的两个角度——功能上算法能否达成需求，非功能上算法是否具备满盈的性能、编码是否罢职最好实行、代码是否具备邃密的可推广性等等。而编码能力，指的是在想路达成一致以后，中枢逻辑能不行落到纸面（代码）上。毕竟，“泛论误国，实战兴邦”；教训和其它工程能力：这部分相对更为机动。比如对测试能力的考试，即可以作念若何的测试来达成对于功能需乞降非功能需求正确性的保证。对于特定的团队和姿色来说，有时候会很是专注于特定的时候能力，比如前端的团队，需要考试前端的基础手段的。

辩论到时候、阴事面和阴事深度的量度，上头这四点有时候不行在一轮口试中完全阴事，但往往也会包含其中三点。比如，系统想象的口试可以细心阴事 1、2、4 点，而编码为主的口试可以细心阴事 1、3、4 点。

2、非时候能力方面

和时候能力考试不同的是，非时候能力考试在不同口试官中的特异性更大，换言之，每个东说念主的角度和尺度王人可能不一样。

但我以为底下这几条很是热切，因而是必须要阴事到的：

疏导合营的能力：如果不计时候本钱，最期望的口试是什么？其实即是一说念责任，责任中才会有满盈多必要的疏导，是以不管是正面的品性照旧负面的问题王人会无所遁形。然而口试的时候有限，咱们莫得主见达成委果的责任氛围，但依然可以模拟责任中一说念考试、分析和照看问题的经由，而这个经由，即是要通过 “疏导” 串起来的。疏导是一个大的话题，具体的考试项有许多，比如，能不行接管建议？能不行筹商想法？有些候选东说念主一朝参加我方的想考模式就听不进别的话了，于是一个点要反复强调几遍；而有的则是穷乏 backbone，略微追问一下，也不想考，就立马更动主意；平和和有趣：平和和有趣的影响是巨大的，王人说有趣是最好的淳厚，这部分是很难 “教出来” 的，对于低级工程师来说更是如斯。平和和有趣不但会影响到他们我方的畴昔发展，也会影响到总共这个词团队的氛围；学习能力：学习能力很大程度决定了候选东说念主在新的岗亭上高出的后劲。同样的基础和基本问题的照看能力，有的候选东说念主大要 “一丝就透”，通今博古，这就在一定程度上就反应了学习的能力。毫无疑问，软件工程师每天王人在濒临新问题，入职以后就会发现，不啻问题是新的，代码是新的，连类库和器具王人是新的。是以在熟习到大要有一定产出之前，这一步一定是学习。

时候能力和非时候能力，哪个更占主导？事实上，这二者王人很热切，况且二者各自又具备不同的特质。

天然相对来说，非时候能力愈加难以训诫，因而这方面的问题要愈加引起爱重。比喻说，要让一个对于软件领域繁重平和和有趣的候选东说念主，在入职以后旋乾转坤，是简直不可能的一件事情。

3、其它方面

上头说的是时候口试中对于 “能力” 的考试。其实，还有一些考试项，严格来说并不行算是 “能力”，因此我就莫得归类在上头，也不算是本文的要点，但这并不是说它们不热切。

比如，候选东说念主是否具备刚直的品格。在 OCI，debrief 的罢了，平淡有 hire 和 no hire 两种。但是有一种情况，可以归结到一个特殊的 “never hire” 内部去，这样的候选东说念主莫得口试冷冻期，不会有职位和级别的筹商，即是一个 “永不辩论” 遴聘——这即是品格问题。品格问题会导致 never hire 的出现，比如候选东说念主对面前的所在任位说谎了。

再比如，和团队的契合程度。不同的团队，经受候选东说念主的程度和条款王人是不一样的。一个典型的例子是，有时候咱们发现，有的候选东说念主在投票的鸿沟线上，即自己是具备相配的后劲的，但是由于繁重有关领域教训，且在某些方面炫夸出递次显着不得要领。如果团队中有熟习、有教训的工程师可以带着，团队也有一定的空间允许他花更长的时候学习和成长，那么临了的论断即是 hire，不然即是 no hire。你也可以看出，许多时候这样的决定王人不詈骂黑即白的，影响的身分是多方面的。

再再比如，性情不兼容导致的风险。我遭遇过一例，候选东说念主在口试经由中，在多轮口试中王人阐明出自尊和自尊的个性。这成为了一个记念招聘进来以后风险过高的热切方面，于是临了咱们毁灭了这个候选东说念主，尽管这个候选东说念主的时候方面是莫得问题的。那么有东说念主可能会说，贤慧东说念主王人是有个性的。但其实 “有个性” 和 “难相处” 有着秘要的辞别，再包容的团队也有我方的底线。咱们天然不但愿错过优秀的东说念主才，但是这并不代表不计代价。

从这几个方面也能看出，这些 “非能力” 的考试项，往往具备着或 0 或 1 的 “red flag” 的特质。

口试官一般不会花心想在这部分的考试上，但如果发现这方面的问题，且了解事后。那罢了往往就会是一个明确的否决票，而这个否决票是和级别、职位无关的。

三、回看阿谁案例

讲收场时候口试的方针，再来去看滥觞阿谁案例。阿谁案例中所记述的口试经由，对于时候口试的时候能力和非时候能力的考试，是否有阴事呢？咱们不妨一条一条看吧：

1、时候能力方面

分析问题，整理需求的能力：这一条考试的程度显着是不够的。给出的问题，是一个明确的、具体的算法题，也即是要达成一个 LRU 队伍。也许这其中存在着问题分析和需求整理的空间，但对于具体算法题来说，这个空间显着并不大。而且候选东说念主闷头就写了，这方面无从考试。

这个问题对于一个低级工程师的口试来说可能还好一些，我平淡莫得微词。可要用来口试一个教训丰富的工程师，我是很不赞赏纯算法题口试的，这即是其中的一个热切原因。

凭证需求来想象系统的能力：这一丝的阴事基本为 0。上来就写代码了，不明晰想考的经由，也更谈不上什么系统想象了。

将中枢逻辑达成的能力：这条如实是这种口试形式大要阴事的部分。因为总共这个词经由，即是候选东说念主想考并达成编码的经由，只不外口试官能得到的只须一个 “罢了”，而非总共这个词 “经由”。这样的数据，反应出来在中枢逻辑达成方面的价值，就要大打扣头了。

教训和其它工程能力：也许大要从代码的达成上获知一部分，但这一条考试的程度也显着是很不够的。

2、非时候能力方面

疏导合营的能力：这是最大的问题，因为这方面是远远不及的。总共这个词经由莫得疏导，莫得合营，只须缄默地作念题。

平和和有趣：这个经由很难从这个角度获取满盈的候选东说念主在平和和有趣方面展示出来的信息。

学习能力：同上。

小结

总的来说， “将中枢逻辑达成的能力” 可能还强迫过得去。这样的口试形式，并不行全面、合理地考试候选东说念主行为软件工程师的概述教学。

事实上，逸想试验责任。如果你的团队中有这样一个工程师，拿到一句浮浅的需求，不阐明问题，不疏导想象，不筹商决议，顺利就启动下马看花，就算能写出可以责任的代码来，这是不是依然是一件无比恐怖的事情？

显着，咱们的口试要尽可能幸免这样的事情在的确寰宇中发生。咱们要找的是软件工程师，不是只会刷题编码者。

这亦然我把这个案例放在起首，行为反面案例的原因之一。等等，“之一”？！难说念还有别的原因？

是的，这还没完，这个案例还有着其它短处，我想再卖个关子——而当今，你可以想一想，再往下看。

四、若何的问题才是 “好” 问题？

终于要正面回话标题中的问题了，到底若何的问题才能委果称得上 “好” 问题呢？

底下是我认为最热切的几条猜度尺度：

1、从迂缓到泄漏

滥觞，这个问题在一启动要满盈迂缓，以便让候选东说念主可以逐层递进，逐渐细化，寻踪觅迹。

这个经由，其实即是将 “具体问题” 经过分析、归纳、想考、抽象并将其映射成为一个 “软件问题” 的经由。

在问题变得泄漏的经由中，期望的情况是，候选东说念主可以阐明出主动性，即候选东说念主可以在多数情况下引颈筹商的想路，而不是口试官。口试官需要顺着候选东说念主的想路，逐渐框定下问题的筹商鸿沟，并明确到其中枢达成是如实可以用软件的主见达成的。

在这样的状态下，候选东说念主可以以天然的状态，具备相配目田度地阐明我方的能力。从这个经由中，可以不雅察得到候选东说念主不同角度的特质了。

通过这种形式，也可以很大程度幸免了依然知说念 “尺度谜底” 的口试官，由于想路的局限性，而给口试施加源自于主不雅偏好的影响。

这就好像是敞开寰宇的 RPG 游戏，有多个不同的旅途王人可以完成任务，玩家可以决策并决定主角的走向，但是这一切恒久还要在游戏想象者的掌控之内。这天然是说的期望状态，有时候会有偏差，但咱们朝着这个地点起劲。

是以这也对口试官阁下不同的情状有着很高的条款，毕竟口试官要对这个问题前前后后满盈的熟悉，以便派遣多样不同的细化场景。有一个常见的形式，是可以从一个我方依然满盈熟悉的问题启动，比如我方也曾多年责任波及的某类系统。

我来举一个具体例子。比如，有这样一个问题：

若何想象一个流量限制系统？

这即是一个迂缓到没法再迂缓的问题了。不知你会不会产生底下这样的问题：

什么系统需要流量限制？当今的流量是若干？需要复旧到什么时候精度？流量限制的规矩若何界说？超越流量的央求若何处理？……

其实，这些王人或多或少是需要口试官和候选东说念主一说念逐渐想考、分析和明确的。在这个经由中，可以考试到的内容太多太多了。

事实上，针对不同程度的候选东说念主，上述这个问题给出的最原始的迂缓程度是不一样的，问题越是迂缓，对于候选东说念主的条款也就越高。对于一个责任十多年的，有着多年系统想象教训的工程师来说，上头这些问题大约王人应该是他/她大要主动发问，或是主动引颈以致明确的。

值得一提的是，期望的问题里最好还有一些荫藏的 “坑”。候选东说念主能否把这些坑识别出来，亦然对于工程能力方面一个很好的考试点。

比喻说，优秀的候选东说念主应该猜测，流量限制可以基于实足时候窗口，或是相对时候窗口来进行，但是要委果保护系统，相对时候窗口才是最期望的。天然在达成难度上，相对时候窗口往往会更难一些。

而对于一个莫得责任教训，并将要连络生毕业的候选东说念主来说，问这样一个迂缓的问题，往往带来了过大的难度，不但辞让易推动口试的程度，还可能给候选东说念主带来寂然的热诚。咱们不但愿看到，候选东说念主拿到问题以后就懵了，如果发现候选东说念主推动有欺压，口试官需要介入并匡助。

因此凭证候选东说念主的程度，这需要口试官主动回话这些问题，或是顺利松开或明确问题的鸿沟，当这个问题的鸿沟缩到最小时，这可以是一个存在多种解法的算法题。

极点地说，这个问题可以一直松开到这样的程度：

假设说有这样一个 API，名字叫作念 isAllowed，这个 API 在系统每次收到央求的时候就调用，传入的是央求对象，传出 boolean 值示意是否允许此次调用——如果最近一分钟内调用次数小于 10000 次就允许，反之则不允许。你能否将这个 API 达成出来？

如果候选东说念主还一脸迷濛，可以提供这样的参考 API：

class RateLimiter { public boolean isAllowed(Request req) { // TODO }}

你看，这只是一个将问题明确、细化和领会的经由，并莫得波及到试验达成代码该用的算法。但是，上头提的那些问题，要么通过这个例子明确了，要么给出具体数字了。

这自己，就将一个迂缓的问题，裁减难度明确为一个具体的算法问题了。

2、不啻一个解

前边一步依然谈到了有不同的形式可将迂缓的 “试验问题” 映射成一个可解的 “软件问题”。而当今，这个 “软件问题” 依然莫得尺度谜底。

可能会有几个参考谜底，它们相互比拟起来各有优劣。但大多数情况下，候选东说念主的想路王人会在这几个参考谜底的想路之中，不外有时也能看到特立独行的新奇想路。

如同前一步所说的那样，对于不同级别的软件工程师职位来说，需求分析、系统想象这些方面的条款可能有着很大的辞别。但是在这一步，对于数据结构和算法这样的基础能力，却是接近的。

这里谈到的流量控的算法，达成形式有许多种，代码复杂程度，限制精度，时候复杂度和空间复杂度等等王人有着相配大的区别。天然此时波及到的，只是基本算法层面的话题。

我可以再举一个我曾频繁用在口试中的例子：

某酬酢网站有两百万的注册用户，每个用户王人有积分属性，且积分凭证用户在酬酢网站上的行径而不停有小幅度的频繁变更（比如登陆一次就+1 分，驳倒一次就+2 分等等），若何想象一种算法，大要高效、准确地实时获取指定用户在所灵验户中基于积分的排名？

上头的问题从迂逐渐缓落实到达成上的时候，异步、定时地排序，是最容易猜测的决议，而题目表述中的 “高效” 和 “实时” 这两个修藉词让这个问题变得欺压。这个经由中，我见到的可以的主见就至少有七、八种，比喻说，底下这个推动问题照看的例子：

候选东说念主：在需要的时候进行排序，决议是……

口试官：好，这样的形式下，时候、空间复杂度是若干？

候选东说念主：……（说着说着我方意志到时候消耗可能巨大）

口试官：对，你能否优化？

候选东说念主：……（提议了一些优化想路，但是他我方对它们的实时性也不悠然）

口试官：好，有换个角度更进一步优化的形式吗？

候选东说念主：对了，可以让数据一直是排好序的！

口试官：好主意，那你若何想象数据结构呢？

候选东说念主：我可以使用一个 map 来保存用户 id 到积分的映射，再把积分从小到大依次放在数组中，这样二分查找就可以找到对应积分所处的排名。

口试官：听起来可以，那么这时候获取排名的复杂度是若干？

候选东说念主：……

口试官：对，每当用户的积分小幅变化的时候，你若何督察这个数组依然有序？

候选东说念主：从数组中拿掉一个老的积分，再放入一个新的积分……

口试官：这个变更影响的数据量有若干，时候复杂度又是如何？

候选东说念主：……

口试官：可以，可这个递次有什么问题吗？

候选东说念主：（大彻大悟）如果新添加一个用户，新的积分会出当今数组头部，数组内的所少见据王人要向后迁移一个单元！

口试官：没错，那你筹划若何优化？

候选东说念主：可以把数组内的积分从大到小排序，这样新添加的用户所对应的积分总在尾部。

口试官：很好，这个递次还有什么问题吗？

候选东说念主：……（意志到在某些情况下，有许多用户领有一样的积分，这时时候复杂度会退化）

口试官：那样的话，你若何优化？

候选东说念主：数组的元素除了纪录面前积分，还纪录有若干个用户具有这个积分，从而放弃一样积分的相通元素……

口试官：很好，可这个递次会带来一个问题，你能猜测吗？

候选东说念主：对了，如果积分变化以后，新的积分是莫得出现过的，那么添加到数组里，即是一个新元素，于是总共比它小的积分全部王人要向后迁移一个单元。

口试官：相配好，那么你若何优化？

候选东说念主：如果使用链表来代替数组就可以幸免这个问题，（一忽儿意志到）然而链表我就没法二分查找了……

口试官：没错，那什么样的数据结构和链表在这方面具有一定相似性，又大要具备二分查找相似的时候复杂度？

候选东说念主：……（这一步能回话出来谜底就许多了，许多王人是很可以的想路，比如灵验跳表的，灵验二叉搜索树的等等）

这只是一个简化了的片断，试验的疏导的内容远比这部天职容多，但是从中也依然可以一隅之见，看出问题照看的经由是若何逐渐推动的。

如果你对这个问题自己感有趣的话，可以参阅一下 《名次榜算法想象达成比拟》和 《海量用户积分排名算法》这两篇著述，它们筹商了其中的几个想路；另外，我以前在这篇著述里也浮浅筹商了其中的一个想路。

从这里也可以看出，不管是从试验问题细化到软件问题，照旧求解这个软件问题，王人存在着多条通往罗马的说念路，看起来很好意思好，但这样的问题想象和口试把控并辞让易。

既然公共王人是软件工程师，是畴昔有可能一说念责任的工程师，口试官的能力和可能就和候选东说念主接近。于是，为了保证口试的恶果，就一定要全心准备这样的问题，而不行指望立时和临场想出来一个 “好” 的问题发问。

3、围绕问题的照看要齐全

这个问题的分析、筹商息争答经由要齐全。对，其实这一丝说的依然不是问题自己了，而是攻克这个问题的经由了。

这指的是总共这个词经由要起劲让候选东说念主大要抵达 “踮踮脚大要到” 的难度，况且大要完成从阐明、分析、筹商、编码、考据和校正等一个经由。这会让总共这个词口试显得齐全，同期带来了两大公正：

对于口试官来讲，这样一个齐全的经由，可以更全面地考试候选东说念主，幸免堕入视角过窄和一叶障方针情境。同期，“踮踮脚大要到” 的难度，又可以给总共这个词考试的程度具备较为合理的预期。对于候选东说念主来讲，心态可以得到一定程度的平复，不寂然，大要 “齐全地” 口试完一轮，大要成绩信心。别忘了，口试是双向的，给候选东说念主一个邃密的印象是很热切的。

前文我举的这个将问题从迂缓到逐渐泄漏化的这个例子，即是一个需要口试官凭证候选情面况动态养息的例子。在候选东说念主大要经过想考而快速推动问题照看进展的时候，要让出主动权，以被迫回话和饱读吹为主；但在候选东说念主卡壳的时候，要夺回主动权，实时给出领导和指导。

在落到数据结构和算法上头的时候，少量有候选东说念主大要在答复想路的时候顺利给出最优解的。这时候，如果时候充裕，很是是在候选东说念主进展相配告成的时候，可以不停领导、追问以条款 “代码前优化”，一步一步优化到他/她的问题照看的能力鸿沟，这即是其中的一个探寻其 “踮踮脚大要到” 的这个问题照看能力之鸿沟的一个主见。

但这个经由的前提是，一定要给编码留足时候。天然，如果候选东说念主不行在截至时候内给出泄漏的优化后想路，那不妨就退一步到原先阿谁算法角度不那么 “好”，但是想路泄漏的解法上，并落实到代码上。

比喻说，对于前文所述的阿谁流量限制的问题，候选东说念主在还有半个小时的时候就猜测了使用一个时候复杂度为 O(N) 的解，而口试官认为时候还比拟充裕，那就可以尝试挑战一下候选东说念主 “能否再优化一下复杂度”。

有些时候，由于前边的经由跌跌撞撞，时候剩下未几了，依然只须时候复杂度较高的 brute force 的解法，那么将这个解法达成了，其实亦然一个可以的采选。

有时候时候实在比拟病笃，可以要务达成一部分中枢代码，这些王人比由于时候太短而代码写了一半急促收尾要好得多。

我的教训是，在筹商充分、想路泄漏的情况下，代码完成的时候，一般只需要 5 到 15 分钟，这样的代码量对于口试来说是比拟合理的。

天然，相较而言，一种更为倒霉的罢了是，一直到临了，筹商的深度依然离编码尚远，致使依然停留在一个很高的泛泛而谈的层面。

如果在编码完成之后，尚有时候，优秀的候选东说念主会拿试验的例子去考据代码的正确性。而口试官也可以和候选东说念主筹商 “代码后优化”，比如以下的问题：

你能否进一步优化算法以训诫时候/空间复杂度？如果是工业级别的代码，你以为代码还有哪些问题？你该若何去想象测试，来保证这段代码的正确性 ？

4、对考试项的阴事兼有深度和广度

这个问题要大要考试前文所述的时候能力和非时候能力。

这里说的阴事，不一定要全部阴事，而是要阴事其中的大部分，况且对于每一个考试项要具备一定的考试深度。

我见到过不少其它的口试作风，但我认为这样就一个迂缓的主要问题（话题）逐渐伸开的形式是最好的。因为它可以兼具广度和深度的均衡。

具体来说：

口试很容易走向的一个极点即是辩论广度，但繁重深度。比如一种作风是，绝大部分的口试时候用来参议候选东说念主的姿色和教训，让候选东说念主我方先容，而口试官跟进追问。这蓝本是一种很好的形式，但是由于候选东说念主对我方的姿色平淡远比口试官熟悉得多，除非明确的吞并领域，不然口试官较难对于其中的内容挖掘到满盈的深度，从而识别出候选东说念主是委果作念事的东说念主，照旧名过其实的东说念主。这亦然这种形式表面可行，但试验开展难度较大的原因之一；另一个极点，天然即是辩论深度，但繁重广度。比如给出一个过于具体的问题，繁重阐明和间接的空间，对这个问题所波及的很小一部分深度挖掘，致使纠缠于某个特殊而单一的 case 很万古候，但是却只可阴事很少的考试角度。

由于深度和广度王人是可控的，那么这样的可以拿来问不同教训和不同时候配景的工程师候选东说念主。这样对于口试官来说，可以赢得满盈的数据，便于在遭遇新的候选东说念主的时候，大要进行横向比拟，作念出更准确的评估。

比喻说，畴前某级别的候选东说念主大要在濒临这个问题的时候，大要达到什么样的级别，而如今这个候选东说念主有着近似阐明，这就可以以畴前的阿谁例子来行为参考比拟了。

五、再次回看阿谁案例

当今，让咱们再次回到著述起首阿谁例子问题，除了依然提到的考试项的阴事不够，它还有哪些问题呢？

参考上文依然提到了 “好” 问题的尺度，我以为其中的这样两条是抵触的：

从迂缓到泄漏：显着，问题给出的时候就依然相对比拟泄漏了，这样的形式并不行模拟软件工程师日常濒临的许多迂缓而欺压的试验问题。我依然提到，对于教训丰富的候选东说念主来说，这样的问题无法重现将试验问题映射到软件问题的热切想考经由。

围绕问题的照看要齐全：示例问题的考试经由中，只须繁重互动的编码智力，莫得其它经由，莫得编码前的分析、想考和优化，也莫得编码后的测试、校正和优化。辩论到 LRU 齐全算法是一个达成代码量偏大的问题，拿来放到口试中作念一个齐全达成，由于会消耗过多的时候，挤压其它时候，因此显得有些过了。

六、其它 “不好” 的问题

前边说了过于泄漏的纯算法题的 “不好” 之处，也说了 “好” 问题的例子，临了我想再来说几类其它的且典型的 “不好” 的例子。

1、被使用过太多遍的问题

许多公司（如 Google 和 Facebook）王人有参考题库，而题库不停更新其中一个热切原因即是，要尽量幸免候选东说念主作念过被问到的题目。

而且，问题越明确和具体，一朝候选东说念主作念过，考试的恶果就越不客不雅。比喻说，底下这个问题本来是个很可以的问题，但由于是被过于庸碌地使用了，因此我照旧不建议拿它来用作口试题的：

若何想象一个短网址系统？

2、依赖于特定话语或框架

而这里说的依赖不好，是因为辩论到候选东说念主不同的时候配景，如果莫得特殊的需要，幸免这样的依赖，以幸免产生不应有的无理的猜度数据。

比喻说，问一个对于 JVM 的问题，这个问题可以问，很是是在候选东说念主强调其具备一定 Java 配景的前提下。但是这样的问题不行成为 “主菜”，尤其是候选东说念主不一定具备很强的 Java 配景，这样的形式会导致考试的偏颇。

3、过于复杂的规矩或配景学问

这主如若基于口试的有限时候辩论的，过于复杂的规矩或配景学问，容易把时候消耗到袒露它们上头。另外，有些配景学问并非是总共东说念主王人熟知的，这就会引起考试尺度的非预期。我给一个经典的反面例子：

想象一个算法，把一个小于一百万的正整数，使用罗马数字来示意。

这个问题描述圣洁，但是拿来作念时候口试中的主要问题的话，其中一个失当之处即是，不是总共东说念主王人很明晰一百万内的罗马数字示意法的。对于不明晰的东说念主来说，要搞明晰这个示意法的规矩，就依然是一件有些复杂和耗时的事情了。显着，这个罗马数字示意法的学问点，不应该成为考试和猜度的尺度。

天然，有时候有些问题的配景学问是冷门的，但是表述圣洁，那么这样的话只须口试官大要主动、赶快地阐述晰，拿来使用是没问题的。

4、学问性问题

我想很是谭一谈，对于学问性问题的发问。在筹商问题的经由中，如果波及到关联的具体学问，那么发问一些基础学问是一个可以的采选，这是考试候选东说念主 CS 基础是否牢靠的形式。

比如候选东说念主提到使用 HashMap，而他/她最熟悉的编程话语是 C++，那么参议在 C++中 HashMap 是若何达成的即是一个可行的问题。而且，由于这样的问题是嵌套在前述这个大流量限制问题的照看经由中的，更显得天然而不突兀。

反之，如果这样的学问性问题较为冷门或浅表，和面前的筹商中的问题无关，或是不在候选东说念主的学问体系内，这样的问题就值得商榷了。比如，只是因为我方的姿色组使用 Spring，口试官就参议候选东说念主 Spring 的 bean 的单例和多例分别是若何建立的，而刚巧候选东说念主又是 C++配景，对于这部分并不熟悉，这样的问题除了给候选东说念主酿成困扰之外，真义就不太大了。

如果把学问性问题行为主要问题来发问，我认为是不相宜的。因为一方面它不具备普适性，另一方面它又具备太强的立时性。

这里不具备普适性这一条，指的是不同时候配景的软件工程师候选东说念主王人要大要相宜参与这个问题的解答。例如来说，如果问 “Tomcat 的线程池的建立战略？”，这即是一个不具备普适性的问题，这是一个偏重 “学问性” 的问题，如果候选东说念主莫得使用过 Tomcat，或是只是略有了解，很可能就栽了。

而具备太强的立时性这一条，指的是一朝待考试的问题具体以后，这个问题就容易从对 “能力” 的考试变成了对 “学问” 的考试，而这个学问，又恰正是比拟容易立时的。也即是说，咱们不但愿候选东说念主 “刚巧” 知说念或不知说念某一个狭窄的学问点，来决定他/她是否通过这项考试。

不管如何，学问性的问题行为考试的援手形式可以，但不应成为主角。我照旧以为咱们应当能把更多的时候，留给主要问题的照看经由自己。

对于 “时候口试中，什么样的问题才是好问题？”，我就说这样多吧。也接待你共享你的观点，咱们一说念筹商。

作家丨四火来源丨raychase.net/5934dbaplus社群接待弘大时候东说念主员投稿赌钱赚钱app，投稿邮箱：editor@dbaplus.cn