我在技术面试中看到的常见问题

你好，我是Aline(interviewing.io的创始人)。这是我们的客座作者系列的第二篇帖子。第一篇帖子谈到了你在面试公司时可能会遇到的危险信号。作为补充，这篇文章由我们一位多产的长期面试官撰写，探讨了受访者经常犯的错误。

我对客座作家系列最兴奋的事情之一是它给我们的博客带来了多样化的观点。技术面试和招聘充满了争议，这些帖子并不是所有内容都会符合我的观点或官方对面试的看法。但这就是它的伟大之处。在这个行业工作了十多年，我仍然不认为有一种正确的方式来进行面试，我认为招聘总是会有一点混乱，因为这从根本上说是一个人性化的过程。即使我们不总是达成一致，我也承诺我们提出的内容将是精心策划的、高质量的，并由对这一领域充满热情的聪明人撰写。

如果你对面试或招聘有强烈的意见，并且一直渴望写出来，我们很乐意听取你的意见。请给我发电子邮件至[email protected]以开始。

威廉·伊恩·道格拉斯(William Ian Douglas)绰号“伊恩”(Ian)，用的是他/他的代名词。他住在科罗拉多州丹佛市，1996年毕业于计算机工程专业。他的职业生涯涉及后端系统、API架构、DevOps/DBA职责和安全，并一直担任管理小团队的团队负责人和工程总监。伊恩在2014年扩展到专业技术面试教练领域，并在2017年将他的整个职业生涯转移到丹佛地区的图灵软件与设计学院(Turing School of Software&；Design)教授软件开发。他于2017年夏天作为合同面试官加入Interviewing.io，是IIO制作的数据分析博客帖子的铁杆粉丝，这些博客帖子旨在帮助揭露和消除我们科技行业面试中的偏见。伊恩在https://techinterview.guide撰写技术指导信息，你可以在推特、领英和gihub上联系到他。

最近，我在Interviewing.io(IIO)网站上进行了第600次面试。我想分享学到的经验教训，为什么我会这样对待面试，并就我在技术面试中看到的常见问题领域做出一些解释。平台上的每个面试官都是不同的，所以你的结果可能会有所不同。我们有一些优秀的人在这个平台上帮助我们，我们有一个很棒的社区在努力让我们自己变得更好。

采访。io Mock采访在我们对IIO的采访中，我们用三个4分制给人们打分。1分意味着他们做得非常差，4分意味着他们在这一类别中做得非常好。我通常会在面试开始时，每个人马上得到3分(满分4分)，然后随着面试的进行，我会获得或失去分数。

平台上的每一位面试官都会有一些他们比其他人更喜欢的方面。作为一名面试官，我自己的偏见倾向于沟通和解决问题，下面我会指出这一点。

技术熟练程度在这一类别中，我根据候选人对他们选择的语言的熟练程度、他们在编写特定风格的算法时是否有重大问题、如果我在编码过程中需要给出很多提示来对他们进行评分。

解决问题在这里，我给候选人打分，看他们把问题分解成小块的程度，想出解决小问题的策略，并在此过程中调试问题。调试时思考问题的能力与编写代码一样重要。当问题发生时，他们是被难住了，还是能够自己找到根本原因？

沟通面试官真的很想听听你的决策过程。这在调试代码时也非常重要。我倾向于雇佣那些能很好地适应较小团队或开发人员集群的人。考虑到这一点，协作和轻松的沟通是赢得我的一个好方法。

我在这里的采访中看到的常见问题领域是我在采访中看到的最主要的问题领域，不仅是在IIO上，而且总体上也是如此。我希望这个建议对你有帮助。

常见问题1：过早进入代码我在所有类型和级别的开发人员中都看到了这一点，但主要是拥有2-5年经验的“中等”级别的开发人员。他们听到一个问题，用30秒或更少的时间谈论高级设计，并且急于开始编码。他们觉得自己像是在计时器上。他们想赶着把事情做完。这是一场冲向终点线的比赛。第一个越过终点线的人是胜利者。

花时间想出一个中层设计的人，无论是伪代码还是只是写下他们的方法的注释，倾向于在以后花更少的时间调试他们的代码。那些直接开始编码的人会陷入我所说的“随用随用设计”问题，您需要花费大量时间重构您的代码，因为您需要更改传递的参数或返回值，或者等待，循环在错误的位置，等等。作为面试官，这一点很容易辨认出来。

在中层设计上花费一些时间并不能保证你的成功，但从长远来看，通过更深入地思考你的计划可能会节省你的时间，而且你买来的额外时间可以在以后用来解决问题。

另外，作为一名面试官，我希望看到你成功。特别是如果你在“现场”(现在是面对面或远程)，因为你在现场面试过程中花费了我们公司更多的钱。虽然我需要公平对待所有候选人，但如果我可以提前看到您的设计，并发现该设计中的缺陷，我就可以提出引导性问题来引导您找到问题并更早地纠正您的方法。

如果您直接跳到代码中，我甚至不知道您的实现是否可以工作，而这不是安排您的面试官的好地方。在我真正理解您的代码中发生了什么之前，如果您已经编写了100行Java代码，那么我要纠正一个设计就会困难得多。

在2012年的一次真正的采访中，我看到了这种缺乏规划的适得其反的可怕效果。应聘者被人力资源部的人带到我的面试间，问他们是否想要一瓶水，并答应回来。我们做了自我介绍，开始着手进行技术挑战。候选人没有分享细节，没有设计，几乎没有谈到高级方法，什么也没有写下来，然后开始在白板上编写代码。(这将是我进行的倒数第二次白板采访，我讨厌白板采访！)。几分钟后，HR出现了，大声敲门，递给他一瓶水，然后离开了。应聘者感激地喝了一杯，打开瓶盖，开始啜饮一口，这时他们脸上露出了令人不快的疲惫表情。送一瓶水分散了他们的注意力，让他们完全失去了思路，我无法帮助他们恢复，因为他们没有和我分享任何关于他们的做法的细节。他们花了几分钟重新思考这个问题，然后重新开始。

然而，在这枚硬币的“另一面”，你可能会在设计阶段花费“太长时间”，没有时间来实施你的天才计划。我见过候选人通过中层设计，然后写笔记，然后用这些笔记手动演练一个示例，以真正确保他们的计划是好的，而现在他们只剩下几分钟的时间来实际实施工作了。也许是通信方面的加分，但我们也需要看到一些有效的代码。

我通常推荐练习，直到您花大约5分钟思考高级设计选择，5分钟计划和证明中级设计，然后开始编写代码。这里的好消息是“熟能生巧”--你越是练习这种设计分解和解决问题的方法，你就会得到越好的效果。稍后会详细介绍这一点。

常见问题区域2：交流“半信半疑”这是我多年来创造的一个术语，在这个术语中，您开始大声地说出一个想法，完成脑海中的想法，然后更改代码的某些内容。通常听起来是这样的：

“嗯，我想知道我能不能…。…。…。不，不要紧，我就这样做吧。“。

面试官想知道你的思维过程是怎么回事。重要的是要知道你是如何做决定的。您如何使想法合格或取消资格？你为什么选择用一种特殊的方式来实现某件事呢？您是否在代码中发现了潜在问题？那是什么东西？

这些缺失的信息对你的面试官来说是一个隐藏的宝藏。只需几秒钟就可以将您的通信更改为以下内容：

“我想知道如果…。嗯，…。嗯，我想把它作为深度优先搜索来实现，但考虑到_的限制，我认为更好的方法可能是_，你觉得呢？“

这可能多花了2到3秒钟，你已经征求了我的意见或同意，我们可以一起考虑可能性，现在我们正在合作这一过程。你已经觉得自己是我未来的同事了！

常见问题区域3：不问澄清问题您有一组整数。编写一个方法，找出两个加起来等于给定目标值的数字，立即停止，并报告这些数字。如果未找到任何内容，则返回两个“null”值。

这是一个很棒的问题，它向我展示了你是如何看待算法的，以及当你听到一个问题时，你会做出什么样的假设。

我编写代码已经有相当长的一段时间了。实际上是从1982年开始的。在我使用过的任何语言中都没有称为“分组”的数据结构。那么你对这个问题有什么假设呢？

大多数候选人立即认为数字的“分组”是在一个数组中。您可以通过使用数组存储数字来成功解决此问题。您的算法可能是O(n^2)(n平方)算法，因为您将以指数方式迭代数据：对于每个值，迭代其余的值。有一种更有效的方法可以在O(N)时间内解决这个问题，方法是选择不同的数据结构。

去问你的面试官有关这个问题的问题吧。如果他们告诉你做出你自己的假设，那就不同了，但是要问问他们是否是好的假设。询问是否有您将用作测试用例的备用数据集，这可能会影响您的算法。

常见问题之四：假设面试官制定了所有规则是的，你在那里面试，但你在那里向他们展示你将如何在团队中工作，当有清晰、开放的沟通和协作意识时，团队工作得最好。在面试的前几分钟设定期望，特别是围绕沟通和工作流程。

与面试官进行这种聊天并没有什么错：“在这样的技术挑战中，我的典型工作流程是花一两分钟静静地思考问题，并写下笔记，我稍后会与你分享这些想法，以获得你的意见。”然后，在我编写代码的同时，我也倾向于安静地工作，但我肯定会不时地暂停一下，在我进行的过程中分享我的思考过程，然后在我们第一次运行它之前更彻底地向您介绍代码。您觉得这样可以吗？或者您对我如何沟通或解决问题有不同的期望？“

我保证你会让他们大吃一惊的。大多数面试官不会准备好让你这样考虑他们的期望。这表明你能很好地在团队中工作。你在为自己创造环境，同时也在为他人着想。你预先说明了你的意图，并让他们有机会在这个过程中进行合作。

常见问题之五：没有像你的面试官那样更快地寻求帮助，我有可能在遇到技术挑战时提供少量的帮助。显然，我不能指导你完成所有的事情，但我宁愿给你一个提示，在一个题目上扣分，看着你最终在这个问题上取得成功，而不是默默地挣扎，绕着圈子转，让我们都觉得面试是在浪费时间。

作为一名软件学院的专业面试者和讲师，我已经变得非常善于问引导性问题来引导你实现或回答问题，而不需要我给你解决方案。

当你陷入困境时，承认是可以的。这不会让你失败，它会让你变得有人性。让你的面试官知道你在想什么，告诉他你哪里有问题。仔细倾听他们的反应，他们可能会提供问题的线索，或者可能会给你提供更全面的如何进行的建议。

分享我最喜欢的资源当我们在IIO的面试结束后，我喜欢深入研究他们的过程中的许多反馈，以及我认为他们可以在哪些方面利用额外的练习来改进。一般说来，我会花10到20分钟回答别人的问题，有时会远远超出我一个小时的预期时间，并对事情进行更详细的讨论。我喜欢帮助IIO上的人。

没有什么比听你自己录制的声音更糟糕的了。但所有的IIO采访都是录音的，我经常在我的反馈和事后的回顾笔记中告诉人们，我会在事后打字收听采访录音的最后几分钟，以审查我给他们的反馈。您还可以随时暂停这些录制并获取代码副本。(这些录音当然是你和你的面试官的隐私。)。

在回放过程中，倾听你自己的思维过程以及你是如何交流你的想法的。当你解决其他挑战时，如果可能的话，找到一种方法来记录自己大声谈论问题，并为自己回放。你会变得更善于表达完整的想法。

问题解决和中级设计更常见的实践网站，如HackerRank、CodeWars、LeetCode等，非常适合编写编码算法，但不给您任何练习设计过程的方法。

我把我的学生送到欧拉计划。Euler是一位数学家，所以网站上的问题通常都是非常重的数学题，但你可以把问题改成你喜欢的任何形式。如果你不知道如何计算一个质数，没关系，把它换成一个数字是否能被17整除或其他东西。

我喜欢欧拉计划，因为那里的挑战只有文字问题。您必须考虑所有问题：算法、要使用的数据结构，特别是如何将问题分解为更小的部分。

我最喜欢的问题之一是他们档案中的第19个问题：计算1901年1月到1999年12月之间有多少个月是从一个星期天开始的。他们给你每个历月的天数，告诉你1900年1月1日是星期一，以及如何计算闰年。剩下的就看你的了。

你把自己暴露在不同类型的问题中越多，你就越能更好地发现模式。

练习，练习，练习我们给学生的一条建议是，每个技术挑战都要练习几次。我们的执行董事杰夫·卡西米尔(Jeff Casimir)告诉学生们要练习10次。这感觉像是一项很大的努力。我更多地瞄准了3到4次，我的理由是：

当你第一次解决问题时，你所做的一切就是解决了问题。你可能在某些部分挣扎过，但你在这里唯一的真正成就是完成。

如果您删除您的工作并重新开始，您可能会想出一个不同的方法来解决问题，也许是一个更有效的解决方案。也许不是，但至少你正在练习解决这类问题。

现在擦掉你的作业，再做第三次。然后是第四次。这些时候，你会开始积极地记忆解决这个特殊问题所采取的策略。当您看到其他技术挑战时，这种“肌肉记忆”将帮助您发现相似之处。“哦，这看起来像是背包问题”，因为您已经多次解决了这个问题，所以进行高级设计和中级设计的时间缩短了很多。

我最喜欢的技术挑战之一可以使用几种不同的算法(DFS、BFS、DP等)来解决。如果你认为你可以用类似的方式解决一个问题，那么用这些算法中的每一个也可以解决3到4次。您将非常善于发现相似之处，并拥有大量处理其他技术问题的策略。

无耻的自我推销我一直在为https://techinterview.guide.有抱负的新开发人员写笔记。它还不完整，但我对准备技术面试、网络和外展、简历和求职信等有很多自己的想法。关于谈判策略和优雅的辞职，我还有几个章节要写，但我很乐意听取其他人对内容的反馈。

我每天也有一系列的电子邮件，涵盖了几种面试问题，但不是从如何完美回答这些问题的角度来看，有很多资源可以做到这一点。相反，我会从面试官的角度审视问题--我真正想问的是什么，我希望你告诉我什么，我希望你不会说什么，等等。例如，一个小小的预览：当你被问到“告诉我关于你自己的情况”时，他们并不是真的在问你的生活故事。他们实际上是在问“告诉我关于你的一些事情的摘要，这些事情会让你在这里成为一个有价值的员工”。

感谢您对受访者的期望和常见陷阱的洞察！对于我目前的情况来说，这是一个非常及时的时刻(在预筛选和预OnSites之间)。

我会把自己归类为你所说的“中等水平”。我是一个“思考者”(也许，倾向于“过度思考者”)，所以我努力保持我开始的高层讨论的简明扼要，甚至更进一步，理解什么时候足够清楚地展示我的中层设计。我倾向于立即知道一种直接/暴力解决方案，但随后就会有几个更优化的版本的想法。

在分享太多想法之前，你对如何自我编辑有什么建议吗？在透明度和听起来令人困惑的…之间有一条细微的界限。一旦你决定描述所选解决方案的中层设计，这样你就不会浪费时间(我已经做了太多次了！)，而是从面试官的角度来思考什么是“足够”的。换句话说，您需要在中层设计中看到什么/应该如何显示才能传达解决方案的框架并确认其清晰度？

我真的很喜欢你对面试官坦率地告诉面试官你喜欢怎样工作的建议。(我很冗长-很明显-但一开始更喜欢沉默地思考)。这是不是应该从头到尾都要做的事情(比如询问开始编码的许可，询问这个解决方案是否清晰)？或者是否需要在直截了当、听起来合乎情理等之间取得平衡？

这是一篇多么精彩的细致入微和富有洞察力的文章。通读伊恩分享的不同问题领域和资源，很明显，他非常关心那些他采访和指导的人。特别是，问题区域2和4是纯金的。作为被采访者，很容易迷失在我们的思想中，只说出我们所想的一半。此外，将面试官视为审讯者而不是合作者，这会让你很难唤起一种同志情谊，让团队合作成为一种有益的经历。

我从技术产品支持过渡到编写代码的旅程已经进行了大约16个月。正是这类材料有助于阐明成功编写软件所需的沟通技能的广度。我非常感谢这篇帖子，并期待着来自Interviewing.io贡献者的更多内容。