头条白板面试_如何在白板上组织您的想法并粉碎技术面试

头条白板面试

by Doug Arcuri

由道格·阿库里(Doug Arcuri)

如何在白板上组织您的想法并粉碎技术面试 (How to organize your thoughts on the whiteboard and crush your technical interview)

关于软件技能中的组织技能和将很多东西融合在一起的应用科学 (On organizational skills and the applied science of gluing lots of things together in the craft of software engineering)

Some weeks ago, a bright individual reposted on Hacker News a well-thought out and succinct post about the most important skill in software development. In this post, John D. Cook pointed out a quote from the article Organizational Skills Beat Algorithmic Wizardry, by James Hague. Both authors tackle the software engineering subject of organization as a skill. They contrast this to the mastery of computer science tested in interviews, taught in academia, or touted in blog posts. Their contemplation got me pondering about how our craft could be improved.

几周前，一位聪明的人在Hacker News上重新发布了一篇经过深思熟虑的简洁文章，内容涉及软件开发中最重要的技能 。 约翰·库克(John D. Cook)在本文中指出了詹姆斯·海格(James Hague)的文章《 组织技能击败算法向导》 。 两位作者都将组织的软件工程主题作为技能来解决 。 他们将此与 对计算机科学的精通是在面试中测试，在学术界任教或在博客文章中吹捧。 他们的沉思使我思考如何改进我们的手艺。

Thinking deeply about both authors’ messages, I ran through my own experiences over time. I empathize with those who experience technical interviews that are not classically trained. My last experience some years ago was disorganized.

我对两位作者的信息进行了深思，因此我逐渐了解了自己的经历。 我对那些经历过未经传统培训的技术面试的人表示同情。 我几年前的最后经历是混乱的。

My last completed professional project was a three old year system that dealt with code complexity, and a never-ending rolling line of products. We fought bravely to organize the growing mess. Both thoughts had a common thread, as they were small and large exercises in organization. They revolved around feelings of anxiety, vulnerability, stress, and happy moments. I (we) cared deeply about outcomes.

我最后一个完成的专业项目是一个使用三年的系统，该系统处理代码复杂性，并且产品线永无止境。 我们勇敢地组织了越来越多的混乱局面。 两种思想都有一个共同的线索，因为它们是组织中的大小事。 他们围绕焦虑，脆弱，压力和快乐时光的感觉旋转。 我(我们)非常关心结果。

This motivated me to write a follow-up in my own way. This is because I was moved by the gravity of these posts. Why not answer questions posed even if my example response did not match cleanly? So I kicked the idea back and forth and hung on one question. John asked:

这促使我以自己的方式编写后续报告。 这是因为我被这些职位的重力所感动。 为什么即使我的示例答案与答案不完全一致也要回答提出的问题？ 因此，我反复提出了这个想法，并提出了一个问题。 约翰问：

…how do you present a clever bit of organization?

…您如何呈现一个聪明的组织？

Thinking about this a bit, I looked away from the screen and saw my whiteboard standing before me. My head swirled around the posts. Tough technical interviews? Organization? Managing state? Collapsing weight? Code complexity? Perhaps the technical interview whiteboard exercise could prove a salient point of software engineering all along.

考虑了一下，我把目光从屏幕上移开，看到白板站在我面前。 我的头在柱子周围旋转。 艰难的技术面试？ 组织？ 管理状态？ 崩溃的体重？ 代码复杂度？ 也许技术面试白板练习可以始终证明软件工程的重点。

So I started solving some typical problems at the whiteboard, nervously, all by myself.

因此，我开始独自一人紧张地在白板上解决一些典型问题。

Rarely at a whiteboard does anyone perform well. You have to show a masterful thought process and hold a lot in your head. You have to communicate, but how do you communicate while ignoring the screaming voice in your head that says “hurry up!” while moving around enthusiastically?

很少有人在白板上表现出色。 您必须表现出精湛的思维过程，并掌握很多东西。 您必须进行交流，但是您如何交流却忽略了脑中尖叫的声音：“ 快点 ！” 同时热情地走动吗？

更好的方法 (A better approach)

At large and small technical companies, there are whiteboard technical interviews. You are placed in a white room with a whiteboard with one other individual who represents the company. He or she asks a question and we are invited to solve the problem. Then it’s usually up to the interviewee to drive the problem to a solution.

在大小型技术公司中，都有白板技术访谈。 您与其他代表公司的个人一起坐在带有白板的白色房间中。 他或她问了一个问题，我们被邀请解决该问题。 然后通常由受访者决定问题的解决方案。

This is where my head starts to spin out of control by way of anxiety and disorganization. Trumpets begin to play in my head and my thought process becomes mangled. Time speeds up. My vision narrows and I become lightheaded.

这是我的头开始由于焦虑和混乱而失控的地方。 小号开始在我的脑海中弹奏，我的思维过程变得混乱。 时间加快了。 我的视野缩小，我变得头昏眼花。

Maybe there is a way to slow down, pace, and walk through a process with organization. Something I’ve never actually seen before while interviewing candidates over my years, but maybe it can help ease the nerves and make it an enjoyable experience. First, look at the board, and cut it up into three sections.

也许有一种方法可以减慢，加快步伐并逐步完成组织工作 。 这些年来，我在面试应聘者时从未真正见过的东西，但也许可以帮助您缓解紧张情绪，并使之成为一种愉快的体验。 首先，看一下木板，并将其切成三部分。

The three sections will be organized for temporary space to work toward solving the problem.

这三个部分将组织临时空间，以解决问题。

步骤1：问题 (Step 1: the problem)

Make sure to write down the problem in a complete sentence up top. This will get you feeling the marker and will help you overcome the initial hit of the rush of “how do I solve this?”

确保将问题完整地写下来。 这将使您感觉到标记，并帮助您克服“我如何解决此问题？”的热潮。

Once you have the question written down, look at it for a moment and start to think about questions. Draw the lines with ample space. Don’t worry about the pause, let the interviewer know that you are thinking about questions to ask.

写下问题后，请看一会儿，然后开始思考问题。 用足够的空间画线。 不用担心停顿，让面试官知道您正在考虑要提问的问题。

步骤2：假设 (Step 2: Assumptions)

Think about some generic questions. Like, what programming language do you prefer? Move to the right side of the board. No questions coming? The problem may contain concepts you don’t know. Ask what they are. Then, start tackling the problem questions. The first ones to ask are what is an example of the parameter input and output. Ask if the data is presorted.

考虑一些通用的问题。 喜欢，您喜欢哪种编程语言？ 移动到板子的右侧。 没有问题吗？ 该问题可能包含您不知道的概念。 问他们是什么。 然后，开始解决问题。 首先要问的是参数输入和输出的示例。 询问数据是否已预先排序。

Clarifying assumptions can simplify the problem. As you ask each question, you should write each answer pair in the assumptions area. When you receive answers, get a secondary marker (a different color) to highlight the answer. Bringing your own markers may help.

明确假设可以简化问题。 提出每个问题时，应在假设区域中写下每个答案对。 收到答案时，请使用辅助标记(其他颜色)突出显示答案。 带上自己的标记可能会有所帮助。

We can only hold so many items in our head, so lean heavily on the board to capture all the knowledge. Writing the questions and answers out will slow down your approach so it is digestible.

我们只能把这么多东西放在脑子里，所以要靠在木板上以获取所有知识。 写出问题和答案会减慢您的处理速度，因此很容易理解。

第三步：方法 (Step 3: the approach)

Once you have a good number of questions on the right side of the board, physically move over to the left. This is where we will start to discuss an approach to our solve.

一旦您在董事会的右边有很多问题，就从身体上移到左边。 这是我们将开始讨论解决方法的地方。

Here, very rough pseudocode, steps, and visualizations occur. Let your interviewer know that this is not your implementation, but a place where you are organizing your thoughts on the strategy and approach, loosely on data structures and abstract data types. Draw out the solve like its a picture.

在这里，会出现非常粗糙的伪代码，步骤和可视化。 让您的面试官知道这不是您的实现，而是一个您在其中组织有关策略和方法的思想，松散地了解数据结构和抽象数据类型的地方。 如图画出解决方案。

The left box will demonstrate something very interesting in that it should reveal holes in our questions. As you write and think out your approach, stop your thought process if a question is not answered. Walk back to the right section, and write out the question and try to receive the answer.

左框将展示一些非常有趣的东西，因为它应该揭示我们问题中的漏洞。 在编写和思考方法时，如果未回答问题，请停止思考过程。 返回右侧部分，写下问题并尝试获得答案。

At the absolute minimum, this will happen a few times as you recognize the average cases, best cases, and worst cases. It depends on the strategy, the limits and the constraints. Request relaxation on approach such as “For this example, can I use a small set of data?” “Can I assume the input array is sorted?” Input validation is also another question generator.

当您认识到平均情况，最佳情况和最坏情况时 ，这种情况至少会发生几次。 这取决于策略，限制和约束。 请求放宽方法，例如“对于这个例子，我可以使用一小部分数据吗？” “我可以假设输入数组已排序吗？” 输入验证也是另一个问题生成器。

第四步：代码实现 (Step 4: code implementation)

Once enough assumptions and approach material are generated, this means that you are now ready to write through your implementation code with confidence. You will be supported by both sides. Highlight and point to each step as you write the code. Carefully step through the approach, listed to your left. As you write your implementation, go back and forth double-checking the assumptions.

生成足够的假设和方法材料后，这意味着您现在可以放心地编写实现代码了。 双方都会为您提供支持。 编写代码时突出显示并指向每个步骤。 小心地执行此方法，列在您的左侧。 在编写实现时，请反复检查这些假设。

Even if you struggle with the solve, you are the wizard of organization.

即使您在解决问题上遇到困难，您也是组织的向导。

Of course, there is a possibility of finding something in the act. Walk back to the left and revive the approach break down and ask for assistance. New questions pop up. Go to the right. Go back and forth from left to right to center until you succeed. You will.

当然，有可能在表演中找到一些东西。 向左走，使方法恢复正常并寻求帮助。 新问题弹出。 转到右边。 从左到右来回居中，直到成功。 你会。

Be the master of organization. If you hit a wall or find something that is just not right, remember that the sides will guide you.

成为组织的主人。 如果碰壁或发现不正确的地方，请记住侧面会引导您。

奖励步骤5：测试 (Bonus Step 5: test)

If you have completed the exercise with code you think is working, take the first step to discuss how it should be tested. Use the assumptions section as a place to write clean test code, if you should choose to do so.

如果完成了您认为可以正常运行的代码的练习，请迈出第一步讨论如何对其进行测试。 如果您应该选择使用“假设”部分，则可以编写干净的测试代码。

By now, it is most likely safe to remove all the questions from this area. Erase the questions and attempt to write unit tests. In the end, you’ll be okay because you organized with confidence.

到目前为止，最有可能从该区域删除所有问题。 消除问题并尝试编写单元测试。 最后，您会没事的，因为您信心十足。

总结一下 (To sum up)

There you go. That was a few minutes of pure organization without much theory. It leans on a few simple concepts.

妳去 那是几分钟的纯组织，没有太多理论。 它基于一些简单的概念。

1. Sectioning — slicing up the problem in pieces from start to finish.

   切片 - 从头到尾将问题分解成碎片。

2. Scaffolding — the concept of temporary architecture or where we set up a supporting structure as we build around us.

   脚手架 -临时建筑的概念，或在我们周围建立房屋时建立支撑结构的地方。

3. Gating — we should not proceed forward with the next step until we are comfortable and confident about the affairs of addressing the problem well. Display confidence but actively engage with “Did I miss any assumptions?” or “Does my approach have holes?” before proceeding.

   门控 -在对解决问题感到满意和自信之前，我们不应该继续进行下一步。 表现出信心，但积极参与“我错过任何假设吗？” 或“我的方法有漏洞吗？” 在继续之前。

4. State — organization is handled visually to maintain the weighing complexity of the problem. Avoid using an eraser if you can.

   状态 -对组织进行视觉处理以保持问题的复杂性。 如果可以，请避免使用橡皮擦。

结论 (Conclusion)

I wanted to finish up with some tidbits that will bring my thought process home.

我想以一些花絮来结束我的思​​考过程。

You can’t appreciate a feat of organization until you experience the disorganization. — John

在经历混乱之前，您无法欣赏组织的壮举。 - 约翰

I agree. This applies to any human experience including projects with code, people, and those technical whiteboard experiences. But to take a step back and answer the problem with a process of organization is a feat of engineering. A problem and a potential solution.

我同意。 这适用于任何人类经验，包括具有代码，人员的项目以及那些技术性白板经验。 但是，退后一步并用组织过程来回答问题是一项工程壮举。 一个问题和一个可能的解决方案。

The key to engineering is potential organization. A large kinetic energy comes from the act of organizing astutely and continuously over time.

工程的关键是潜在的组织 。 大量动能来自于随着时间的推移不断精巧地组织起来的行为。

Never underestimate this phenomenon.

永远不要低估这种现象。

Only if the disorganized mess is your responsibility, something that means more to you than a case study, can you wrap your head around it and appreciate improvements. — John

仅当混乱的混乱是您的责任时，对您而言比案例研究更重要的是，您可以全神贯注并欣赏改进。 - 约翰

We all have a story about the whiteboard. I wanted to find how I could improve and task my engineering mind at the same time. Many an engineer connects emotionally at the whiteboard. We all have the stories of damned defeat.

我们都有一个关于白板的故事。 我想找到如何同时改善和分配工程思维的方法。 许多工程师在白板上建立了情感联系。 我们都有失败的故事。

Most of our craft is an applied science. Rarely, the gifted can tinker and tamper to invent new data structures or algorithms. Ours is one of a pattern language and a craft. It is rarely art, if ever. It has a lot to do with identifying the latest organization skill and ungluing and gluing things together very well, repeatedly. Perhaps with some tools out of the toolbox. But be careful of the tools of organization that are pushed on us by an exchange or by enthusiasm.

我们的大部分手艺都是一门应用科学。 极少有天赋的人可以修补和篡改以发明新的数据结构或算法。 我们的语言是一种模式语言和一种Craft.io 。 如果有的话，这很少是艺术。 有很多事情要做 识别最新的组织技能，并反复很好地脱胶和粘合在一起。 也许在工具箱之外有一些工具。 但是要注意交流或热情推动我们使用的组织工具。

Remember, there is pride in improving on top of code by way of organization and structure. I’ve written a few posts about organization and the subject linking organization to system complexity. There is a strong link. This is why I appreciated John’s and James’ thoughts deeply. They are organized messages without hurry up time expiration.

请记住，以组织和结构的方式在代码之上进行改进而感到自豪。 我写了一些有关组织以及将组织与系统复杂性联系起来的主题的 文章 。 有很强的联系。 这就是为什么我对约翰和詹姆斯的思想深表赞赏。 它们是有条理的消息，而不必着急时间到期。

If you find yourself in this situation, ask for a larger whiteboard!

如果您遇到这种情况 ，请要求使用更大的白板！

翻译自: https://www.freecodecamp.org/news/how-to-organize-your-thoughts-on-the-whiteboard-and-crush-your-technical-interview-b668de4e6941/

头条白板面试