Original Post:Surviving an interview with me
Nicholas C. Zakas,2007年3月27日
翻译完成:2010年1月9日,最后更新:2010年1月10日

早就打算写这篇文章了,但时至今日才决定动笔。如果你投了简历,那么应该会在面试你的人名单里找到我的名字。你现在就有点紧张了,(好啦,别不好意思)面试总会让人感觉有点不舒服。作为面试官,我其实并不算难对付,但如果你想在我们谈话之后让我放你过关,你确实得做一些必要的准备。

  • 回答问题。我问你一个问题,你必须要回答它。我遇到应聘者在回答我问题时顾左右而言他的情况太多了。我知道你会有些紧张,说几句不着边际的话可能有助于缓解,但请你不要喋喋不休,要赶快回到正题上来。我不想知道你的宠物猫最近又出了什么新状况,我只想听到你的回答。假如你没有听明白我问的是什么,可以要求我再解释一下,重复几遍问题或者换一种问法,对我而言没有什么。
  • 告诉我你不知道什么。如果我问到了你不知道的问题,一定要告诉我。我不认为你的大脑里可以装得下百科全书。在知道了你不知道什么以后,我对你的评估才会更加公平。问题仍然要回答,但我会给你一些提示,同时也可以考察一下你解决问题的能力。
  • 不要放弃。在我面试你的过程中,不要总想着放弃。如果你被我前面的话不幸言中,那么你可能会面对一个让你不知所措的问题,而且你也告诉我你答不上来了。此时此刻,千万不要打退堂鼓!我会尽力提醒你,让你找到正确答案;因此不要随随便便打断我说:“我真的不知道。”在我们这个行业,你经常会遇到没有现成解决方案的挑战,到时候你会轻易放弃吗?我必须知道你具备解决问题的能力,而不是遇到一点挫折就轻言放弃。
  • 不用担心怪问题。有些公司的确有吓唬应聘者的传统,他们会让你回答一些类似脑筋急转弯似的稀奇古怪的问题。对那种面试方式,我不敢苟同。我提的所有问题都有答案,而且绝大多数还不止有一个正确答案;我保证一个怪问题也不会问你。因为这样既会让你难堪,又对我毫无意义。你大可放心,我的每个问题都至少会有一个正确答案。
  • 自圆其说。如果你提到了某个解决方案或者强调自己掌握了某方面知识,请做好进一步讨论它的准备。假设我问了一个问题,你在回答这个问题时提到:“对,因为IE不支持CSS3……”然后,你最好能够跟我讨论一下要是IE支持CSS3你会怎么办。
  • 不要说自己是专家。大多数面试中可能都需要注意这一条,但我对这一条尤其敏感。我从来不会把应聘者划分为三六九等,因此你也不必告诉我你属于哪个等级。一旦你声明自己已经跻身“专家”的行列,我怕有些问题会让你下不来台。我确实见过自称专家而又确实是专家的人。但是,我认为真正的专家不会自己说出来,而是会做给你看。
  • 不要靠卖弄赚取我的好印象。如果我想知道什么,我会问。我知道在面试时需要了解哪些信息,只要一听到有人说“想不想看一个绝妙的技巧?”或者其他类似的话,我都有一种立即中断面试的冲动。所以,请尽力回答好我的问题即可。
  • 充满激情。如果你想得到跟我一起工作的机会,请给我一个愿意跟你共事的理由。最好的理由就是要有激情,把你主动、积极学习的热情展示出来。希望你能谈一谈产品、公司,以及为什么想得到这份工作。尤其要注意最后一点,我不想听你说你当前的工作如何如何讨厌。当然,可以解释一下为什么现在或者过去没有从事你喜欢的工作,但你一定要告诉我你对自己今后的成长有何打算,还有为什么你应聘的这个职位能够有助于你的成长。

没错,我确实希望将来有可能被我面试的所有人都看到这篇文章。我希望你能在我面试你时表现得非常好,真的,确实如此。说来也简单,只要你留意上述这些常见的问题,并且原原本本地展示你自己就足够了。说不定哪一天,你就会跟我坐到同一间办公室里了。

注意,My Yahoo!团队正在招聘呢。如果你是一位有才华的软件工程师,又对创造价值和Yahoo!公司充满激情,请跟我联系,咱们谈谈。

延伸阅读

Nicholas C. Zakas的书

Professional JavaScript for Web Developers, 2nd Edition Professional Ajax, 2nd Edition Even Faster Web Sites

Original Post:Interviewing the front-end engineer
Nicholas C. Zakas,2010年1月5日
翻译完成:2010年1月7日,最后更新:2010年1月10日

面试前端工程师对我来说是一件非常有意思的事,因为面试过程很大程度上也是自我提升的过程。无论大公司还是小公司,之所以在如何招聘到真正有能力的前端工程师方面会遇到同样的问题,就是因为负责招聘的那些人不知道自己公司需要什么样的人,结果问问题时也问不到点子上。经过这几年在行业里的摸索,我总结出了自己的一套很有效的面试前端工程的方法。

有的应聘者说我不好对付,但留给他们这样的印象也并非我所愿。我觉得之所以他们说我不好对付,主要是因为我问他们问题时问得太细了。以前我曾专门写过一些东西,告诉应聘者怎么才能通过我的面试以及怎样才能成为优秀的前端工程师应该具备什么样的素质,而我的面试可以说完全是按照那两篇文章的标准进行的。我不会问一些特别偏门的问题,也不认为出几道逻辑题就能考出人的真实水平。我唯一的想法就是确定你能否胜任我们要招的这个职位。为此,我需要简单地考察如下几个方面。

基本知识

我们生活在互联网时代,你想知道的任何事情几乎都能在15分钟内找到相关信息。可是,能找到信息并不等于你会使用它。我认为所有前端工程师至少都应该掌握某些基本的知识,才能有效地完成自己的工作。如果一遇到问题,就停下工作上网四处搜索解决方案,怎么可能保证按期完成工作呢?听听,还有谁在说“我不知道,但我可以上网搜到。”请这些同学把手举起来,让大家认识一下(immediately raises a flag for me.)。下面我列出一些基本的知识点,这些都是我认为一名前端工程师(无论工作年头长短)在没有任何外来帮助的情况下就应该知道的。

  • DOM结构——两个节点之间可能存在哪些关系以及如何在节点之间任意移动。
  • DOM操作——怎样添加、移除、移动、复制、创建和查找节点。
  • 事件——怎样使用事件以及IE和DOM事件模型之间存在哪些主要差别。
  • XMLHttpRequest——这是什么、怎样完整地执行一次GET请求、怎样检测错误。
  • 严格模式与混杂模式——如何触发这两种模式,区分它们有何意义。
  • 盒模型——外边距、内边距和边框之间的关系,IE < 8中的盒模型有什么不同。
  • 块级元素与行内元素——怎么用CSS控制它们、它们怎样影响周围的元素以及你觉得应该如何定义它们的样式。
  • 浮动元素——怎么使用它们、它们有什么问题以及怎么解决这些问题。
  • HTML与XHTML——二者有什么区别,你觉得应该使用哪一个并说出理由。
  • JSON——它是什么、为什么应该使用它、到底该怎么使用它,说出实现细节来。

重申一下,上述这些知识点都应该是你“想都不用想”就知道的东西。我一开始问的所有问题都是想摸清你对所有这些领域知识的掌握程度。虽然上面列出的这些知识点并没有面面俱到,但我觉得你至少应该掌握这些,才有可能跟我坐到一间办公室里来。

少量提问

我非常赞同面试者问的问题越少越好。反复问应聘者各种问题既不公平,也很无聊。我在任何一次面试中,通常只问三个大问题,但每个问题又会涉及我所能想到的多个方面。回答每个大问题一般要经过几个步骤,这样我就可以在每个步骤中穿插着问一些小问题。比如说: 查看全文 »

函数声明与函数表达式的有什么区别?
命名函数表达式的语义及其适用场景有哪些?
JScript、WebKit在实现命名函数表达式时“创造”了哪些bug?
SpiderMonkey在实现命名函数表达式是如何对规范“言听计从”的?

请看
命名函数表达式探秘

原文链接:http://yura.thinkweb2.com/named-function-expressions/
本文链接:http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html

Table of Contents

  1. 前言
  2. 函数表达式与函数声明
  3. 函数语句
  4. 命名函数表达式
  5. 调试器中的函数名
  6. JScript的bug
  7. JScript的内存管理
  8. 测试
  9. Safari中存在的bug
  10. SpiderMonkey的怪癖
  11. 解决方案
  12. 替代方案
  13. WebKit的displayName
  14. 对未来的思考
  15. 致谢

今天抽时间专门研究了一番仿真器(emulator)和模拟器(simulator),分析过程就不写了,下面直接给出结论;有不明白的地方,可以再看参考文献和网络词典及维基的释义。

仿真器,指的是几乎能够百分之百地模拟某硬件或软件系统的全部特性、行为的装置或程序。
模拟器,指的是仿照真实的硬件、软件、环境、条件,能够在某种程度上再现这些硬件、软件、环境、条件的装置或程序。

仿真是尽可能做到全方位的模拟,而且力求逼真,有点欲将原型或模仿对象取而代之的味道。仿真更具体,接近实物(也有说接近硬件的,但肯定不局限于硬件)。
模拟只是表面上做做样子,不会有真实的过程发生;但能够给出反馈,多用于研究和培训。模拟更抽象,侧重建模

当然,也会存在模拟器与原型的近似程度堪与仿真器媲美的情况,但它们的区别还是十分明显的,那就是模拟不够“真实”,而仿真非常接近“真实”。

在参考文献中“记性不好,所以写写”的原话基础上稍作修改,可以说:

如果原型是一个人,那么仿真就是克隆一个新人(这个人的言行举止与原型几乎一模一样),模拟就是把这个人生活中的某一段录成视频(能够据以建模)。

参考文献

1.海之雁 《仿真专业词义辨析之一——模拟与仿真
2.记性不好,所以写写《Simulation & Emulation
3. 丁刚 《详述软件开发中模拟器与仿真器的区别查看全文 »

原文地址:http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html

看来(根据一位专家的说法是这样,不过还是感觉有点言不由衷),JavaScript最后真的流行起来了

[此处是youtub.com中一段视频,可惜被"墙"了]

对我这个从小就呆头呆脑的人来说,这段视频像是咒语又像是玩笑。(这要看你是否跟我站在了相同的立场上:绿壳鸡蛋不就流行过吗?)

布兰登·艾奇深得他那尖脑壳老板的信任,Navigator浏览器应该有自己的脚本语言,只有开发一门新语言才可行,必须在短时间内设计和实现这门语言,现有的任何语言都不能充当该角色。

我搞不清楚为什么道格(Doug)要编故事。他并不在网景公司。他亲耳听到过我回忆JavaScript诞生的经过,我在Ajax大会的发言中也讲过了。难道是想混淆视听,想在Web开发人员中掀起一股提前讨论MicroHoo C#语言的风潮?

谁知道呢,要计较这些就没完了。不过,鉴于本周是我参与创立的mozilla.org 10周年,我打算讲一点历史。

正如我多次重申过的,而且Netscape的其他人也可以证明,我是因为Netscape要在浏览器中“实现Scheme”才被招聘进公司的。当时,至少负责客户端技术的汤姆·帕坎(Tom Paguin)迈克尔·托伊(Michael Toy)瑞克·谢尔(Rick Schell),以及一个叫马克·安德森(Marc Andreessen)的家伙认为Netscape应该在HTML中嵌入一种语言,一种源程序式的编程语言。而我这个新人要去说服“尖脑壳”的老板几乎是不可能的——实际上更多的则是他们在向我解释问题。

到底是不是要基于Scheme并没有定论,但Scheme确实是吸引我加入Netscape的一个原因。在此之前,我在SGI公司期间,尼克·汤普森(Nick Thompson)引导我学习了SICP(Structure and Interpretation of Computer Programs《计算机程序的构造和解释》)。

当时真正需要的是一种有说服力的概念验证,也就是一个演示程序。在我交付演示程序之后,这个程序在极短的时间内就变为了既成事实。

没错,在加入Netscape后不久,我被调出服务器团队——由于人员不足,我在这个团队干了一段时间,在那里与麦库尔·吐温斯(McCool Twins)阿瑞·卢奥托嫩(Ari Luotonen)有了一段时间不长但很快乐的合作;1995年下半年,阿瑞和我创建了PAC(Proxy Auto Config,代理自动配置)——的时候,Oak语言已经改名为Java,而Netscape正与Sun协商将该语言包含在Navigator中。

Netscape公司内部争论的最大焦点变成了:“为什么要包含两种语言?为什么不只用Java?”得到的回答是:必须有两种语言分别面向编程圣殿中的两类最不可能走到一块的开发人员:组件开发人员——这类人使用C++或(我们希望的)Java和脚本开发人员(爱好者或专业人员)——这类人编写直接嵌入在HTML中的代码。

至于是否使用已有的语言,而不发明一门新语言,也不是我说了算的。上峰的“军令”就是这门语言必须“看起来像Java”。这样,不仅排除了Perl、Python和Tcl,也排除了Scheme。后来,1996年,约翰·奥斯特豪特(John Ousterhout)前来推广TK时,还曾因Tcl错过机会而惋惜过。

谈不上自鸣得意,但我确实为自己吸收了Scheme式的一类函数和Self式的原型(尽管不那么主流)而感到高兴。至于Java的影响,特别是Date的Y2K bug和原始类型与对象类型(如string与String)差异的影响则是非常不幸的。

时光倒转回1995年春天:我记得在此期间见到了比尔·乔伊(Bill Joy),我和他讨论了垃圾收集的细节(card marking for efficient write barriers)。比尔一上来就完全理解了我们所说的一门易用的“脚本语言”与Java的关系,他还拿微软平台的VB与C++之间的关系作类比。据我所知,比尔是我们在Sun公司的支持者。

基普·希克曼(Kipp Hickman)和我在1995年4到5月间研究了Java,基普也开始写他自己的JVM。他和我编写了NSPR的第一个版本,作为他的JVM之下的可移植层。而我在5月中上旬创建Mocha的原型时,也将该版本用作了相同的目的。

比尔说服我们放弃基普的JVM,因为它会导致与Sun的JVM中的bug无法兼容(在那个时候可谓智慧的预言)。而此时此刻,Mocha已经通过在Netscapte Navigator 2.0(的初期测试版)中的快速原型和嵌入证明它自己。

除此之外,应该说都是对历史的歪曲和调侃。JS在客户端打败了Java,只有Flash能与其竞争,而Flash又支持JS的一个衍生品——ActionScript

现在再回到流行的问题上。其实谈不谈这个问题都无所谓。然而,那些散布于互联网的流行的Ajax库,却经常以被掰碎了、压扁了,然后再以链接形式挑出来的纯文本的形式存在。难道不可以共享吗?

有一种想法——受到了不少人的质疑,最近一次发出质疑声音的人是道格——在可能将会非常长寿的script标签属性中嵌入“神秘的散列码”(crypto-hashes)。这是个好主意吗?

恐怕不是。一方面因为“神秘的散列码”理论上的完备性问题,另一方面则因为其广为人知的药饵攻击(poisoning attacks)。

还有一个主意倒是不错,这个主意我是先从罗布·塞尔(Rob Sayre)那里听说的:通过HTML5中script标签的share属性支持一种可选的“公认的URL”:
<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js”
shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”>
</script>

如果浏览器首先下载了共享的URL,而且根据HTTP的缓存规则它依然有效,那么就可以使用缓存(及预编译)的脚本,而不必从src属性指定的URL中下载。

这就避免了散列药饵的问题。这个方案只要求内容作者保证src属性指向的文件与share属性指定的这个库的公认(或流行)的版本相同即可。不过当然,我们必须信得过相应的DNS。(Ulp.)

这个方案可以避免在script标签属性值中嵌入不可预测的散列码。

欢迎大家就此问题给我留言。

好了,这次真的回到JavaScript流行的问题上了。我们都知道有些Ajax库的确流行。那JavaScript流行吗?很难说。有些Ajax开发人员表示(也证明)了对它的喜爱。但也有很多人骂它,也骂我。我依然认为JavaScript是C和Self草草结合的结果(或一个私生子)。我又想起了约翰逊博士(http://en.wikipedia.org/wiki/Dr._Samuel_Johnson)的那句话:“好的不是原创的,而原创的都不好。”

不过,这没什么。Web总要发展,否则只有死路一条。JS也一样,要不就不会有ES4了。说到ES4,很快将有下文。

Firefox 3好像也会流行的, 它的空间与时间性能测试预示了这一点。相关内容呢,我以后还会陆续地谈到。