David Hansson是Ruby on Rails语言的发明者，他在一条推特信息中坦承，他无法在白板上写出冒泡排序算法。David总是在网上搜代码：

他的几个同事也都支持他的观点：

这个话题一次又一次地出现在不同的地方，正好我自己也有类似的经历：这周以及之前的几周，我参加了几家公司的技术面试，所以怎样准备面试这个问题现在对我来说是最重要的。

面试官会经常性地问到包括算法在内的所谓编程语言基础知识（于我，那就是JavaScript啦），这已经不是秘密了。任何平均水平的（对“平均水平”这个词语的定义，人们经常有一些讨论，但是我坚持使用“平均水平”这个词，而不引用别人的定义）工程师都面临两大难题。但首先，我想先稍微解释一下“平均水平”这个词语：一位普通的开发者在商业开发中，应使用其领域最先进的技术方案（例如，最好的算法），这是开发者的责任所在。但是，一位普通的、平均水平的开发者是否需要记住最好算法代码上的某些实现，这仍然是个有争议的话题。

所以，两大难题出现了：

1）通常在面试中，面试官会给你一张纸，一支铅笔，或者一个白板和一只记号笔。在真实的开发环境中，我们使用大量的工具，减少一些常规的开发任务：比如，代码自动补全工具。所以，你需要考虑到面试中的压力环境，也许你并不总是能够凭空写出来精确的、语法正确的代码。

2）第二大难题是数字化时代的基本特点所带来的后果。我会用一个小例子来说明。

过去十几年，我一直在学习汉语。学习汉语最主要的难点在于记住这些汉字的象形写法。这和我们欧洲的语言不同，我们已经习惯了字母表式的语言，而汉语，即使你知道一个汉字的发音，也不一定能帮助你准确地写出这个汉字。现代化的电子助手——手机应用程序——通过输入拼音能够降低写出汉字的难度，因为它能让你快速找到你需要的汉字。

我时不时地会去想人们在过去是怎样做的。那时候，每次为了找到某个汉字的正确拼写方式，最多就只能是去翻一翻厚重的汉语字典。这对于他们记忆象形文字的能力，对于他们反复记忆学习所花费的时间等等，都提出了完全不同的挑战。

简而言之，粗略地说，我们大脑的部分功能会不由自主地被带到外部世界来，被带出来的并非记忆本身，而是，比如说对记忆构建的哈希表，从这张哈希表我们可以快速找到大量的、在加速前进的职业生涯中所获取到的知识。

而对于编程知识来说，情况一模一样。坦率的说，每个人都会承认：他迟早都会忘记一些最基本的东西。例如，每个优秀的JavaScript课程都会介绍OOP的概念，讲解继承这个主题，如何创建“类”等等。但是，在现代化项目里，特别是那些基于框架的项目，程序员并不经常直接使用OOP的特性，其使用频率并不像OOP在面试中被问到的那样频繁（面试中几乎总是会被问到）。所以自然地，你实际记住了的和你自己以为记住的（通常却被忘得一干二净），这两者之间会产生冲突。

换句话说，成功的程序员能够了解从哪里以及怎样找到应对当前话题的知识，他们每天都写很多代码，甚至能够解决很多复杂的问题（例如，创建RoR），但却会在面试中挂掉，不能清晰明了地解答面试题目，只能对着看似“幼稚”的面试任务发呆。那么问题来了，这样的面试究竟是在定义什么？

顺便说一下，一些西方企业就这一主题（http://blog.interviewing.io/you-cant-fix-diversity-in-tech-without-fixing-the-technical-interview/）做了一些研究。

结论是：“它无法界定得那么清楚。”当然，任何平均水平的雇主首先想要在候选人身上看到的是其具备基础知识。由于我们的整个文化主要是写的文化，雇主也就有权要求候选人把他所知道的知识写在纸上。但是，对于编程（很可能在其他需要很多脑力的领域也是这样），一个简单的事实正变得显而易见：一个人不借助特别的线索和提示等，是很难使他所知道的所有知识在脑中重现。相反，让候选人解决一个实际的问题，综合评估其寻求解决方案的能力和技能，而并非只是测试他们是否记住了某些代码片段，这会让面试更有效果。

原文链接：
Programmers can’t write algorithms without help: once more about the interview

创作场景

Ruby on Rails 之父自认为写不了冒泡排序