I jut recently completed a month-long job search in which I went through 75 interviews, resulting in 7 offers. The technical interviews I went through could be classified as good or terrible.

我认为我最近完成了为期一个月的求职，在其中进行了75次面试，获得了7个职位。 我所经历的技术面试可分为好或坏。

The good ones were great. They were engaging, fun, and left room to interact with people and go through the thought process and tradeoff discussions together. They felt like conversations and collaborative problem solving.

好人很棒。 他们充满互动，充满乐趣，并留有与人互动的空间，并一起进行了思考过程和权衡讨论。 他们感觉像是对话和协作式问题解决。

The terrible ones were truly terrible. Some asked me to invest five hours into take-home projects, despite the fact I had a job as well as an extensive portfolio of open-source side projects. Others ask me to spend hours to complete technical assessments that ended up not assessing anything related to the role. Others asked me to refactor or code, but then provided only skeleton boilerplate code that left little room to actually demonstrate engineering skills and technical knowledge.

可怕的是真正可怕的。 尽管我有一份工作以及大量开源方面的项目，但有些人还是要求我将五个小时投资于实得项目。 其他人要求我花几个小时来完成技术评估，结果最终没有评估与该角色有关的任何内容。 其他人要求我进行重构或编码，但随后只提供了框架样板代码，几乎没有余地实际展示工程技能和技术知识。

As someone who has been on both sides of the hiring aisle many times, it pains me to see such terrible interviews being inflicted upon candidates and companies alike.

作为多次在招聘通道两边工作的人，看到候选人和公司遭受如此可怕的面试让我很痛苦。

会造成持久伤害 (It does lasting damage)

Bad interviews hurt candidates, who have to be exposed to stressful situations that leave them feeling defeated and dejected, even if they would make otherwise excellent hires.

差劲的面试伤害了应聘者，他们不得不面对压力大的环境，即使他们本来可以成为优秀的员工，也要感到沮丧和沮丧。

They also hurt the companies themselves by extending the time it takes for them to hire, as well as leaving them with poor reputations amongst the candidates who have to endure it.

他们还延长了聘用时间，并在必须忍受的候选人中使他们的声誉欠佳，从而伤害了公司自身。

这个过程坏了 (The process is broken)

Companies simply don’t know what they are hiring for. Because of this, they use the wrong or ineffective technical assessments and evaluate the wrong skills.

公司根本不知道他们在招聘什么。 因此，他们使用错误或无效的技术评估并评估错误的技能。

了解您要招聘的技能 (Know the skills you’re hiring for)

Did you know there’s differences between the following?

您知道以下两者之间的区别吗？

• Coding
  编码
• Programming
  程式设计
• Engineering
  工程
• Architecting
  建筑设计
• Developing
  发展

Are you using the appropriate technical interview questions to identify the appropriate skills needed for the specific role you are hiring for?

您是否使用适当的技术面试问题来确定您要招聘的特定职位所需的适当技能？

编码 (Coding)

Coding is the mechanical process of entering code instructions into the computer. Familiarity with language syntax, standard libraries, etc. are the skillsets involved here.

编码是将代码指令输入计算机的机械过程。 熟悉语言语法，标准库等是此处涉及的技能组。

例子： (Examples:)

If you’re asking someone to write a for-loop that prints the numbers 1 through 10, you’re testing their coding skills.

如果您要某人编写一个打印数字1到10的for循环，那么您正在测试他们的编码技能。

(1..10).each { |i| puts "#{i} " }# 1 2 3 4 5 6 7 8 9 10

Problems that assess coding skills often:

经常评估编码技能的问题：

• Have a single method that has a deterministic result
  具有确定性结果的单一方法
• Have a well-defined or easily discoverable algorithm
  拥有定义明确或易于发现的算法
• Have well-defined inputs
  输入明确
• Have well-defined outputs
  具有明确的输出

The prompt might look like:

提示可能如下所示：

def fizzbuzz(n)

# Print fizz if the answer is divisible by 10

# Print buzz if the answer is divisible by 5
end

The above example has a very clear input, a very clear process, and a very clear output.

上面的示例具有非常清晰的输入，非常清晰的过程和非常清晰的输出。

Even in cases where the algorithm is not explicitly defined, it is still relatively simple — there’s no complex calculations, forward-looking/backwards-looking logic, or gotchas.

即使在没有明确定义算法的情况下，它仍然相对简单-没有复杂的计算，前瞻性/后向逻辑或陷阱。

这对候选人有什么启示？ (What does this tell you about the candidate?)

Candidates performance in coding gives a few clear signals:

候选人在编码方面的表现给出了一些明确的信号：

• Are they aware of the language constructs available to them?
  他们知道他们可用的语言结构吗？
• Can they take a sequence of defined steps and input them into the computer?
  他们可以采取一系列已定义的步骤并将其输入计算机吗？
• Can they translate the real-world steps into actual, working code?
  他们可以将实际步骤转换为实际的工作代码吗？

However, there’s also some noise. Performance doesn’t necessarily indicate:

但是，也有一些噪音。 性能并不一定表示：

• Whether people can structure programs maintainably
  人们是否可以维持程序结构
• Whether people can implement business requirements
  人们是否可以执行业务需求
• Whether people can optimize systems
  人们是否可以优化系统
• Whether people can solve problems
  人们是否可以解决问题
• Whether people understand the technology, how to integrate with them, or the tools available to them
  人们是否了解技术，如何与他们集成或对他们可用的工具

Coding assessments are great for filtering out people who don’t know anything about writing computer programs.

编码评估是伟大的过滤掉的人谁不知道怎么写计算机程序什么 。

程式设计 (Programming)

Programming is the act of creating a sequence of steps that can be translated into code to solve the problem at hand. Knowing algorithms, the various attributes of data structures, and problem analysis techniques are the name of the game here.

编程是创建一系列步骤的动作，这些步骤可以转换为代码来解决当前的问题。 众所周知的算法，数据结构的各种属性以及问题分析技术就是这里的游戏名称。

The solution space for a good programmer is optimal runtimes, minimal growth curves, and low memory and processor usage.

优秀程序员的解决方案空间是最佳的运行时间，最小的增长曲线以及较低的内存和处理器使用率。

Also important to note is that there are two rather distinct types of programming problems.

还要注意的重要一点是，有两种非常不同类型的编程问题。

Simpler programming problems like “check if this string is an anagram of another string” can be done with basic problem solving.

可以通过基本的问题解决方法来完成一些更简单的编程问题，例如“检查此字符串是否是另一个字符串的字谜”。

Advanced programming problems like “what is the minimum number of moves this knight must make before they have visited each square at least once?” requires a certain level of mathematical or algorithmic knowledge that many find difficult to derive or use in an interview setting.

高级编程 问题，例如“该骑士至少访问每个广场一次必须执行的最小移动次数是多少？” 需要一定水平的数学或算法知识，许多知识很难在面试中获得或使用。

例子 (Examples)

Programming questions are often arbitrary problems with some sort of brute-force solution, and a hidden optimal solution.

编程问题通常是带有某种蛮力解决方案和隐藏的最佳解决方案的任意问题。

The problems often are abstract or don’t particularly represent any real-world use-case.

这些问题通常是抽象的，或者并不特别代表任何实际用例。

The solution itself may be hidden behind a “gotcha” — a solution you would only reasonably know if you had seen it before.

该解决方案本身可能隐藏在“陷阱”后面-您只有在以前看过该解决方案的情况下，才能合理地知道该解决方案。

Programming problems may read like below:

编程问题可能如下所示：

• Write a function that finds the length of the largest substring without repeating characters.
  编写一个函数，该函数无需重复字符即可查找最大子字符串的长度。
• What is the minimum number of moves this knight must make before they have visited each square at least once?
  该骑士至少访问每个广场一次必须执行的最少移动次数是多少？
• Write a function to sort this list of numbers.
  编写一个函数来对此数字列表进行排序。

The medium is often a whiteboard, coding pad, or an online assessment. This is the kind of dreaded “whiteboard interview” that many developers hate but the industry embraces.

介质通常是白板，编码板或在线评估。 这是许多开发人员讨厌但业界接受的那种可怕的“白板采访”。

这对候选人有什么启示？ (What does this tell you about the candidate?)

The signal:

信号：

• Can they develop or optimize algorithms to manipulate data in an effective, efficient way?
  他们是否可以开发或优化算法来有效，高效地处理数据？
• Can they optimize programs?
  他们可以优化程序吗？

The noise:

噪音：

• It does not show you whether people can structure programs maintainably.
  它没有向您显示人们是否可以维护程序的结构。
• It does not show you whether people can implement business requirements.
  它没有向您显示人们是否可以实现业务需求。
• It does not show you whether people can solve engineering problems.
  它没有向您显示人们是否可以解决工程问题。

• It does not actually show you whether people can solve programming problems, either.

  它实际上也没有向您显示人们是否可以解决编程问题。

等待-最后一点呢？ (Wait — what about that last point?)

It turns out the signal here may still be noise.

事实证明，此处的信号可能仍然是噪声。

You see — there’s only two ways to solve these programming problems: you have to derive the algorithm on the fly, or have to know it already.

您将看到–只有两种方法可以解决这些编程问题：您必须动态导出算法，或者必须已经知道它。

This is interesting. By studying specifically for these programming questions, you can excel at them. But, you can study them in two ways — either by truly learning and knowing how to derive the solution, or rote memorization of the solutions and a bit of luck encountering a known problem.

这是有趣的。 通过专门研究这些编程问题，您可以在这些方面脱颖而出。 但是，您可以通过两种方式研究它们-真正地学习和知道如何得出解决方案，或者死记硬背解决方案以及遇到一个已知问题时有些运气。

This assessment style specifically incentivizes candidates to lie and pretend they haven’t seen the problem before to better emphasize their problem-solving skills. At that point, is there an actual signal?

这种评估方式特别激励候选人撒谎，并假装他们从未见过问题，以便更好地强调其解决问题的能力。 那时，是否有实际信号？

Additionally, by introducing the element of studying, this test specifically favors candidates who have this information is fresh in their minds, such as recent graduates of computer science programs. It actively disfavors people who have been in the industry gaining experience building things, or people without the time to study. It is a hidden, unspoken, albeit indirect bias against age and people with families or other commitments.

此外，通过引入学习元素，该考试特别适合那些心中有新知识的候选人，例如计算机科学专业的应届毕业生。 它会严重不利于已经在该行业积累经验的人或没有时间学习的人。 它是对年龄和有家庭或其他承诺的人的间接，隐性的，不言而喻的偏见。

All the worse, most companies don’t actually need this kind of problem solving ability. With the exception of some larger, data-heavy, at-scale organizations like Google or Amazon, what most companies really need are people who can build features, structure systems, and make them adaptable to changing business requirements.

更糟糕的是， 大多数公司实际上并不需要这种解决问题的能力。 除了诸如Google或Amazon之类的规模较大，数据繁重的规模化组织外，大多数公司真正需要的是可以构建功能，构建系统并使其适应不断变化的业务需求的人员。

In these cases, such programming problems are a valueless assessment. These solutions do not translate into effective problem-solving at the product and systems level. You are not FAANG company, so stop interviewing like them.

在这些情况下，这样的编程问题是无价值的评估 。 这些解决方案无法在产品和系统级别转化为有效的问题解决方案。 您不是FAANG的公司，所以不要像他们一样进行采访。

This is also not mentioning the fact that computer scientists have spent decades of their lives originally developing these algorithms, and these whiteboard interviews often expect you to derive the solution in 30 minutes.

这也没有提及计算机科学家最初花费了数十年的时间来开发这些算法的事实，而这些白板采访通常希望您在30分钟内得出解决方案。

“我们需要弄清楚候选人是否可以编码” (“We need to figure out if the candidate can code”)

This is often the go-to reason when I ask companies why they do these style of interviews. What people forget when designing their technical interview questions: coding and programming are two separate skills.

当我问公司为什么要进行这种类型的采访时，这通常是首选理由。 人们在设计技术面试问题时会忘记什么：编码和编程是两项独立的技能。

They incorrectly conflate the two. Programming implies coding, but you can be a great programmer and a terrible coder, or vice versa.

他们错误地将两者混为一谈。 编程意味着编码，但是您可以成为一名出色的程序员和糟糕的编码器，反之亦然。

Let’s say you are an algorithm developer that knows the algorithm, but you’ve never coded a single instruction in your life. In this situation, you are not a coder, but you are a programmer.

假设您是一位了解算法的算法开发人员，但是您从来没有编写过一条指令。 在这种情况下，您不是编码人员，而是程序员。

Being a terrible coder is often also be a temporary state of being and is contextual. For example, I know Java, but if you asked me to develop in C#, I will be a terrible coder until I can ramp up in the available language constructs, which may end up being a matter of a week or two.

成为一个糟糕的编码者通常也只是存在的暂时状态，并且是上下文相关的。 例如，我知道Java，但是如果您要求我用C＃开发，我将是一个糟糕的程序员，直到我能够使用可用的语言构造为止，这可能要花一两个星期的时间。

这就是行业出错的地方。 (This is where the industry is getting it wrong.)

Most technical interviews leveraging Leetcode, HackerRank, CoderPad, et. al are testing algorithmic skills first and foremost. They aren’t actually testing knowledge and experience coding, engineering, or using and incorporating technologies into systems, as many believe.

大多数技术面试都是利用Leetcode，HackerRank，CoderPad等进行的。 首先是测试算法技能。 许多人认为，他们实际上并没有测试知识和经验的编码，工程或使用技术并将其整合到系统中。

These algorithmic aspects are where most people trip up in their interviews. If they can’t derive the algorithm, they can’t convert it into machine instructions, even if they could have coded it well had they known the algorithm. You can tell this is happening when the candidate seems to be writing tons of code perfectly, but can’t seem to get the write output.

这些算法方面是大多数人在面试中脱颖而出的地方。 如果他们不能导出算法，就不能将其转换为机器指令，即使他们知道算法就可以很好地进行编码。 您可以看出，当候选人似乎在完美地编写大量代码，但似乎无法获得写入输出时，这种情况正在发生。

It makes sense to use algorithmic questions if you are hiring people to develop algorithms like Google, but I guarantee most companies are not. I’d personally reject any code where a developer on my team tried to write their own sorting algorithm instead of calling Array.sort().

如果您要雇用人员来开发Google之类的算法，则可以使用算法问题，但是我保证大多数公司都不会。 我个人拒绝团队中的开发人员尝试编写自己的排序算法而不是调用Array.sort()任何代码。

Companies using these kinds of programming tests then receive a lot of false negatives. They might feel great about having such as high bar, but it is artificial.

然后，使用此类编程测试的公司会收到很多误报。 他们对拥有如此高的门槛可能会感到很好，但这是人为的。

Maybe the candidates aren’t as strong at programming, but are fantastic engineers and coders. You’d never know, because your interview doesn’t even test for engineering skills, and the problem doesn’t give space to demonstrate coding ability until you first solve the problem of the algorithm.

也许候选人在编程方面不那么强，但他们是出色的工程师和编码人员。 您永远不会知道，因为您的面试甚至都没有测试工程技能，并且直到您首先解决算法问题，问题才得以展示。

Want to find out if this is the case for your candidates? Write out the solution sequence in human-readable sentences in your problem description, and see how many more candidates suddenly start passing your test with flying colors.

是否想找到适合您的候选人的情况？ 在您的问题描述中用易于理解的句子写出解决方案的顺序，看看有多少其他应聘者突然开始通过您的考试，而且成绩斐然。

What I found while hiring is that people who end up being excellent engineers often do terribly in the programming tests. They hadn’t been studying how to solve arbitrary problems that have already been solved. They’re not fresh out of their university’s computer science program. They’ve been out in the field building systems. Their algorithmic problem-solving skills may have started to stagnate, because those skillsets are completely separate.

我在招聘时发现，最终成为优秀工程师的人经常在编程测试中做得很糟糕。 他们没有研究如何解决已经解决的任意问题。 他们并非刚从大学的计算机科学专业毕业。 他们已经参与了现场构建系统。 他们的算法解决问题的技能可能已开始停滞不前，因为这些技能集是完全独立的。

工程 (Engineering)

Engineering is the process of identifying and structuring components into a system that accomplishes a goal and fits within a set of constraints within a given context.

工程是将组件标识和组织到一个系统中的过程，该系统可以实现目标并适合给定上下文中的一组约束。

This is the realm of data models, architectures, software designs, interaction structures, data flow management, etc. Engineers ensure your system doesn’t topple over, is secure, can flex and bend to meet changing requirements, and fulfills your business’ operational requirements.

这是数据模型，体系结构，软件设计，交互结构，数据流管理等领域。工程师确保您的系统不会翻倒，安全，可以弯曲和弯曲以满足不断变化的需求并满足您的业务运营需求要求。

自动化在线评估不会对此进行评估吗？ (Don’t automated online assessments evaluate this?)

HackerRank and CoderPad don’t test for this. They simply can’t — at least not yet.

HackerRank和CoderPad对此不进行测试。 他们根本做不到，至少还没有。

Engineering is part art and part science. It’s not something that can be filtered for with a multiple-choice question or demonstrated in a single function you can write in an hour.

工程既是艺术又是科学。 它不是可以用多项选择题过滤掉的东西，也不是可以在一小时内编写的单个函数中演示的东西。

It requires deep understanding of the business and context, analysis, and back-and-forth discussions to identify potential change points and edge cases.

它需要对业务和上下文，分析以及前后讨论进行深入了解，以识别潜在的变更点和边缘情况。

一个坏问题的好例子 (A good example of a bad question)

One question I saw was a multiple-choice question with a 60-second timer that went something like this:

我看到的一个问题是带有60秒计时器的多项选择题，其内容如下：

1. If you had to model users sending messages, which would be best?a. A User table and Message table where Message has a sender_id and receiver_id
b. A Message table where Message has the sender's name and receiver's name.
c. A Message table that has the sender_id and receiver_id, sender_name and receiver_name.
d. A Message table where the message has the name of the sender.

The problem? There is no such thing as an absolute best in engineering. There is only contextually appropriate. Any one of these answers could be a great solution depending on the constraints in the environment, which include business factors like time, cost, and available skill level. They might all even be unfit solutions for the situation at hand.

问题？ 工程上没有绝对最好的东西。 只有上下文合适 。 根据环境的约束，这些答案中的任何一个都可能是一个很好的解决方案，其中包括时间，成本和可用技能水平等商业因素。 它们甚至可能都不是当前情况的合适解决方案。

Solution A was the “correct” answer that the system wanted me to put in, but there’s many scenarios in which it might be a bad decision. What if you had a group chat? Would you want to duplicate every single message to every single person? What if you wanted to send messages to people without a user account?

解决方案A是系统希望我输入的“正确”答案，但是在很多情况下，这可能是一个错误的决定。 如果您有群聊怎么办？ 您想将每条消息复制给每个人吗？ 如果您想向没有用户帐户的人发送消息怎么办？

Solution B can be a good solution in some cases. What if you wanted an anonymous drop-off messaging system, without any tracking? What if the sender and receiver are groups?

在某些情况下， 解决方案B可能是一个很好的解决方案。 如果您想要一个没有任何跟踪的匿名送信系统怎么办？ 如果发送方和接收方是组怎么办？

Solution C can result in duplicate data, but also provides some advantages. If sender name changes are common, and you want a snapshot history of it, storing the name at that moment in time with the message would allow you to fulfill that requirement. Since the data is denormalized, the resulting reads are greatly sped up if performance is a factor.

解决方案C可能导致重复数据，但也提供了一些优点。 如果发件人姓名的更改很常见，并且您需要快照的快照历史记录，那么在该时间与消息一起存储姓名将使您可以满足该要求。 由于数据是非规范化的，因此如果将性能作为一个因素，则会大大加快读取结果的速度。

Solution D might be an acceptable solution in older systems that don’t have the capacity to track users separately from the message, or if you need to track the message in its entirety. If the system is sending/receiving a text message from a single number, and you need to track the contents of what you sent while notifying the recipient, you’d have to add the name to the message or at least some identifier.

解决方案D在较旧的系统中可能是可以接受的解决方案，因为它们没有能力从消息中单独跟踪用户，或者如果您需要整体跟踪消息。 如果系统正在从一个号码发送/接收短信，并且您需要在通知接收者的同时跟踪发送的内容，则必须在邮件中添加名称或至少添加一些标识符。

There’s also a ton of other potential solutions, many that might involve not having tables at all! Document stores are a thing, as is peer-to-peer ephemeral messaging.

还有很多其他潜在的解决方案，其中许多可能根本就没有桌子！ 对等的临时消息传递，文档存储是一回事。

重点 (The point)

The point of this is that the context can change the “correct” answer wildly, and there’s many assumptions baked into even this simple, generic question. Someone who immediately chose A as the correct answer without even considering any of these factors is likely NOT going to be the kind of engineer you’d want.

这样做的目的是，上下文可以疯狂地更改“正确”答案，即使这个简单的通用问题也有很多假设。 立刻选择A作为正确答案而不考虑任何这些因素的人可能就不会成为您想要的那种工程师。

Context is everything, and there is no “best” solution.

背景就是一切，没有“最佳”解决方案。

那么，您如何评价这项技能？ (So, how do you evaluate this skill?)

You identify the signal through:

您可以通过以下方式识别信号：

• Discussions on tradeoffs, factors, decision-making on technical projects, both past and hypothetical.
  讨论技术项目的权衡，因素和决策，既有过去的也有假设的。
• Looking at past work, projects, and experience.
  查看过去的工作，项目和经验。
• Looking for deep understanding of interactions, structure, and fundamentals.
  寻找对相互作用，结构和基本原理的深入理解。
• Discussions about implementations, technology choices, what-ifs, etc.
  关于实现，技术选择，假设条件等的讨论。

This will show you whether they understand the tradeoffs and factors and structures they worked with, and whether they can apply and change their library of knowledge and tools to fit your business context.

这将向您显示他们是否了解权衡因素以及与之合作的因素和结构，以及他们是否可以应用和更改其知识和工具库以适合您的业务环境。

The signal:

信号：

• Do they know how to make effective technical decisions?
  他们知道如何制定有效的技术决策吗？
• Do they know what tools are available to them to best structure the system?
  他们是否知道可以使用哪些工具来最佳地构建系统？

The noise:

噪音：

• It doesn’t show whether people can actually implement the system they talk about.
  它没有显示人们是否可以真正实现他们所谈论的系统。
• It doesn’t show whether the system can be built or provides value in the specific situation.
  它没有显示在特定情况下系统是否可以构建或提供价值。

发展 (Developing)

Developing is the ability to build and iterate on a product or system to accomplish a business outcome.

开发是指在产品或系统上进行构建和迭代以实现业务成果的能力。

Developing is specifically interested in value delivery. An effective developer may use the worst possible technical solution if it means maximizing the amount of value delivered.

开发对价值传递特别感兴趣。 一个有效的开发商可能会使用最糟糕的技术解决方案，如果这意味着最大化所交付的价值。

They’ll respond to customer demand and keep the impact in mind, and ensure that the overall goals of the project are actually completed.

他们将响应客户需求并牢记影响，并确保实际完成项目的总体目标。

The noise:

噪音：

• It doesn’t show whether the candidate can build systems that are easy to maintain or change in the future.
  它没有显示候选人是否可以构建易于维护或将来更改的系统。
• It doesn’t show whether the candidate can build reliable, secure, safe systems.
  它没有显示候选人是否可以构建可靠，安全，安全的系统。
• It doesn’t show whether the candidate can actually implement or solve more difficult technical problems.
  它没有显示候选人是否可以实际实施或解决更棘手的技术问题。

您如何为此聘请？ (How do you hire for this?)

Testing for this involves holistic discussions of problems and solutions. Do they ask questions that keep in mind various groups of stakeholders? Do they think iteratively and incrementally? Do their solutions consider many aspects, not just technical?

为此进行测试涉及对问题和解决方案的全面讨论。 他们是否提出要考虑各利益相关方群体的问题？ 他们会反复迭代地思考吗？ 他们的解决方案是否考虑了很多方面，而不仅仅是技术方面？

Past experience here is really visible too — do they have experience building and delivering things into the hands of users? Previous startup or consultancy experience can be a part of a successful track record.

过去的经验在这里也很明显-他们是否有构建和交付东西到用户手中的经验？ 以前的启动或咨询经验可以成为成功记录的一部分。

Note also that there is significant overlap in product management skills here.

还要注意，这里的产品管理技能有很多重叠之处。

招聘 (Hiring)

Let’s say we are looking for someone to build us a software system that allows people to log in and do stuff.

假设我们正在寻找可以为我们构建一个软件系统的软件系统，该软件系统允许人们登录并执行操作。

我在找什么 (What am I looking for?)

I’m not going to look for a fantastic coder. The scope of coding as it pertains to things like HackerRank is too small for what I am trying to do. I need people who can think holistically and act far beyond a known input and output for a single function. That’s engineering, not coding.

我不会寻找出色的编码器。 对于像HackerRank这样的事情，编码的范围对于我正在尝试的事情来说太小了。 我需要能够全面思考并采取行动的人，远远超出单个功能的已知输入和输出。 那是工程，而不是编码。

I’m not going to look for a great programmer. Problems like authentication, interfaces, dashboards, etc. have already been solved. I’m not solving novel problems, I’m structuring, re-organizing, and integrating parts to combine a set of old solutions in a new way that provides value.

我不会寻找优秀的程序员。 身份验证，界面，仪表板等问题已经解决。 我不是在解决新颖的问题，而是在构造，重新组织和集成部件，以一种能够提供价值的新方式组合一组旧解决方案。

I’m going to look for a software engineer with some software development skills and enough coding chops to build the idea they came up with.

我将寻找具有一些软件开发技能和足够的代码编写经验的软件工程师 ，以建立他们想到的想法。

够了吗 (What’s enough?)

Coding — how much is just enough? For this situation, it would be positive answers to the following:

编码-多少就足够了？ 对于这种情况，将是以下方面的肯定答案：

• Does the candidate know what variables, methods, classes, etc. are?
  候选人是否知道什么是变量，方法，类等？
• Is the andidate aware of the standard and common libraries?
  候选人知道标准库和通用库吗？
• Does the candidate know how to install and use dependencies?
  候选人是否知道如何安装和使用依赖项？
• Is the candidate familiar with the ecosystem?
  候选人是否熟悉生态系统？

These are all things you can get from a 5 minute conversation, or a brief glance at a personal project.

只需5分钟的交谈，或者简短地浏览一下个人项目，您便可以获取所有这些内容。

Development — how much is enough?

开发 -多少就足够了？

• Does the candidate know how to track and interpret a user’s flow through the system through analytics services or interaction events?
  候选人是否知道如何通过分析服务或交互事件来跟踪和解释用户在系统中的流动？
• Does the candidate know how to refine ambiguous asks down into a small, minimum deliverable you can use to validate the solution?
  候选人是否知道如何将模棱两可的要求细化为可用于验证解决方案的最小，最小交付量？
• Does the candidate know how to understand the intent of the customer and mold the technology in the direction of their overall goals?
  候选人是否知道如何理解客户的意图并朝着他们的总体目标方向发展技术？

These are things you can find by asking the candidate about how they approach thinking about the product, user, and software.

您可以通过询问应聘者有关产品，用户和软件的思考方式来找到这些东西。

Engineering — how much is enough?

工程学 -多少钱足够？

• Does the candidate know how to optimize a system, and what levers are available to pull for different constraints and use cases?
  候选人是否知道如何优化系统，以及可以使用哪些杠杆来应对不同的约束和用例？
• Does the candidate know how to model data in a way that can absorb change and perform effectively under multiple conditions?
  候选人是否知道如何以能够吸收变化并在多种条件下有效执行的方式对数据建模？
• Does the candidate know how to structure your code in a way that makes things maintainable and extendable?
  候选人是否知道如何以使事情可维护和可扩展的方式来构造代码？

Programming — how much is enough?

编程 -多少钱足够？

• Does the candidate know the ways you can leverage common data structures like lists and maps?
  候选人是否知道可以利用常见数据结构(如列表和地图)的方法？
• Does the candidate know how to read an algorithm and identify is growth rate and runtime efficiency?
  候选人是否知道如何读取算法并确定增长率和运行时效率？

You’ll notice that’s not much. Most performance related items are constrained by the architecture and system design, not by the algorithm. Even if it was, it would be easily resolved by some straightforward, basic algorithmic practices that don’t require significant programming knowledge.

您会注意到这并不多。 大多数与性能相关的项目都受体系结构和系统设计的约束，而不是受算法的约束。 即使是这样，也可以通过一些不需要大量编程知识的简单，基本的算法实践轻松解决该问题。

正确组织评估 (Structure your assessments correctly)

If you’re hiring a coder, you can use simple, well-defined problems. You can also do take-home projects, or real-time refactoring questions (provided there is enough “meat” to refactor).

如果您要雇用编码员，则可以使用简单的，定义明确的问题。 您还可以进行实地项目或实时重构问题(只要有足够的“肉”进行重构)。

If you’re hiring for a programmer, continue doing the Leetcode, HackerRank-style questions.

如果您正在招聘程序员，请继续进行Leetcode和HackerRank风格的问题。

If you’re hiring an engineer, you start entering the realm of conversational interviews. How candidates think about factors, tradeoffs, holistic thinking, and decision-making can only be discovered by interacting with them candidate.

如果您正在招聘工程师，那么您将开始进入对话式访谈的领域。 候选人如何考虑因素，权衡，整体思维和决策，只有通过与候选人互动才能发现。

If you’re hiring a developer — look at their past work, or talk to them.

如果您正在雇用开发人员，请查看他们过去的工作，或与他们交谈。

招聘团队 (Hiring for the team)

The final aspect of all this is that you need to hire for what the team needs.

所有这一切的最后方面是，您需要根据团队的需要来雇用。

Great teams are balanced as a whole, with people who work well together and have strengths and weaknesses overlapping. Synergy is a common buzzword in the business world, but for good reason: great teams are greater than the sum of their parts.

优秀的团队整体上是平衡的，相互配合的团队成员彼此协作，优势与劣势重叠。 在企业界，协同作用是一个常见的流行语，但有充分的理由：优秀的团队比其各个部门的总和还重要。

If your team is full of architects or engineers, you’ll likely want to balance it out with coders who can execute and crank out features.

如果您的团队中充满了架构师或工程师，那么您可能希望与可以执行和扩展功能的编码人员保持平衡。

If your team is full of coders who crank out features, you’ll want to hire an engineer to balance things out and help provide long-term stability and mature technical capabilities over time.

如果您的团队中充满了开发各种功能的编码人员，那么您将需要雇用一名工程师来平衡各种情况，并随着时间的推移提供长期的稳定性和成熟的技术能力。

If your team is full of people who build things, but performance is a concern, a programmer can help come in and optimize things.

如果您的团队中充满了构建事物的人员，但是性能是一个问题，那么程序员可以帮助您进行优化。

If your team is full of builders, or you need someone to bootstrap an idea and iterate on it in the interests of the business, hire a developer.

如果您的团队挤满了建设者，或者您需要某人来引导一个构想并为了企业的利益对其进行迭代，请雇用开发者。

雇用权利 (Hire right)

Ultimately, effective technical interviews comes down to knowing what you’re hiring for. Without that, you can’t actually ask the questions that enable you to identify whether the candidate has the right skills.

归根结底，有效的技术面试归结为了解您的招聘目标。 否则，您将无法提出真正的问题，从而无法确定候选人是否具有正确的技能。

Don’t waste time hiring for the wrong skills. Learn what you and your team need, and then structure your interview to hire for the right skills.

不要浪费时间雇用错误的技能。 了解您和您的团队的需求，然后安排面试以雇用合适的技能。