聊聊ThoughtWorks面试

标签: thoughtworks 面试 | 发表时间:2012-09-10 20:04 | 作者:dreamhead
出处:http://dreamhead.blogbus.com

英文版

http://www.businessinsider.com/hardest-tech-company-job-interviews-2012-8

中文版
http://www.cnbeta.com/articles/203954.htm

最近有几篇关于科技公司面试的新闻,这篇格外受瞩目,因为竟然有公司力压Google,成了面试最难的公司,而这个公司居然是ThoughtWorks。

这个结果真的让我有些惊讶,作为一个面试过许多人的ThoughtWorker,我之前还真没想过我们的面试到底有多难。既然有人关心ThoughtWorks面试,我就不妨在此分享一下我的“面经”。

先来说说,我们的招聘流程。ThoughtWorks的招聘流程大抵分成如下几个部分,以社招开发人员为例:

  • 电话面试,称为Phone Screen,由负责招聘的同事了解候选人基本情况
  • 技术电话面试,称为Techinial Phone Interview,TPI,这个环节通常是针对远在外地的候选人
  • 代码作业,称为Homework,动手写代码对程序员的考核而言是不可或缺的。

通过上面流程,候选人就可以进入到我们的办公室。一般说来,候选人要来办公室两次,第一次会做一些测试题:

  • 逻辑和英语测试

通过之后,才是真正的重头戏,也是称为“面试”的部分。一般说来,这些环节会在一个下午的时间完成:

  • 结对编程面试,称为Pair Programming
  • 面谈,称为Office Interview,在我们招聘同事的口中,它有一个更复杂的名字:Overall Technical Interview and Culture Interview

这是主要的流程,有些情况会因人而异稍做调整。一般情况下,整个流程需要3周左右时间。我个人参与较多的主要是后两个环节,我的“面经”也主要在这里。

结对编程面试,是候选人和面试官一起写代码。所用的代码就是候选人之前在代码作业环节所写的代码。这是个真刀实枪的环节,想作弊是不可能的。之前曾经发生过这样的事情,候选人找人代写代码,结果,一到这个环节就完全暴露。

在这个近距离一起工作的面试中,候选者对代码的理解、开发习惯和与人交流的方式等等就全部展现在面试官面前。有些人之前习惯于窝在一个角落里写代码,像这样,写程序时身边还有人交流,对他们来说是一个巨大的挑战。我曾经看到很多面试者在这个环节紧张得不能正常思考,导致实力打了折扣。

之所以采用这样的方式进行面试,因为这就是我们日常的工作方式。我们希望了解候选人的情况,同样,也希望他们能够最真实地体验我们的工作方式、交流方式和思考方式。我们不仅仅要写程序,还要彼此交流,降低项目中出现“关键人物”的风险。以我之前的一个项目为例,这是一个总规模在十人左右的项目,一年半的时间里,这个项目先后下了四个团队lead,离开项目的开发主力也有五六个,但项目一直顺利进行,未受太大影响,就是因为通过交流,知识得到了充分地分享,避免了“关键人物”带来的风险,也让更多的同事得到了充分地锻炼。

不可否认的是,不是所有人都喜欢这种工作方式。有了这样的环节,候选人在体验之后也会有个新的评估:ThoughtWorks是不是他在找的工作,这样的工作是不是他喜欢的。

透露一个秘密,如果在结对过程中,候选人能够展现出他对快捷键和命令行的熟练,会在面试官心目中有加分的。

接下来是面谈环节,面试官和候选人坐下来,聊聊候选人的一些经历。以我个人的面试风格而言,了解了候选人过往的经历之后,我会让他挑一个自己最想讲的项目,做一个介绍。听起来很容易,但接下来,根据他介绍的内容,我会做进一步挖掘。比如,候选人说自己做过某个设计,我会问他为什么这么做,而不是那么做,对比不同方案之间的差异。这是一个说难不难的环节,如果在做设计决策的过程中,候选人经过了深入思考,回答出这些问题简直易如反掌,但对于那种直奔结果而去的候选人而言,这个问题却并不容易,当初决定的草率会在这个环节暴露无疑。这是整个面试的重头戏,候选人完全可以在这个环节将自己对技术的深入理解体现出来。

所有的问题都是开放的,没有正确答案可言,通过这样的交流过程,我们可以看到候选人更多方面的能力:思考方式、分析能力、表达方式等等。当然,也有一些人让人遗憾,他们应该是做了很多出色的工作,但完全没有办法清晰地表述出来。我喜欢听到的介绍方式是,层次清晰的讲述,当然,如果有激情就更好了。如果你看到过对技术真的有热情的人讲技术,你会知道,与那样的人交流简直是就是一种享受。

之后,我们还会了解候选人的本职工作之外的努力,因为我们相信,所谓的工作,并不能阻止一个真正热爱写程序的人求知的心:即便他只是Java程序员,并不妨碍他了解Ruby;即便工作再忙,他也会抽空学点东西。如果候选人曾经利用时间做过一些东西,那是我们乐于见到的,如果再能涉猎更多的东西,那简直太好了,当然,我们会问一些问题,了解他是“听说、了解、用过,还是深入研究过”。

单就面试过程而言,ThoughtWorks的面试并没有特别的。但为什么还有很多人会觉得这个过程很难。或许,这就是他们习惯的工作方式与我们工作方式的差异所在。

众所周知,ThoughtWorks在“如何做软件”方面是走得很靠前的。当我们的客户还在考虑ClearCase是否要切换成SVN时,我们已经抛弃了SVN,拥抱了git;当很多公司开始做持续集成时,我们已经开始了持续交付;当许多人开始拥抱敏捷时,我们正逐步地“去敏捷”。

在ThoughtWorks工作,我们要找的是真正热爱技术的人,喜欢刨根问底的人,那种为了完成而完成的人不是我们想要的。在公司里,我们经常会听到这样的话:我们不只要实现功能,更要以正确的方式来做。追求是无止境的,所以,我们要找的就是具备深入思考的能力/潜力的人,这样,我们才能不断向前。

在很多的人印象中,ThoughtWorks有一群特别能说的人,没错,在我们的工作里,沟通占了很大的比例,无论是我们在交付项目中,还是咨询项目里;无论是与自己人,还是与客户。所以,在面试中,我们也特别重视一个人的表达能力,肚子有货的人是否能够清晰地表达出来,而表达能力往往是一面反映多方面能力的镜子:分析能力、组织话题的能力、对技术的理解等等。

以个人观察而言,在程序员这个闷骚遍地的行业里,所谓不擅与人沟通的程序员只是没有找到合适的环境。其实,表达能力完全是可以锻炼出来的。还记得我第一次在东软给别人讲东西的时候,紧张得手心里全是汗。在公司内部主动讲讲东西,在社区活动做一些分享,多讲几次,什么问题就都没有了。

其实,所谓ThoughtWorks面试难,在我看来,只不过与其他公司只重视技术能力而言,我们更注重全方位的工作能力而已。因为在ThoughtWorks,我们是程序员,但我们不只是程序员。

相关 [thoughtworks 面试] 推荐:

聊聊ThoughtWorks面试

- - 梦想风暴
最近有几篇关于科技公司面试的新闻,这篇格外受瞩目,因为竟然有公司力压Google,成了面试最难的公司,而这个公司居然是ThoughtWorks. 这个结果真的让我有些惊讶,作为一个面试过许多人的ThoughtWorker,我之前还真没想过我们的面试到底有多难. 既然有人关心ThoughtWorks面试,我就不妨在此分享一下我的“面经”.

再见ThoughtWorks!

- lnsoso - Happy Hacking
最近的几个月时间里我的工作和生活都发生了较大的变化:因为家庭原因,我离开了生活了六年之久的北京,来到了上海和妻子团聚;同时,我也因此而离开了 ThoughtWorks ,加入了设计软件公司 Autodesk. 回首过去的几年时间,我能很清晰地感觉到自己对软件开发的认识不断地发生着有趣的变化:. 眼中只有C#/.NET/Windows,“外面"的世界.

ThoughtWorks读书雷达-编码实践篇

- - 简单文本
期望通过四分之一的读书雷达图就能将与编码实践有关的优秀书籍一网打尽,自然是不现实的打算. 因此,我们希望就我们的侧重点来推荐书籍. 对于编码实践而言,我们共同认为培养良好的编码习惯,编写整洁简单而又合理的代码,是一名好程序员的基本要求. 因此,这里我们更强调与程序员基本编码技能相关的知识. 我们并没有给出与算法直接有关的书籍,虽然我们认为算法知识同样属于编码实践的范畴,虽然我们认为诸如《计算机程序设计的艺术》、《编程珠玑》、《算法导论》之类的书籍同样很重要很优秀;然而,我们取舍再三,仍然将它们划出了读书雷达的范围.

如何快速读Paper – ThoughtWorks洞见

- -
去哪里找paper之后,大家问我的问题就常常变成了:. 如何快速阅读一篇paper并准确的提取其中有用的信息. 在本文中,我将试图为大家简要解答这个问题,争取告诉大家如何在短时间内通过阅读文献的方式了解一个新的领域. 阅读一篇paper通常见的目的有四种:. 面对一个新的领域,我要快速把握这个领域的研究方向和state-of-the-art方法,来给自己或者团队设计一个大致的技术方案.

再谈敏捷和ThoughtWorks中国咨询师

- lishali - 酷壳 - CoolShell.cn
之所以用了“再”,是因为之前的两篇文章——. 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议.

2013年的技术趋势 — ThoughtWorks技术雷达阅读笔记

- - I am Hu Kai
边界正在变的更加模糊,传统上办公室是工作发生的地方,我们需要内部网络来登陆邮件系统,访问公司的知识库,利用电话会议系统和处于世界各地的同事交流. 随着移动设备的普及,网络速度的提升以及越来越多的内部系统被迁移到同时提供外部访问的云平台上,工作正在从办公室扩展到生活的每一处,在出租车上,我们用手机阅读和回复邮件;在机场,我们使用Goto Meeting来和各地的同事举行电话会议;在客户现场,我们用手机访问Jive.

ThoughtWorks读书雷达方法学篇-张逸

- - 人月神话的BLOG
原文: http://agiledon.github.io/blog/2013/08/06/methodologies-of-reading-radar/. 方法学(Methodology)看似与开发技能无关,常为程序员忽略. 忽略意味着未曾察觉,却不等于它的无关紧要. 我们每时每刻呼吸的空气同样会被我们忽略,但空气不重要么.

Serverless实战:打造个人阅读追踪系统 – ThoughtWorks洞见

- -
阅读习惯和个人知识管理体系. 进入互联网时代,知识的获取成本变得前所未有的低廉,但是无论再好的知识,若是没有对个人产生价值的话,那也只不过是一种信息噪音而已. 我在《个人知识管理:知识的三种形态》这篇文章中使用“材料 -> 资料 -> 知识”这样的路径来诠释信息的流通,如何方便快捷并且有效地收集材料,再将其整理转化为有价值的个人知识体系结构,在这个信息极度碎片化的时代变得尤为重要.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

用DDD指导微服务拆分 - ThoughtWorks洞见

- -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.