从编程面试中学到的这些东西值得一看

在 2017 年，我参加了 ‘计算机行业中的女性’ 的Grace Hopper 庆祝活动。这个活动是这类科技活动中最大的一个。共有 17,000 名女性IT工作者参加。

这个会议有个大型的配套招聘会，会上有招聘公司来面试会议参加者。有些人甚至现场拿到 offer。我在现场晃荡了一下，注意到一些应聘者看上去非常紧张忧虑。我还隐隐听到应聘者之间的谈话，其中一些人谈到在面试中做的并不好。

我走近我听到谈话的那群人并和她们聊了起来并给了一些面试上的小建议。我想我的建议还是比较偏基本的，如“（在面试时）一开始给出个能工作的解决方案也还说的过去”之类的，但是当她们听到我的一些其他的建议时还是颇为吃惊。

为了能更多的帮到像她们一样的小白面试者，我收集了一些过去对我有用的小点子，这些小点子我已经发表在了 prodcast episode 上。它们也是这篇文章的主题。

为了实习生职位和全职工作，我做过很多次的面试。当我还在大学主修计算机科学时，学校每个秋季学期都有招聘会，第一轮招聘会在校园里举行。(我在第一和最后一轮都搞砸过。)不过，每次面试后，我都会反思哪些方面我能做的更好，我还会和朋友们做模拟面试，这样我就能从他们那儿得到更多的面试反馈。

不管我们怎么样找工作: 工作中介、网络，或者学校招聘，他们的招聘流程中都会涉及到技术面试：

近年来，我注意到了一些新的不同的面试形式出现了：

• 与招聘方的一位工程师结对编程
• 网络在线测试及在线编码
• 白板编程（LCTT 译注： 这种形式应该不新了）

我将重点谈谈白板面试，这种形式我经历的最多。我有过很多次面试，有些挺不错的，有些被我搞砸了。

我做错的地方

首先，我想回顾一下我做的不好的地方。知错能改，善莫大焉。

当面试者提出一个要我解决的问题时， 我立即马上立刻开始在白板上写代码，什么都不问。

这里我犯了两个错误：

没有澄清对解决问题有关键作用的信息

比如，我们是否只用处理数字或者字符串？我们要支持多种数据类型吗？如果你在开始解题前不去问这些问题的话，你的面试官会有一种不好的印象：这个人在我们公司的话，他不会在开始项目工作之前不问清楚到底要做什么。而这恰恰是在工作场合很重要的一个工作习惯。公司可不像学校，你在开始工作前可不会得到写有所有详细步骤的作业说明。你得靠自己找到这些步骤并自己定义他们。

只会默默思考，不去记录想法或和面试官沟通

在面试中，很多时候我也会傻傻站在那思考，什么都不写。我和一个朋友模拟面试的时候，他告诉我因为他曾经和我一起工作过所以他知道我在思考，但是如果他是个陌生的面试官的话，他会觉得我正站在那冥思苦想，毫无头绪。不要急匆匆的直奔解题而去是很重要的。花点时间多想想各种解题的可能性。有时候面试官会乐意和你一起探索解题的步骤。不管怎样，这就是在一家公司开工作会议的的普遍方式，大家各抒己见，一起讨论如何解决问题。

想到一个解题方法

在你开始写代码之前，如果你能总结一下要使用到的算法就太棒了。不要上来就写代码并认为你的代码肯定能解决问题。

这是对我管用的步骤：

1. 头脑风暴
2. 写代码
3. 处理错误路径
4. 测试

1、 头脑风暴

对我来说，我会首先通过一些例子来视觉化我要解决的问题。比如说如果这个问题和数据结构中的树有关，我就会从树底层的空节点开始思考，如何处理一个节点的情况呢？两个节点呢？三个节点呢？这能帮助你从具体例子里抽象出你的解决方案。

在白板上先写下你的算法要做的事情列表。这样做，你往往能在开始写代码前就发现 bug 和缺陷（不过你可得掌握好时间）。我犯过的一个错误是我花了过多的时间在澄清问题和头脑风暴上，最后几乎没有留下时间给我写代码。你的面试官可能没有机会看你在白板上写下代码，这可太糟了。你可以带块手表，或者房间有钟的话，你也可以抬头看看时间。有些时候面试者会提醒你你已经得到了所有的信息（这时你就不要再问别的了），“我想我们已经把所有需要的信息都澄清了，让我们写代码实现吧”。

2、 开始写代码，一气呵成

如果你还没有得到问题的完美解决方法，从最原始的解法开始总是可以的。当你在向面试官解释最显而易见的解法时，你要想想怎么去完善它，并指明这种做法是最原始的，未加优化的。（请熟悉算法中的 O() 的概念，这对面试非常有用。）在向面试者提交前请仔细检查你的解决方案两三遍。面试者有时会给你些提示， “还有更好的方法吗？”，这句话的意思是面试官提示你有更优化的解决方案。

3、 错误处理

当你在编码时，对你想做错误处理的代码行做个注释。当面试者说，“很好，这里你想到了错误处理。你想怎么处理呢？抛出异常还是返回错误码？”，这将给你个机会去引出关于代码质量的一番讨论。当然，这种地方提出几个就够了。有时，面试者为了节省编码的时间，会告诉你可以假设外界输入的参数都已经通过了校验。不管怎样，你都要展现你对错误处理和编码质量的重要性的认识。

4、 测试

编码完成后，用你在前面头脑风暴中写的用例来在你脑子里“跑”一下你的代码，确定万无一失。例如你可以说，“让我用前面写下的树的例子来跑一下我的代码，如果是一个节点是什么结果，如果是两个节点是什么结果……”

在你结束之后，面试者有时会问你你将会怎么测试你的代码，你会涉及什么样的测试用例。我建议你用下面不同的分类来组织你的错误用例：

一些分类可以为：

1. 性能
2. 错误用例
3. 期望的正常用例

对于性能测试，要考虑极端数量下的情况。例如，如果问题是关于列表的，你可以说你将会使用一个非常大的列表以及的非常小的列表来测试。如果和数字有关，你将会测试系统中的最大整数和最小整数。我建议读一些有关软件测试的书来得到更多的知识。在这个领域我最喜欢的书是 《我们在微软如何测试软件》。

对于错误用例，想一下什么是期望的错误情况并一一写下。

对于正向期望用例，想想用户需求是什么？你的解决方案要解决什么问题？这些都可以成为正向期望用例。

“你还有什么要问我的吗？”

面试最后总是会留几分钟给你问问题。我建议你在面试前写下你想问的问题。千万别说，“我没什么问题了”，就算你觉得面试砸了或者你对这间公司不怎么感兴趣，你总有些东西可以问问。你甚至可以问面试者他最喜欢自己的工作什么，最讨厌自己的工作什么。或者你可以问问面试官的工作具体是什么，在用什么技术和实践。不要因为觉得自己在面试中做的不好而心灰意冷，不想问什么问题。

申请一份工作

关于找工作和申请工作，有人曾经告诉我，你应该去找你真正有激情工作的地方。去找一家你喜欢的公司，或者你喜欢使用的产品，看看你能不能去那儿工作。

我个人并不推荐你用上述的方法去找工作。你会排除很多很好的公司，特别是你是在找实习工作或者入门级的职位时。

你也可以集中在其他的一些目标上。如：我想从这个工作里得到哪方面的更多经验？这个工作是关于云计算？Web 开发？或是人工智能？当在招聘会上与招聘公司沟通时，看看他们的工作单位有没有在这些领域的。你可能会在一家并非在你的想去公司列表上的公司（或非盈利机构）里找到你想找的职位。

换组

在这家公司里的第一个组里呆了一年半以后，我觉得是时候去探索一下不同的东西了。我找到了一个我喜欢的组并进行了 4 轮面试。结果我搞砸了。

我什么都没有准备，甚至都没在白板上练练手。我当时的逻辑是，如果我都已经在一家公司干了快 2 年了，我还需要练什么？我完全错了，我在接下去的白板面试中跌跌撞撞。我的板书写得太小，而且因为没有从最左上角开始写代码，我的代码大大超出了一个白板的空间，这些都导致了白板面试失败。

我在面试前也没有刷过数据结构和算法题。如果我做了的话，我将会在面试中更有信心。就算你已经在一家公司担任了软件工程师，在你去另外一个组面试前，我强烈建议你在一块白板上演练一下如何写代码。

对于换项目组这件事，如果你是在公司内部换组的话，事先能同那个组的人非正式聊聊会很有帮助。对于这一点，我发现几乎每个人都很乐于和你一起吃个午饭。人一般都会在中午有空，约不到人或者别人正好有会议冲突的风险会很低。这是一种非正式的途径来了解你想去的组正在干什么，以及这个组成员个性是怎么样的。相信我，你能从一次午餐中得到很多信息，这可会对你的正式面试帮助不小。

非常重要的一点是，你在面试一个特定的组时，就算你在面试中做的很好，因为文化不契合的原因，你也很可能拿不到 offer。这也是为什么我一开始就想去见见组里不同的人的原因（有时这也不太可能），我希望你不要被一次拒绝所击倒，请保持开放的心态，选择新的机会，并多多练习。

以上内容选自 《The Women in Tech Show: Technical Interviews with Prominent Women in Tech》的 “编程面试”章节，

作者简介：

微软研究院 Software Engineer II， www.thewomenintechshow.com 站长，所有观点都只代表本人意见。

via: https://medium.freecodecamp.org/what-i-learned-from-programming-interviews-29ba49c9b851

作者：Edaena Salinas 译者：DavidChenLiang 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

原文来自：https://linux.cn/article-10032-1.html

本文地址：https://www.linuxprobe.com/study-from-interview.html编辑：清蒸github，审核员：逄增宝