头条白板面试_让我们谈谈白板面试和可能的替代方法

头条白板面试

by Sun-Li Beatteay

通过孙丽·贝蒂

让我们谈谈白板面试和可能的替代方法 (Let’s talk about whiteboarding interviews and the possible alternatives)

It’s not news to anyone that many engineers hate whiteboard-based interview questions.

对于任何人来说，许多工程师都讨厌基于白板的面试问题，这对任何人来说都不是新闻。

Whether it’s on Twitter, Medium, or LinkedIn, it’s easy to find someone venting. The phrase “the hiring process is broken” is used so often it’s become a cliché.

无论是在Twitter，Medium还是LinkedIn上，都很容易发泄。 经常使用“招聘过程中断”这一短语，这已成为陈词滥调。

Unfortunately, much of this frustration is falling on deaf ears.

不幸的是，许多挫败感落在了耳聋的耳朵上。

Despite the chorus of ire surrounding it, “whiteboarding” is still a staple in software engineering interviews. Part of that is due to the fact that developers are quick to voice their resentment, but slow to offer better alternatives.

尽管周围充满了烦恼，但“白板”仍然是软件工程采访中的主要内容。 部分原因是因为开发人员会很快表达自己的怨恨，但会缓慢地提供更好的选择。

有更好的选择吗？ (Are there better alternatives?)

This question has been on my mind a lot recently. Four weeks ago, I landed my first full-time software engineering job. While I’m not involved in the hiring process yet, I will be eventually.

最近我一直在想这个问题。 四周前， 我找到了我的第一份全职软件工程工作 。 虽然我还没有参与招聘过程，但最终我还是会的。

Having been on the other side of the table just a month ago, I understand how imprecise interviewing can be. When it’s my turn to ask the questions, I want to make sure that I evaluate my potential colleagues with accuracy and fairness.

就在一个月前出现在桌子的另一端之后，我了解到面试可能是不精确的。 轮到我问问题时，我要确保我以准确性和公正性评估我的潜在同事。

This predicament has led me to two questions:

这种困境使我想到了两个问题：

1. Are whiteboarding interviews the best choice?

   白板面试是最佳选择吗？

2. If not, what are the better alternatives?

   如果没有，还有什么更好的选择？

In this post, I’m going to attempt to answer these questions. Keep in mind, these are my personal opinions that have been shaped by my own interviewing experience.

在这篇文章中，我将尝试回答这些问题。 请记住，这些是我个人的见解，这些见解是根据我自己的采访经验而定的。

I will try to be as objective as possible by approaching this task in true software engineering fashion: examining all the options and weighing their tradeoffs.

我将以真正的软件工程方式来尝试完成此任务，以使目标尽可能客观：检查所有选项并权衡其权衡。

白板面试最差吗？ (Are whiteboarding interviews the worst?)

The first step in this process is to scrutinize whiteboarding.

此过程的第一步是仔细检查白板。

优点： (Pros:)

1. Fast and low effort
   快速省力
2. Not language or domain dependent
   与语言或领域无关
3. You know (generally) what to expect
   你知道(通常)会发生什么
4. Community support (Glassdoor, LeetCode, Pramp, and so on)
   社区支持(Glassdoor，LeetCode，Pramp等)

缺点： (Cons:)

1. Luck is a big factor (algorithm lottery)
   运气是一个很大的因素(算法彩票)
2. Doesn’t necessarily test engineering aptitude
   不一定测试工程能力
3. Favors young engineers and recent grads
   青睐年轻工程师和应届毕业生

For companies who require engineers to have a strong grasp on CS fundamentals, low level algorithms, and aren’t dependent on libraries, the whiteboarding interview is perfect.

对于需要工程师对CS基础知识，低级算法有较强了解并且不依赖库的公司，白板面试非常适合。

SpaceX, MacOS/Windows, and Facebook’s React were all built by engineers with such knowledge. To get a whiteboarding interview from one of these companies is to be expected.

SpaceX，MacOS / Windows和Facebook的React都是由具有此类知识的工程师构建的。 从这些公司之一获得白板采访是可以预期的。

As a job candidate, I love whiteboarding interviews. I know what to expect. Most algorithm questions fall under these general topics:

作为求职者，我喜欢白板面试。 我知道会发生什么。 大多数算法问题都属于以下一般主题：

• Arrays/Strings
  数组/字符串
• Binary Trees
  二叉树
• Linked Lists
  链表
• DFS/BFS
  DFS / BFS
• Backtracking
  回溯
• Dynamic programming
  动态编程

Knowing this ahead of time means I can study for it. And there’s a plethora of studying tools to choose from. Technical interview preparation is an entire industry of its own.

提前知道这一点意味着我可以学习。 并有一个大量 的 学习 工具 来 选择 从 。 技术面试准备本身就是整个行业。

It’s for that reason that whiteboarding interviews aren’t the best option for every company. So much of it comes down to luck, memorization, and whoever has spent the most time studying.

出于这个原因，白板面试并不是每个公司的最佳选择。 如此之多归结为运气，记忆和花费时间最多的人。

Not everyone can study for long swathes of time to master algorithms.

并不是每个人都可以花很长时间学习算法。

I was lucky that I could and outcompeted other engineers who couldn’t. Am I a better engineer than all of them? Maybe, but I’m not sure a whiteboarding interview is the best means of revealing it.

我很幸运能够胜过其他无法胜任的工程师。 我是一个比所有人都更好的工程师吗？ 也许可以，但是我不确定白板面试是揭示它的最好方法。

So if there’s doubt that the whiteboarding interview is the best tool for the job, what could be better?

因此，如果怀疑白板面试是否是该工作的最佳工具，还有什么会更好？

Let’s take a look at some of the alternatives.

让我们看一些替代方案。

通过计算机进行编码挑战 (Coding challenges via computer)

优点： (Pros:)

1. Get to use a computer and familiar dev environment
   开始使用计算机和熟悉的开发环境
2. Can be done remotely via screen share
   可以通过屏幕共享远程完成
3. All of the other advantages of whiteboarding interviews
   白板面试的所有其他优点

缺点： (Cons:)

1. More strict about syntax and run-ability.
   在语法和可运行性方面更加严格。
2. Programming environment and plugins can play a big factor
   编程环境和插件可以发挥重要作用
3. Same disadvantages of whiteboarding interviews
   白板面试的相同缺点

Coding Challenges on a laptop are the less rigorous cousin of the whiteboarding interview.

笔记本电脑上的编码挑战是白板采访中不那么严格的表亲。

Candidates have the benefit of using their own computers. They can be done remotely or in a pair programming environment.

候选人受益于使用自己的计算机。 它们可以远程或在一对编程环境中完成。

One nice thing I’ve noticed about these is that they will usually be easier than whiteboarding questions. Most of the questions I got involved string manipulation, or simple algorithms that any experienced engineer wouldn’t need to study for.

我注意到的一件好事是，它们通常比白板问题要容易。 我遇到的大多数问题都涉及字符串操作或任何经验丰富的工程师都不需要学习的简单算法。

The drawback to this is that there is much greater emphasis on functionality.

这样做的缺点是更加强调功能。

During my job hunt, I was asked the Coin Change problem twice. One as a whiteboard challenge and the other on an editor.

在找工作期间，我两次被问到找零硬币的问题。 一个作为白板的挑战，另一个作为编辑器。

For the whiteboard challenge, I got away with mainly explaining my solution. On my laptop, I was expected to write edge case tests and guarantee that my solution worked.

对于白板挑战，我主要介绍了我的解决方案。 在我的笔记本电脑上，我应该编写边缘案例测试并保证我的解决方案有效。

Part of the reason I like whiteboarding is due to the leniency. No one is going to run your written function through a compiler. As long as the interviewer understands what you’re thinking and the writing looks good enough, you get full credit.

我喜欢白板的部分原因是由于宽大处理。 没有人会通过编译器运行您编写的函数。 只要面试官理解您的想法，并且文字看起来足够好，您就会获得充分的信誉。

Not so with code challenges.

代码挑战并非如此。

Some may argue that the emphasis on functionality is better, because we’re paid to write working code. That’s true, but we aren’t getting paid to do it in 30–45 minute sprints.

有人可能会争辩说，对功能的强调会更好，因为我们得到了编写有效代码的报酬。 是的，但是我们并没有在30-45分钟的冲刺中获得报酬。

Let’s just hope you don’t get nervous during interviews. One small bug that causes failing tests and several minutes of debugging could be the difference between a “strong hire” or a pass.

只是希望您在面试时不要紧张。 导致测试失败和调试几分钟的一个小错误可能是“强聘”或通过的区别。

Code challenges still suffer from the same short comings as whiteboarding because many of them are algorithm-based.

由于许多挑战都是基于算法的，因此代码挑战仍然遭受与白板相同的短暂挑战。

With the added pressure of functionality, it can make the questions even more difficult despite the comfortable environment. If you already dislike algorithm problems, code challenges won’t be much better.

在舒适的环境中，随着功能压力的增加，问题将变得更加棘手。 如果您已经不喜欢算法问题，那么代码挑战将再好不过了。

进行家庭评估 (Take home assessments)

优点： (Pros:)

1. Can work on it in your pajamas
   可以穿着睡衣来做
2. Usually given upwards of a week to work on assignment
   通常需要一周以上的时间进行作业
3. Get to use your own editor and dev environment
   开始使用自己的编辑器和开发环境
4. Can be a new addition to portfolio
   可以成为投资组合的新成员
5. Usually more fun than whiteboarding
   通常比白板更有趣

缺点： (Cons:)

1. Level of difficulty can range drastically
   难度范围可能会很大
2. Much more effort and time consuming than coding challenges
   比编码挑战更多的精力和时间
3. Can be domain dependent
   可以取决于域
4. Can lead to feature creep due to competition
   可能由于竞争而导致特征蠕变
5. Doesn’t represent day to day work
   不代表日常工作

A lot of engineers prefer take home assignments. The timelines for turning them in are usually flexible, and candidates get to actually code. It’s no shock programmers prefer this to standing in front of a whiteboard while being silently judged.

许多工程师更喜欢带家庭作业。 上交时间表通常很灵活，考生可以开始实际编码。 程序员在静静地被评判时站在白板前并不奇怪。

However, take home tests have some major drawbacks.

但是，带回家测试有一些主要缺点。

Firstly, they’re easy to manipulate.

首先，它们易于操作。

Many companies host their tests on GitHub. Type in “Challenge” or “Test” into GitHub search and you’ll find plenty. This will give the savvy candidate plenty of time to preemptively research the challenge.

许多公司在GitHub上托管测试。 在GitHub搜索中输入“挑战”或“测试”，您会发现很多。 这将使精明的候选人有足够的时间先发制人地研究挑战。

That’s not really a complaint. Just more of a pro-tip.

那不是真正的抱怨。 只是一些小费。

What is an issue is that it’s easy enough to find other people’s answers to these challenges and copy them. Plenty of engineers keep the answers to take home challenges on their GitHub profiles.

什么是一个问题是，这是很容易找到别人的答案，这些挑战，并复制它们。 许多工程师在GitHub个人资料中保留了应对挑战的答案。

You can even test it yourself. Type “<Company Name> Challenge” into GitHub search and see what you find.

您甚至可以自己对其进行测试。 在GitHub搜索中输入“ <公司名称>挑战”，然后查看发现的内容。

I live next to the Etsy headquarters in Brooklyn and was curious if I could find the answers to some of their tests. “Etsy Challenge” revealed four. There were even more under “Etsy Test”.

我住在布鲁克林Etsy总部旁边，很好奇我能否找到他们的一些测试的答案。 “挑战挑战赛”共有四场。 “ Etsy测试”下还有更多内容。

It’s true that companies can change their assessments. However, it can be a hassle to change an interview process every couple months due to details being leaked.

的确，公司可以更改其评估。 但是，由于细节泄露，每两个月更改一次面试过程可能很麻烦。

Secondly, the level of difficulty and time it takes to finish these challenges varies widely.

其次，完成这些挑战所需的难度和时间水平差异很大。

During my last job hunt, I was given four take home assignments. Three of the companies said they should only take 3–5 hours to finish.

在上一次求职期间，给了我四份实地任务。 其中三家公司表示，它们只需要3-5个小时即可完成。

They all took me multiple days.

他们花了我很多天。

The main reason for this was because the challenges were often domain specific. They required several hours of researching API docs and new technologies.

这样做的主要原因是因为挑战通常是针对特定领域的。 他们需要花费几个小时来研究API文档和新技术。

The fourth company took a challenge that could easily take a week and gave me two days. I had to build a functioning chat app that supported slash commands.

第四家公司接受了一个挑战，可能很容易就花了一周的时间，却给了我两天的时间。 我必须构建一个支持斜杠命令的功能正常的聊天应用程序 。

It was a fun and interesting project, but it required me to drop everything I was doing for two days in order to complete it.

这是一个有趣且有趣的项目，但是它需要我放弃两天的工作才能完成。

If a candidate is fortunate enough to interview with multiple companies at once, it can become a full time job just working on these challenges.

如果候选人有幸一次可以面试多家公司，那么应对这些挑战就可以成为全职工作。

Additionally, professional developers have to work on legacy codebases and deal with deadlines. A week long greenfield project isn’t going to assess how well the interviewee works in a fast paced environment.

此外，专业开发人员必须处理遗留代码库并处理截止日期。 一个为期一周的未开发项目不会评估受访者在快速节奏的环境中的工作状况。

Overall, I like take home assignments as an initial screen of a candidate’s ability. With that said, they should be related to the job the candidate is applying for, and shouldn’t take an obscene amount of time to finish.

总体而言，我喜欢将家庭作业作为候选人能力的初始屏幕。 话虽如此，他们应该与候选人正在申请的工作相关，并且不应花大量时间完成工作。

基于项目/合同签订 (Project Based/Contract-to-Hire)

优点： (Pros:)

1. Get a chance to work with candidate/team
   有机会与候选人/团队合作
2. Get paid to work
   获得工作报酬
3. Get to work on real projects
   开始从事真实的项目
4. Are evaluated on how well you work with team and ship code
   评估您如何处理团队和运输代码

缺点： (Cons:)

1. Long time commitment
   长期承诺
2. Working without a guarantee of employment
   没有就业保障的工作
3. No health benefits as a contractor
   作为承包商没有健康利益
4. Can put candidate in bad negotiating position
   可以使候选人处于不利的谈判地位
5. Language dependent
   取决于语言

Project-based interviews are rare. But quite a few companies stand by them, such as Basecamp and Automatic. I can understand why.

基于项目的采访很少见。 但是有很多公司支持他们，例如Basecamp和Automatic。 我能理解为什么。

These interviews are probably the most accurate way to assess someone’s skill and evaluate them as a team member. The company gets to work with them directly and see how they handle tasks in a team.

这些面试可能是评估某人技能并将其作为团队成员进行评估的最准确方法。 公司可以直接与他们合作，并了解他们如何在团队中处理任务。

The candidate also gets a chance to evaluate the company and determine if it is the type of environment they would like to work in.

候选人还有机会评估公司，并确定这是否是他们想要工作的环境类型。

Win-win. Or so it seems.

双赢。 大概是这样。

With all of that said, as a job candidate, I would never partake in project-based interviews or contract-to-hire roles. The negatives far outweigh the positives.

综上所述，作为求职者，我永远不会参加基于项目的面试或从合同到雇用的角色。 负面影响远大于正面影响。

The first couple months of any job are typically the toughest. You’re acclimatizing to a new team, culture, codebase. Now imagine working on a project not knowing if you’ll have a job by the end.

任何工作的前几个月通常都是最艰难的。 您正在适应新的团队，文化和代码库。 现在想象一下在一个项目中工作，不知道最后是否会有工作。

A good friend of mine recently interviewed at Automatic and confirmed how stressful it can be. Everything from the way you interact with coworkers to the questions you ask are judged. In these environments, there is such thing as a “stupid question.”

我的一个好朋友最近在《 Automatic》上接受采访，并确认它会带来多大的压力。 从与同事互动的方式到您提出的问题，所有内容都会得到评估。 在这些环境中， 有这样的事情作为一个“愚蠢的问题。”

What’s worse is that he was let go after the three month contract. Luckily, he hasn’t let it impact his self-esteem. He knows his ability and is charging ahead. I’m not sure if I, or many other engineers, could do the same so easily.

更糟糕的是，他在三个月的合同后被放开了。 幸运的是，他没有让它影响他的自尊。 他知道自己的能力，并且正在向前冲。 我不确定我或其他许多工程师是否可以这么轻松地做到这一点。

Furthermore, contracts put the job seeker in an awful negotiating position. Strength in negotiations comes from the willingness to walk away.

此外，合同使求职者处于糟糕的谈判位置。 谈判的力量来自于走开的意愿。

By the end of a contract-to-hire period, the potential candidate won’t have any bargaining chips. They won’t have any other offers and they’ve already poured dozens or hundreds of hours into their projects depending on the contract length.

到合同雇用期结束时，潜在候选人将没有任何筹码。 他们没有其他报价，他们已经根据合同期限在他们的项目中投入了数十或数百个小时。

They would be incentivized to take the position even if it’s not their preferred choice. The alternative is to join the job market back at square one.

即使不是他们的首选，他们也会被激励去担任这个职位。 另一种选择是重新加入劳动力市场。

The Sunk Cost Fallacy at its finest.

沉没成本谬论处于最佳状态。

While whiteboarding interviews may not be ideal, I would do a hundred of them before I ever did a project-based interview.

尽管白板面试可能并不理想，但在进行基于项目的面试之前，我会先进行一百次面试。

那么哪个最好？ (So which is the best?)

As you might’ve guessed: It Depends™.

您可能已经猜到了：It Depends™。

The tradeoffs seem to be between speed and effort versus accuracy. Each method sacrifices one for the other. It is up to each company to judge those tradeoffs for themselves. SpaceX is most likely going to have a different process than small New York startup.

权衡似乎在速度和精力与准确性之间。 每种方法都为另一个牺牲。 每个公司都应自行判断这些折衷方案。 SpaceX可能与纽约小型初创公司的流程有所不同。

What is true is that a SaaS company should only ask candidates to write out dynamic programming algorithms if it helps them determine the engineer’s skill. Not simply because Google does it.

真正的事实是，SaaS公司仅应要求候选人写出动态编程算法，以帮助他们确定工程师的技能。 不仅仅是因为Google这么做。

If I were designing the interview process for my team at DigitalOcean, I would use a mixture of take home assessments and code challenges/pairing exercises. I would also gauge their understanding of availability and distributed systems through a Q&A session and system design challenge.

如果我要为DigitalOcean的团队设计面试流程，则需要结合使用实地评估和代码挑战/配对练习。 我还将通过问答环节和系统设计挑战来评估他们对可用性和分布式系统的理解。

The good news is that my team already does this. DigitalOcean’s tough yet fair interview process was one of the reasons I accepted their offer. It proved to me that they had already gone through this self-examination process and found out how to fairly evaluate their candidates.

好消息是我的团队已经做到了。 DigitalOcean艰难而公正的采访过程是我接受他们的报价的原因之一。 向我证明，他们已经经历了这个自我检查过程，并且发现了如何公平地评估他们的候选人。

Please let me know what your preferred interview method in the comments below!

请在下面的评论中告诉我您首选的面试方法！

Finally, for all you engineers who want to see the interview process change, start coming up with ideas. I’ve seen too many engineers rant about whiteboarding interviews only to continue the process once they get hired because it’s too much work to change it.

最后，对于所有希望看到面试过程发生变化的工程师，请开始提出构想。 我已经看到太多工程师对白板面试一无所知，只是在被录用后才继续进行此程序，因为要进行更改是一件繁重的工作。

Don’t be that person.

不要做那个人。

Stop complaining.

停止抱怨。

Find solutions.

寻找解决方案。

翻译自: https://www.freecodecamp.org/news/lets-talk-about-whiteboarding-interviews-fed040e20cc9/

头条白板面试