Interview questions

如何提高面试的效率，是每个面试者和应聘者都应该认真研究的问题，只有双方良好地沟通，才能保证双赢的结果。所谓双赢，并非一定指确定双方的雇佣关系，也包含避免公司找到不合适的人或应聘者加入不适合自己的公司。

这里有一些面试问题，大家可以做为参考，试着回答一下，或者想想自己希望听到怎样的回答。其中我最喜欢的两个问题是：

• What are your long-term goals?
• What book is currently on your nightstand?

即使不是为了面试，每隔一段时间回答一下这两个问题也是非常有好处的。

然而，真正促使我写这篇blog的是文章标题所引用的那个问题——"Why should I hire you?"

这个问题过于狂妄自大了。招聘是一个双向选择的过程，公司在选择员工，员工也在选择公司，面试是一个相互交流、增进了解的过程，如果公司可以询问"Why should I hire you?"，那么应聘者是否也可以问"Why should I join you?"。没有任何一个公司可以强势到要别人非加入不可，也没有任何个人能够让公司非招聘不可，所以，无论哪一方提出这样的问题都是不合适的，因为被问者总是可以说：“就算你愿意，我还未必肯呢！”对于公司来说，发掘合适的人才是自己的事情，应聘者不会，也不可能站在公司的立场上来思考、回答这样的问题。一般来说，如果没有亲身经历，很难了解在一个公司里工作是怎么回事，更不要说知道这个公司需要怎样的人才，即便是Google这样曝光率极高的公司，对外人来说仍然显得十分神秘。因此，这样的问题根本就无从回答。应聘者所能做的也就是讲讲自己最擅长的事，然而如果面试者真的是想了解应聘者的能力，完全可以问的更直接些，而不是选择这个貌似很有创意，实则极其愚蠢的问题。

没有人愿意加入一个狂妄自大的公司，也没有人愿意与狂妄自大的人一起工作。所以，请千万不要问这个问题，即便是用来凑数。

Scroll screen, not cursor, in emacs

曾经被问道如何滚动emacs的屏幕而不动光标，奈何本人能力有限，无法回答。

最近，一位匿名的朋友贴出代码，参见这里。不知道这位朋友和提出问题的是否为同一人，无论如何，非常感谢！

I enjoy learning programming languages

“学习程序设计语言”是一种很笼统的说法，实际上要学的东西多种多样。

首先是学习语法，即怎样写出一个合法的程序来。学习语法也有两层境界，初级选手就是希望能写出一个顺利通过编译并执行（或解释执行）的程序，然而由于语法的各个部分之间的组合有多种可能，初级选手往往不能分辨其优劣，所以写出的程序质量难以保证。高手通过学习语法基本就能写出高质量的程序，因为他们掌握了这些语法背后的理论（比如closure, higher order function, dynamic scope等等），知道它们为什么被设计成这样，以及应该怎样使用。

程序的质量往往是指程序的结构，一个质量高的程序未必是个有用的程序。所以，在学习一门程序设计语言时还要学另一种东西——库。记得在读本科的时候，有些同学在没有学过C++的情况下就去学MFC，竟也写出程序来。其实我现在写Perl程序也差不多，几个CPAN上的module拿过来组装一下，居然也写成 些实用的程序，只是在编辑器里打开一看，其质量实在不敢恭维。学会使用库对找工作是相当重要的，因为我们很难拿出自己的代码告诉对方其质量是如何之高（即便拿得出，对方也未必懂得欣赏），通常都是列出实现过功能。实际上，绝大多数公司和老板也仅仅关心程序员能做出哪些东西，而不关心其质量如何。

每种语言都有自己的价值观和理论基础。我的目的，是通过学习不同类型的语言，学习从不同的视角、用不同的思维方式看问题，从而为不同性质的问题选择合适的工具，以便高效地解决问题。我这样的学习对提高程序质量恐怕没有什么帮助，但是对于快速完成那些质量不重要、不需要维护的程序（即那些以解决一次性问题为目的的程序）来说非常有帮助。正是许许多多这样的小程序或小脚本，将我们从烦琐的“体力劳动”中解放出来，即提高的效率又愉悦了身心，缺点是简历上写不出来。不过，我们可以用节省下来的时间完成些能够打动人心的东西。

正好回答Sucha的疑问：我是想通过一种不同于学习库或API的方式来提高自己写出实用程序的效率。

一个实用的程序要胜过一万个华而不实的程序，然而，能够写出实用程序的程序员实在太多了，只有不断提成程序质量才能使自己与一般程序员区分开来。当然，对于无需维护的程序来说质量毫无意义，这也是Perl哲学的一部分。然而，一个需要维护的程序，如果质量不能保证，维护的代价是相当大的。当然，质量好的程序 未必容易维护，这还要取决于维护程序的程序员的水平。一个水平不够的程序员是无法欣赏、也无法利用高质量的程序的。可见，“以人为本”不是一句空话。

所以，尽管学习的终极目标是写出高质量的程序，然而前途是光明的，道路是曲折的，我们还是先写出实用的程序保住饭碗，保证生活质量，再来谈程序质量吧。

Learn new programming language - another try

真正认真学过的程序设计语言有两个：C++和Perl。学习方式都很简单：读遍当时市面上能找到的名著，然后写代码。C++的书多是在学校里读的，当时全国上下掀起一片学习C++的热潮，我也没落下。只是书读得多，代码却写得少，很担心自己眼高手低，于是在做毕业设计的时候拼命实践书上的知识。幸好工作后的项目是用C++实现的，这么多年就这样实践着，只是读书的兴趣全无，反正也用不上。学习Perl应该是从2004年开始的，和学C++不同的是，这回是边看书边写程序，加上工作后读书的时间本就有限，所以到现在还有几本名著被打在冷宫，比如Perl Cookbook和Pro Perl Parsing。

其实，我很喜欢尝试学习新的程序设计语言，但是学习Ruby、Scheme、Javascript、以及Emacs Lisp都半途而废了，关键原因是无法做到学而时习之，书读得断断续续，程序也没机会写，时间拖得久了热情也就没了。

这一次又没忍住，成天看着“Lisp”、“Haskell”这些词儿在programming.reddit.com上蹦出来，甚向往之，几经权衡，还是选了Common Lisp。主要理由如下：

• 两本名著——Practical Common Lisp和On Lisp——都有电子版；
• 我手上还有著名的Paradigms of Artificial Intelligence Programming，作者Peter Norvig；
• 学好Common Lisp之后，Emacs Lisp可以更快上手。通过读Emacs Lisp Reference Manual来学Emacs Lisp简直不是人受的；
• 学好Common Lisp之后，可以更好地理解Higher-Order Perl，用好Perl。

Practical Common Lisp已经读了6章，谈两点感受，

1. 书写得很好，很好读，毕竟得过Productivity Award at the 16th Annual Jolt Product Excellence Awards！
2. 稍嫌罗嗦。:-)

也许这本书主要面向没有任何Lisp经验的人，某些理念对于没有接触过的人来说相当晦涩，因此需要反复解释。而我在读过《程序设计语言——实践之路》，甚至硬啃过Emacs Lisp Reference Manual的前半部分之后，已经掌握了基本的语法和概念，关键是不会用，不知道怎么写出一个程序来。幸好Practical Common Lisp有相当多的章节是程序实例，只是放在后面而已，暂时没有读到。期待中……

顺便说说我的学习方式。我属于三分钟热血的那种，兴致高的时候什么都想学，兴致没了也就不学了，真是“乘兴而来，兴尽而返”。所以我是很不喜欢学校的。说不好究竟是我这种方式浪费的时间多，还是在学校里学习浪费的时间多，但至少按照自己的方式学习，心情很好，不会觉得累。心情好，就愿意学更多的东西，知识相互关联的可能性也就越大，收获自然越多。

Two powerful emacs packages

虽说已工作四年多，暑假后遗症仍如期而至，整日懒洋洋，提不起精神。加上不久前病了一场，休息了大半周，如今仍“自欺”还在恢复，哑铃也不举了。

懒散归懒散，也并非一事无成，看到Emacs Muse 3.03发布了，值得称道的是终于支持嵌套列表了，也就是说，可以写出这样的东西了：

• 先这样
• 开始
• 结束
• 再那样

其实早就知道Emacs Muse，就是因为其不支持嵌套列表，所以一直没用。也许用到嵌套列表的情况并不多，但没有它总觉得这软件写得不专业。正是基于这种古怪的、不可取的想法，始终坚持手写HTML。现在支持了，我也没了借口，便再次试用了下，感觉真得不错，以后再写点啥，就全靠它了。那篇翻译——《评判人的两种目的》—— 就是用Emacs Muse写好后生成的。

之后又试了Org-Mode，Emacs 22.1缺省安装的一个用来做日程管理、项目管理和ToDo列表的mode。这个东西不错，比之Google Calendar和remember the milk，更像我想要的东西。只不过Org-Mode功能多，还真得学一会儿，现在只用些简单的功能，就像OrgTutorial中提到的那样。Emacs Muse加Planner也可以实现类似的功能，不过捆绑的总是有些优势，Planner只好日后再说了。:-(

上半年Perl用得多些，如今也换换口味，免得审美疲劳，呵呵。