作者：TWInsights

这个夏天，再一次coding with her

TWInsights 评论

“毕竟我们只有这一次结对的机会，一个题目总要善始善终，所以不知不觉就写到了凌晨两点，和小伙伴用git协作，寝室只有我的电脑屏幕发出微弱的光，感觉夜晚如此静谧，而我们的大脑和手指都在激烈又高速运转着，我喜欢这样忘我的感觉。”

再遇见

在参加完第三季ThoughtWorks最佳编程体验之旅活动后，凯欣在自己的博客中写下了这样的回顾，这是她第二次参与最佳编程之旅。同样经过了为期四周的线上编程挑战，同样是从一千多名网申报名者中脱颖而出，最终与其他127名学生一起来到ThoughtWorks位于北京、武汉、西安、成都、深圳五城的根据地体验结对编程。

（第三季最佳编程体验——五城集结）

这次活动从开始报名到最终落幕共历时一个月，大家在其中学会的第一课可能就是——坚持。平心而论，今年的线上题目难度并不高，在题目截止之前，ThoughtWorks工程师还在线上分享过程中“无心插柳”的讲解了考题，并对同学们在这一过程中所遇到的问题进行解答。意在让大家遇到难题时能够选择直视问题、正面出击，毕竟在真实的工作场景中，“退缩”从来都不可取。

但即便如此，仍然有近90%的报名者在两轮线上答题赛中退出。最终，留到最后的128名同学在6月8号聚集在了一起。提到这次相聚，凯欣用了“久违”二字。这其中并不全是怀念，在去年的编程体验中，她算是抱憾而归。在侧重于“交付完整产品”的比赛中，由于纯粹追求设计思想与代码质量，忽视了内部研究，最终与第一名失之交臂，还错失了心心念念的“无人机”奖品。在朋友圈看到活动信息后，她第一时间报了名，想看看今年的玩法会有什么不同。

确认过眼神，遇上对的人

第三季最佳编程体验之旅的主题是“Coding with her”，作为全球最佳女性科技雇主，ThoughtWorks认为在科技领域男性和女性没有差别，在校招过程中也一直坚持男女比例1：1。在第一天的碰面中，同学们就见到了来自ThoughtWorks气场全开的几位小姐姐，她们都是公司内部非常厉害的程序媛，能文能武，可以利落的解决技术问题，也可以很好的兼顾工作与家庭，被内部同事称为“刀马旦”。

初遇“刀马旦”，倾听她们讲述ThoughtWorks的文化理念、职业经历与个人实践，学生们也在这个过程中“确认眼神、找到对的人”，定下后面两天结对编程的coach。凯欣选择了北京办公室的大姐大——禚娴静作为coach，因为“喜欢她的气场，感觉莫名亲切，喜欢投缘的人。”

紧张Coding，快速交付

作为第二次参加的“过来人”，凯欣对结对编程的概念及方法、TDD（TDD是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码）等实践方法都有所了解。在听完讲解、拿到需求后，就迫不及待的想要开始做整体设计。

这时大姐大却提醒她们，要着眼于当下需求，“我们就很听话地从实现第一个需求开始测试驱动开发，我写测试，小伙伴写实现，一路乒乒乓乓，极其尽兴，几乎忘了所有人的存在，沉浸在程序世界无法自拔，不知不觉就到了五点半截止时间，代码还有一点不太完美的地方，纠结要不要继续改，担心犯规什么的，我们俩最后一致决定要完成它，在最后完成所有基础需求的时候，我们给大姐大做审阅，大姐大咔咔咔指出n个不足，最有感触的一句话是：测试要从需求层面写，我当时好佩服啊，架构师就是不一样，一眼就能看出问题，给我们宏观的把握，接受完指点后感觉自己好幸运，那天晚上非常愉快地从大厦出来，和小伙伴一路商讨，回顾大姐大的点评，想到代码有哪些不完美，我们俩就哪哪都不舒服，也顾不上什么规则了，决定晚上回去继续做。”

在为期两天的编程和showcase过程中，大姐大一直守护在身后，对凯欣小组所遇到的问题进行引导。在这个过程中，回答问题并非主要目的，更重要的在于“授之以渔”，让她们拥有解决问题的思路。这不同于课堂上的直线教学，在真实项目中，问题是无法精确预见的，只有解题思路能够常存心中。这也是为什么ThoughtWorks要把最终脱颖而出的学生聚集到一起、让大家去体验真实的开发过程和工作场景。

（凯欣小组）

最终，在最后一天三分钟的showcase过程中，凯欣和小伙伴赢得了在场coach的称赞，并成功拿下“小蜜蜂”奖品。更让她开心的是，这次奖品的设置是从多个角度进行衡量的，——“这和平时的单一评判标准（分数）决定学生好坏的片面评价不一样，衡量一件事就该多方面衡量，每个方面做的出色的同学都该得到鼓励和表扬，这一点就比第二期的活动做的更好， 很走心。”

尾声

6月10日下午，为期两天半的线下结对编程结束，走在回去的路上。凯欣在回味大姐大点评的同时或许也会想到大姐大的开场分享，“我不知道我50岁的时候会在做什么，但是，一想到很可能是在写代码，我就很开心。我也曾经无数次的想过要选择放弃，但是我站在这里就是最好的答案。”

更多精彩洞见，请关注微信公众号：思特沃克

Share

创新，最重要的是信念 | 产品创新读书雷达发布啦！

TWInsights 评论

首先，读书，当然不能保证我们可以做出成功的产品。

不记得在哪里看过说，“读书，其实是为了培养信念”，对于产品创新这件事也是一样。读书，会让我们明白：

  • 有那么多事，值得我们去改变；
  • 原来，我们也能够去改变；
  • 原来有这么些逻辑和方法，可以避免愚蠢的错误；
  • 只要具有钢铁般的意志，终将抵达彼岸。

“我这辈子遇到的来自各行各业的聪明人，没有一个不是每天阅读的——没有，一个都没有。而巴菲特·沃伦读书之多，可能会让你感到吃惊，他是一本长了两条腿的书！”巴菲特合伙人查理·芒格曾这样评价巴菲特。

但我们也不想让大家为读书而焦虑。因此，基于以下的原则，我们筛选出了32本书：

  • 聚焦产品创新主题；
  • Less is More，少就是多；
  • 兼顾格局、视野与实用、落地；
  • 趣味和思想 胜于 全面和细致。

如果你是想尝试产品创新、已经在做产品、或是想在组织里培养更多产品创新者的人，那么下面这份读书雷达或许可以帮到你：

Share

2018年5月期技术雷达正式发布！

TWInsights 评论

ThoughtWorks每年都会出品两期技术雷达，这是一份关于技术趋势的报告，由 ThoughtWorks 技术战略委员会（TAB）经由多番正式讨论给出，它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议，为从程序员到CTO的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性，因为它不仅涉及到新技术大趋势，更有细致到类库和工具的推荐和评论，因此更容易落地。经过半年的追踪与沉淀，ThoughtWorks TAB（ThoughtWorks技术咨询委员会）根据我们在多个行业中的实践案例，为技术者产出了第十八期技术雷达，对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。

本期四大主题

浏览器增强，服务端式微

为了实现应用逻辑，浏览器在持续扩展成为部署目标的能力。当平台能照顾好横切关注点和非功能性需求的同时，我们注意到后端逻辑的复杂性有逐步降低的趋势。 WebAssembly 的引入为web应用创建逻辑提供了新的语言选择，同时把处理过程更加推向金属侧（以及GPU）。 Web Bluetooth让浏览器能够处理那些原本是本地应用才能处理的功能，而且我们看到越来越多像 CSS Grid Layout和 CSS Modules这样的开发标准正在替换掉自定义的库。对更好用户体验的追求，正在持续地把功能装进浏览器里，许多后端服务因此变得越来越薄，复杂性也因而降低。

不断蔓延的云环境复杂性

虽然AWS继续凭借令人眼花缭乱的新服务保持领先，但我们逐渐看到 Google Cloud Platform （GCP）和 Microsoft Azure 已经成为可行的替代方案。像 Kubernetes 这样的抽象层以及持续交付和基础设施即代码这样的实践，能支持更容易的演进式变化，从而促进云环境之间的过渡。但随着 PolyCloud （这允许组织根据差异化的功能在多个供应商之间进行挑选）以及越来越多的监管和隐私问题的出现，云策略必然会变得更加复杂。例如，许多欧盟国家现在依法对数据所在地做出要求。这使得数据存储的管辖权和其主机的管理策略成为评估云计算环境的新维度。云计算环境的可选范围也在扩大，比如在“函数即服务”和“管理更长寿命集群”这两者之间，就可以选择提供了“容器即服务”（CaaS） 的 AWS Fargate 这个有趣的选项。虽然各个组织对云技术的应用日臻成熟，但伴随使用这些新技术构建真实解决方案的，是逐渐蔓延又无法避免的复杂性。

信任但要验证

对于几乎所有的软件开发来说，安全问题仍然是至关重要的。当前我们观察到传统的“全局权限管理”的安全策略正在转变为更为细致的本地化方法。现在许多系统会在更小的领域内管理信任，并在不同系统之间使用一些新的机制创建可传递的信任。其理念正在由“永远不信任领域外所有东西”以及“从不验证领域内任何东西”转变为“信任但是需要验证领域内外任何东西”——也就是说可以假设和系统其它部分有本意良好的互动，但一定要在本地验证这份信任。这使得团队可以对自己的基础设施、设备和应用程序栈有高度的权限控制，从而实现高度可视化，并可以在必要时候提供高级访问护栏。类似 Scout2的工具以及 BeyondCorp 这样的技术反映了关于信任更成熟的视角。我们欢迎这种向本地化管理的转变，特别是当工具和自动化策略可以确保同等或更好的合规性时。

物联网的发展

物联网（IoT）生态系统持续稳步发展，关键成功因素包括安全和成熟的工程实践。我们看到了整个物联网生态系统的增长，从设备上的操作系统到连接标准，尤其是基于云服务的设备管理和数据处理。我们看到了一些成熟的工具和框架，支持良好的工程实践，比如持续交付、部署以及为实现最终广泛使用的大量其他必要实践。除了主要的云服务提供商——包括 Google IoT Core ，AWS IoT 和 Microsoft Azure IoT Hub ——像阿里巴巴和阿里云这样的公司也在大力投资物联网 PaaS 解决方案。可以从我们的 EMQ 和Mongoose OS 条目一瞥当今物联网生态系统的主流功能，它们也例证了 物联网 的良好的发展状态。

象限亮点抢先看

要记住，就像适用于其他软件领域一样，封装也同样适应于事件和事件驱动的体系结构。特别是，我们需要考虑一个事件的范围，以及我们是否期望它在同一个应用程序、同一个领域或整个组织中被消费。DOMAIN-SCOPED EVENT将在其发布的同一个领域内被消费，因此我们期望消费者能够访问特定的上下文、资料或引用，进而对事件进行处理。如果这个事件的消费在组织内更广泛地发生，且事件的内容需要有所不同，我们就要注意不要“泄漏”其他依赖领域的实现细节。

身份管理是平台的关键组件之一。外部用户在使用移动应用的时候，需要对其身份进行验证，开发人员需要被授权才能访问基础设施组件，而微服务也需要向彼此证明自己的身份。你应该考虑的是，身份管理是否真的有必要自己来搭建和维护。根据我们的经验，HOSTED IDENTITY MANAGEMENT AS A SERVICE（ SaaS）这种解决方案更为可取。我们相信，像Auth0和Okta这样的顶级托管商可以在“正常运行时间”和“安全”两方面提供更好的SLA。也就是说，虽然有时候自行搭建和维护身份管理解决方案是一个现实的选择，特别是对于那些有操作规范和资源的企业来说，这个选择更为安全。但大型企业的身份解决方案通常包含更广泛的功能，例如集中授权、治理报告和职责分离管理等等。不过，这些担忧通常与员工身份更相关，特别是那些受遗留系统限制的企业，尤其如此。

在实践微服务的过程中，为了将后端资源进行聚合，我们实践了一个又一个的模式。之前，我们经常使用类似于Netflix Falcor这样的工具帮助我们实现BFF（Backend for Frontend ），现在很多项目已经开始使用GRAPHQL FOR SERVER-SIDE RESOURCE AGGREGATION。GraphQL可以让客户端直接使用特定的查询语句去访问BFF以获取数据。使用这项技术时，后端服务可以继续暴露 RESTful API，而GraphQL可以轻易的将这些服务所提供的资源聚合在一起，并且对客户端十分友好。我们推荐GraphQL是因为其简化了BFF和其他聚合服务的实现。

在高度分布式的微服务架构中，其可观察性有一个两难问题 —— 要么记录一切，代价是巨量的存储空间；要么随机抽样记录，代价是有可能丢失某些重要事件。最近我们注意到一项技术，它在这两种方案之间提供了一个折衷方案。通过跟踪请求头中传入的某个参数来LOG LEVEL PER REQUEST。使用跟踪框架（可能基于OpenTracing标准），你可以在一次事务中的多个服务之间传递一个相关的ID。还可以在开始事务时注入其它数据（比如期望的日志级别），并且与跟踪信息一起传递它。这样可以确保这些额外数据在系统中总是和相应的单个用户事务一起流动。这在调试时也是个很有用的技巧，因为服务可能会暂停或以逐个事务的方式进行修改。

Headless CMS（ Content Management Systems, 内容管理系统） 正在成为数字化平台的常见组件。CONTENTFUL是一个现代化的 headless CMS。我们的团队已经成功把它集成到开发工作流中。我们特别喜欢其“API 优先”的特点，及其CMS as Code的实现。它支持强大的内容建模原语代码和内容模型演化脚本，并允许将其视为其他数据存储的schema，并将演进式数据库设计实践应用到 CMS 开发中。我们所喜欢的其他特性包括：默认包含两个 CDN以提供多媒体资源和 JSON文档，本地化的良好支持和与Auth0集成的能力（尽管需要做出一些努力）。

EMQ是一个可伸缩的开源多平台 MQTT代理。为了追求高性能，它使用Erlang/OTP语言编写，能处理数百万的并行连接。它能支持多种协议，包括MQTT、MQTT传感器网络、CoAP以及WebSockets，使其适用于物联网和移动设备。我们已经开始在项目中使用 EMQ，很享受其安装以及使用的便捷性，以及它能将消息路由到不同目的地（包括Kafka和PostgreSQL）的能力，还有它在监控和配置上所采用API驱动的策略。

TICK STACK是一个由开源组件组成的平台。使用它就可以轻松地收集、存储、绘制基于时间序列的数据（如度量和事件）来触发告警。TICK Stack 的组件包括：收集和报告各种指标的服务器代理telegraf、高性能时间序列数据库InfluxDB、平台的用户界面 Chronnograf，以及可以处理来自 InfluxDB 数据库的流式数据和批量数据的数据处理引擎Kapacitor。不像基于“拉”模型的Prometheus，TICK Stack是基于“推”模型来收集数据的。InfluxDB 组件是该系统的核心，同时也是目前最好的时间序列数据库。虽然这套组件栈基于 InfluxData ，而且需要使用诸如数据库集群这样的 InfluxData 企业版的功能，但在监控方面它仍然是一个不错的选择。我们正在一些生产环境上使用该平台，并且获得了一些很好的体验。

WEB BLUETOOTH能够直接从浏览器控制任意低功耗蓝牙设备。这样以前只能通过原生手机应用来处理的场景，现在也可以适用了。该规范由 Web Bluetooth Community Group 发布，并且定义了一个 API，通过蓝牙 4.0 无线标准发现设备并在设备间通信。 当前，Chrome 是唯一支持这个规范的主流浏览器。借助Physical Web和 Web Bluetooth,现在有了其他途径来让用户与设备进行交互, 且无需让他们在手机上安装另一个应用。这是一个令人兴奋的领域, 值得密切关注。

我们很开心使用 BACKSTOPJS 来做 web 应用的可视化回归测试。作为可视化比较工具，它的可配置视窗和可调节容错能力可以很容易定位到细微差别。它有很优秀的脚本功能，并且可以选择在无界面Chrome、PhantomJS 和SlimerJS 中运行。我们还发现，它在实时组件样式规范的基础上运行时尤其有帮助。

世界上有数不清的问题都可以用数学优化问题来表达，而其中可以用凸问题来描述的那部分常常能够得到有效解决。CVXPY便是一种针对凸优化问题所开发的开源Python嵌入式建模语言。它由斯坦福大学的学者维护，已经为数个开源和商业解决方案提供了功能齐备的安装套件。它的文档中也包含了许多能够引起开发者使用兴趣的例子。尽管有些时候，我们仍然需要类似Gurobi和IBM CPLEX这类商业解决方案，但CVXPY在原型设计阶段可以说所向披靡。在多数情况下，有CVXPY就足够了。同时，基于最近的优化进展，其开发者一直在为我们提供更多的扩展包（例如DCCP）和相关软件（例如CVXOPT）。

HELM是Kubernetes的包管理器。共同定义某个应用的Kubernetes资源集合被打包成图表。这些图表可以描述单个资源，例如Redis pod，或者全栈的Web应用程序：HTTP服务器、数据库和缓存。Helm 默认带有一些精选的 Kubernetes应用，维护在官方的图表仓库里。想要为内部用途搭建私有的图表仓库也很容易。Helm有两个组件：一个是称为Helm的命令行工具，另一个是称为Tiller的集群组件。保护Kubernetes集群是一个宽泛而微妙的话题，但我们强烈建议在基于角色的访问控制（RBAC）环境中搭建Tiller。我们在很多客户的项目中使用了Helm，它的依赖管理、模板和钩子机制极大地简化了Kubernetes中应用程序的生命周期管理。

ARCHUNIT是用来检查架构特征的Java测试库，比如包与类的依赖关系、注解验证、甚至层级一致性。它可以在你现有的测试方案中，以单元测试的方式运行，但目前只能用于Java架构。ArchUnit测试套件可以合并到C（I 持续集成）环境或部署流水线，使我们很容易地以演进式架构的方式实现适应度函数。

Hyperledger项目现在已经发展成包含一系列子项目的大工程。针对不同业务需求，可以支持不同的区块链实现方式。例如，Burrow专门用来实现带权限控制的Ethereum，而Indy更专注于数字身份。在这些子项目中，Fabric是最成熟的一个。当开发者们谈到使用 Hyperledger 技术时，实际上大多数时候是在考虑 Hyperledger Fabric。然而，chaincode的编程抽象相对底层，因为它直接处理账本的状态数据。此外，在编写第一行区块链代码之前，搭建基础设施也经常耗去很多时间。HYPERLEDGER COMPOSER 构建于Fabric基础之上，加速了将想法实现为软件的过程。Composer 提供 DSLs 来建立业务资源模型、定义访问控制和构建业务网络。使用 Composer，可以在不搭建任何基础设施的情况下，仅通过浏览器来验证我们的想法。需要明确的是，Composer 本身并不是区块链，仍然需要把它部署在 Fabric 上。

RASA是聊天机器人领域的新成员。 它并非使用简单的决策树，而是通过神经网络将用户意图和内部状态映射到回应上。Rasa 集成了自然语言处理解决方案（spaCy）。与技术雷达中的其他同类工具不同，Rasa是开源软件，可以自行托管，对于担心数据所有权的使用者来说 Rasa 是一个可行的方案。我们在内部应用中使用了Rasa Stack，效果良好。

RIBs即路由器（Router）、交互器（Interactor）和构建器（Builder）的缩写， 是来自 Uber 的跨平台移动架构框架。RIBs的核心思想是将业务逻辑从视图树中分离出来，从而确保应用程序由业务逻辑驱动。 可以将其看作是Clean Architecture模式在移动应用程序开发领域的一次应用。通过在原生 Android 和 iOS 应用上使用一致的架构模式，RIBs为应用提供了清晰的状态管理模式和良好的可测试性。尽管我们一直建议尽量将业务逻辑放在后端服务，不要将其泄漏到前端视图中，但移动应用程序非常复杂，RIBs可以帮助管理这种复杂性。

REACTOR是一个基于Reactive Streams规范的、用于开发非阻塞式应用程序的 JVM 库，支持 JVM 8 及以上版本。响应式编程强调将命令式逻辑转换成异步、非阻塞和函数式风格的代码，特别是在处理外部资源时。Reactor 实现了 Reactive Streams 规范，并且提供了两个不同的发布者API：Flux (0 到 N 个元素) 和 Mono（ 0 或 1 个元素），可以高效地对基于推送的流处理进行建模。Reactor 项目非常适合微服务架构，并且为HTTP、WebSockets、TCP和UDP等提供了支持背压（backpressure）的网络引擎。

以上是我们在最新一卷技术雷达中随机摘取的几个Blips，欲获取整版技术雷达，请点击这里！

Share

在ThoughtWorks，我们如何做招聘

TWInsights 评论

引子

知乎上有很多关于ThoughtWorks面试的讨论，主要集中在这样两个方面：

  • 该如何准备ThoughtWorks的面试？其面试流程是怎样的？
  • ThoughtWorks选择员工的标准是什么？

做OP（办公室负责人）一年了，我发现自己几乎30%以上的时间都在面试——招聘成为了我最重要的工作。于是想写一篇文章，讲讲我对面试的理解。

网上盛传ThoughtWorks面试严格，为什么会有这样的说法？说简单一些，与其说ThoughtWorks在选择员工，不如说ThoughtWorker在寻找同事。人与人之间是互相效仿的，很多人加入ThoughtWorks，就是为了和更多优秀的人共事。我们的中国区总经理曾经写过一篇名为《ThoughtWorks的同侪压力》的文章，文中提到：

对应到ThoughtWorks的上下文，这里汇集了一群追求卓越的人，于是这群人形成了一个追求卓越的环境，让每一个新进来的伙伴都压力山大，努力提升自己，寻求用正确的方法，做正确的事情。当对大家留在ThoughtWorks的原因进行调查时，很多人的回答是，因为有出色而努力的伙伴逼着我必须进步。

如何持续寻找我们的同事？

  • 将胜任力模型作为统一的面试框架，寻找有“学习型思维模式”的人才。
  • 多轮测评，以提高人才命中率。
  • 鼓励所有人为招聘出力，打造全员参与的招聘文化。

尽管组织的极速发展带来了巨大的人才需求压力，我们仍然不想在这方面有所妥协。为此，我们在内部建立了由同事进行评估的招聘体制，并成立招聘委员会——伯乐，招聘结果需要通过同事评估、由伯乐来定夺，以尽可能保证结果的合理性。

我们甄选人才的标准基于以下四个方面：

  • 知识：目标职位所需的技术和专业知识——候选人知道什么
  • 经验：目标职位所需的教育背景和工作成就——候选人做过什么
  • 能力：目标职位所需要的一系列行为表现——候选人能做什么
  • 个性特征/工作动力目标：与目标岗位的工作满足感和成败相关的特质——候选人是怎样的人

我们希望面试官在招聘时不要过于重视应聘者掌握了多少知识，而更应看重他们尚未开发出的潜力，也就是他们学习新知识的能力。亨利.福特说过：“不管你是20岁还是80岁，只要停止学习，就说明你老了。坚持学习的人则永远年轻。人生中最大的乐事，莫过于保持头脑青春永驻。” 拥有“学习型思维模式”的人是我们理想的应聘者，这些人不仅有处变不惊的智慧，也有乐于享受变化的心态。

以胜任力模型作为统一的面试框架

专业能力的发展一方面是知识、技能的持续更新；另一方面是通过刻意的锻炼和实践，持续提升专业所需的素养，在ThoughtWorks我们称之为胜任力。Competency Model (胜任力模型)是一个在HR领域非常成熟的、基于行为模式描述的人才管理模型。ThoughtWorks选取和我们的文化特点以及业务模型相匹配、重点强调员工发展的模型而不是单纯“考评”的工具，我们在自己的胜任力模型里定义了Craft Skill(使用某种特定工具解决某类特定问题的能力)和Amplifier(经过一段时间的学习和训练具备达到更高层次的能力)，分别探寻个人在其方向上的发展方式。

举个例子，我们的“企业文化”也可以用胜任力模型来解释：

  • 360度反馈 => 自信
  • 培养型文化 => 发展他人
  • Tech@Core => 技术专长
  • Business Relevance => 客户成果交付

我们以“胜任力模型”作为统一的面试框架。对应胜任力模型，我认为有“学习型思维模式”的人具备这样的特点：

  • 自信：他们敢于挑战更高目标，迎着困难不停前进，而不是总想给自己留条后路。
  • 灵活机动：心态开放，对新事物有好奇心和主动钻研的热情，愿意对自己习惯的做事方式做出改变。对自己的强项和需要改善的地方有清晰的认知，而且能不断调整和突破固有思路和做法，适应新的岗位和要求。
  • 分析性思考：有逻辑、有条理地将问题逐条解决，能比其他人更快学习和领会新事物的特点。
  • 技术专长：在不断地实践中摸索最佳的答案，并持续不断地提高对技术的掌握水平，寻找更好的方法来解决问题。

设计这样的面试流程

很多公司在人才甄选方面非常粗放，随便看看简历，问几个问题就了事，这是非常不妥的。为了提高人才命中率，我们会采取多轮面试方式进行测评。

工作样本测试：针对候选人未来可能面临的实际工作场景、工作内容进行抽样和模拟，观察和评估候选人的表现。比如我们的Homework Review、Pair Interview和Role Play都属于工作样本测试。

行为事件面谈：这是结构化面谈的方式之一。它通过一系列对真实事件而不是假想事件的询问，了解应聘者是否具备职位所要求的能力。在准备面试前（Technical & Culture)，面试官首先根据职位要求的关键能力准备相关的问题，并通过导入性问题和探索性问题开展面谈。

导入性问题：用于导入我们关心的一项能力，通常以“请举一个例子”开头。比如，当我们想评估求职者处理复杂问题的能力时，就可以问：“请举一个例子，当你遇到棘手的问题、或是需要作出一个重大决策的时候，你是怎么应对的？”

探索性问题：我们需要用STAR模型来还原当时的真实场景。

  • 情景：这件事情发生的时间、地点、人物等背景介绍。
  • 任务：这件事发生在什么样的场景下，你要完成什么任务？面对什么决策或者两难？
  • 行动：你扮演什么角色？你具体做了哪些事情？如何想到要那么做的？
  • 结果：事情结果如何？你收到了什么反馈？如何进一步改善？

情景问题面试成功的秘诀是对细节的深挖，像放电影一样还原当时最真实的场景。这样面试官就可以判断候选人提供的信息是否属实，是否具备需要考察的能力。

打造全员参与的招聘文化

在面试中，我们的职责是在有限的时间以及人为设置的环境中辩识出应聘者的优势。我们对招聘的要求越高，面试的过程就越重要，也就越富有挑战性。一个人的简历也许会告诉我们：他不仅成绩优异，还有很强的社交能力。但是通过面试我们可能会发现，这个人其实是一个几年都没有什么进步的平庸之辈。

同时，应聘者并不是唯一接受面试的人。一个能力过人的应聘者在接受我们评估的同时，也在对我们进行审视。我们不仅需要斟酌我们提出的问题，也要留意那些提出深刻问题的应聘者。在这个双向评估的过程中，我们需要不断地锻炼自己的分析力、洞察力、感知力和沟通能力。练习这样的面试技巧，不是很有意思的事情吗?

物色人才不只是招聘团队的事，招聘团队管理招聘流程，但人人都应该参与到招聘工作中来。招聘与整个组织的发展息息相关，这一理念需要渗透到组织深层。

对于小型企业而言，全员参与招聘非常自然。记得我在2014年刚加入ThoughtWorks武汉办公室的时候，无论是校招还是社招，几乎都是人人参与。然而，当组织扩大到一定规模的时候，我们经常谈论的是“人员如何分配”，而不是“如何寻找精英之才”。 而寻找TWer范的优秀人才应该是我们最重要的工作之一。

人才济济的组织很容易在人员规模上翻倍，每位员工只需引荐一位俊才，这个目标就可以实现了。这就是为什么在很多卓有成效的组织中内推很有效的原因——招聘周期短、且推荐的人才适配度更高。

写在最后

我们将胜任力模型作为面试的框架，帮助我们客观地收集信息、评定并识别候选人“冰山”以下的能力。

在武汉，招聘团队在持续推进面试官培养计划，挑选擅长面试的面试官给新人作培训。我们正在统计每位同事举荐的人数和来参加面试的应聘者人数，我们还会评估面试官填写面试反馈的效率，并可视化参与招聘活动的频率。我们鼓励所有人为招聘出力，以此来打造全员参与的招聘文化。

《变革的基因》这本书提到了“谨慎招聘”（Hire Slow)。文中提到：

“优秀的人才通常没耐心等待，为什么还要谨慎招聘？这是因为招聘决策非常重要，如果仓促做了招聘决策，就很可能要在低效的培训、无休止的反馈和痛苦的提升计划中耗费时间。为什么不尽力一次做对呢？”

我们设计相应的招聘流程，就是为了更好的提高人才命中率。我们也建立了招聘反馈机制，在持续关注每一位入职新人成长的同时，验证招聘的有效性，并持续改善我们的招聘流程。这或许能回答我们在文章开头提出的问题。

谢谢阅读！

PS：如果你也想成为一名ThoughtWorker，请查看这里：https://www.lagou.com/gongsi/j67300.html

更多精彩洞见，请关注微信公众号：思特沃克

Share

安吉・弗格森：IT曾是女性主导的行业

TWInsights 评论

本文首发于微信公众号：哈佛商业评论，已获授权，转载请联系哈佛商业评论。

不可否认，女性程序员在全球IT领域仍处于劣势地位。2015年调查数据显示，Facebook的IT人员中仅16%为女性，谷歌为18％。而2014年夏，谷歌、雅虎、领英和Facebook公布本公司女性员工雇用比率时，就承认这一水平过低。事实数据说明，这些大型技术公司在提高女性程序员数量上仍需更多努力。

让我们再聚焦于中国IT从业人员。互联网求职平台100offer在2016年公布的中国互联网女性工程师工作报告表明，过去一年，男性程序员的注册人数是女性程序员的近4倍。此外，同一职位上的男性程序员薪资普遍高于女性程序员。实际上，女性在IT行业，甚至包括整个STEM（科学、技术、工程、数学）领域，都面临严峻挑战和多重偏见，导致这些行业的女性比例和待遇迟迟得不到提高。长达40年的社会科学研究表明，如果不对女性员工的偏见加以制止，这将继续渗透到人们观念中，而且人们会认为自己就在奉行贤能主义，所以更加不会采取行动，破除偏见。

加州大学哈斯汀法学院法学杰出教授琼・威廉姆斯（Joan C. Williams）发表于2014年《哈佛商业评论》的《攻克科技领域多样性问题》一文指出，技术行业女性员工面临的偏见和挑战主要可以分为四类：

  1. 再证明一次！女性要用更多成绩证明自己和男性有同等工作能力；
  2. 如履薄冰。普遍观点认为，高级职位需要在职者拥有传统意义上的男性特质，而女性应做到谦逊矜持。因此，女性职员不能过于女性化，这会显得能力不足，也不能过于男性化，会不讨人喜欢。
  3. 母亲壁垒。女性员工当了母亲后，其敬业度和工作能力会因其母亲身份而频频受到质疑。尽管很多从事技术行业的女性对本行工作时间灵活和远程工作条件称赞有加，但成为母亲后，一旦她们有失职情况，即便是迟到，也会再次印证女性不适合当CEO的传统观念。
  4. 内战。威廉姆斯的研究中，45％的受访女性称曾遭遇这种状况，即如果女性在其事业起步阶段受到歧视，会倾向于避免与其他女性接触，拒绝帮助她们，甚至不惜以损害其他女性利益为代价与男性协作。她们回避对性别歧视的控诉，并以此表明自己的忠心。

那么面对技术领域中普遍存在的四种性别偏见，女性应如何应对，公司又该采取哪些措施提升女性技术人员数量，保障女性员工权益，加强人才多样性呢？带着这些问题，《哈佛商业评论》中文版采访了全球技术咨询公司ThoughtWorks亚太地区集团执行总监安吉・弗格森（Ange Ferguson）。弗格森来自澳大利亚，拥有在澳洲、英国、荷兰、印度、新加坡和中国等国的跨国工作和管理背景，从事技术工作时间近20年。基于在该领域的深厚经验和对女性程序员的深刻洞察，她谈到了女性在技术领域遇到的阻碍以及解决之道。

HBR中文版：从全球范围看，女性在技术领域所占比例都比较低。作为女性，你如何接触到计算技术并最终进入该行业？

弗格森：我的父亲是科学老师，所以我小时候可以借父亲工作之便，在放假时使用学校的计算机。1995年我考上大学，第一次接触到互联网，惊讶于这项科技巨大的连接性，决定从哲学系（50/50男女比例）转到计算机技术系（20/80男女比例）。计算机专业是个男性占绝对主导地位的学科，但当时我还没有意识到，这是个需要探讨的问题。

毕业后我去了一家小型专业服务公司。因为公司规模小，所以我得到很多大公司都不能给予新人的机会。虽然工作量很大，但我成长得非常快，还遇到了人生中一位重要导师丹尼斯。2001年互联网泡沫破灭时，我所在公司不幸倒闭了，于是我像很多澳洲人一样，去了欧洲旅行，并先后在伦敦、阿姆斯特丹工作。几年后我回到澳洲墨尔本工作，在丹尼斯引荐下，到了ThoughtWorks工作，到现在已经11年了。

HBR中文版：外界对IT行业的看法是竞争激烈，而且工作强度和难度都很大。作为资深从业者，你认为吸引你留在这一行的因素是什么？

弗格森：IT行业的工作机会很好，我有幸去世界不同国家和地区工作，也尝试了不同的职责，比如我曾在悉尼、布里斯班、香港、新加坡等地担任项目经理。我在ThoughtWorks工作几年后进入管理团队，一年后去印度担任管理工作，还为当地大学毕业生授课。我喜欢这种IT公司的商业模型——我们以项目为单位，结果为导向，工作时间和地点都不确定。你可能每半年或几年就要换新项目，面临全然不同的工作内容、合作伙伴和文化。我喜欢这种多样性带来的冲击。

此外，技术公司往往采取扁平化管理架构。比如在ThoughtWorks，我的另一位导师兼上司就在我隔壁。他像我的朋友，对我极其信任，同时又有很高期望，不断激励和鼓励我。导师对个人，尤其是女性的职业发展来说极其重要；他们的经验和洞见是年轻人最需要积累的财富。（但研究表明，女性虽然擅长建立关系网，可在职场中这种能力并未得到充分发挥。）当然除了导师以外，你可以向公司中每一个人求教，他们都会像朋友一样认真回答你的问题，而且相比进入管理团队，我们更愿意留在一线，学习应用最先进的技术，毕竟编程才是程序员真正热爱的工作。

HBR中文版：时间灵活、重视多样化，这些似乎都是对女性员工友好的工作条件。但为何现在IT行业女性人数依然过少？在打破技术公司性别偏见方面，ThoughtWorks有什么可供借鉴的解决方案吗？

弗格森：某名为《当女性停止编程》的研究指出，个人计算机最初进入市场时，其营销方向是男孩的玩具，所以美国、欧洲、澳洲的大多数家庭都会把电脑放在男孩子的房间。我们准备考大学时，卧室里有电脑的男孩对计算机更熟悉，技能更熟练，所以选择计算机专业的学生往往是男生，而最终从事这一行业的人也多为男性。我认为，市场营销，包括整个社会从一开始就建立了“计算机属于男性领域”的刻板印象，但这一假设并不成立。在计算机早期应用阶段，程序员往往是女性，而计算机主要用于行政工作——传统女性主导的领域。这样看，男女工作的选择更多受社会思维观念影响，而非男性真的做不好行政工作，或女性不能胜任IT岗位。

为创建多元化且有包容性的文化，ThoughtWorks一直以来都注重培养（cultivating）和发展（developing）员工，为他们提供开放、时间灵活、鼓励学习的工作环境。现在我们在中国的女性技术员工占员工总数的34%，所有女性员工占比40%，女性领导者在管理团队占比40%，在全球基本也是以上数据，这在IT公司中算是比较平衡的男女比例。我们是怎样做到这一点的呢？首先，我们会改变思维模式，不去规定你不能做什么，而是专注于你能做什么。我们赋权给员工，尽量给他们更多选择，让他们不论性别、种族、国籍、教育背景如何，都能发挥出其最大潜能。此外，IT行业变迁太快，这要求你在整个事业生涯中都不能停止学习。我们了解，每个人的学习方式都不同，所以我们提供不同的培训项目，并鼓励大家在网络平台上展开积极讨论，为所有员工创造了解彼此、互相学习、共同进步的良好氛围。值得一提的是，我们还在西安邮电大学建立的实验室，为上千名学生，特别是年轻女性提供线上和线下编程课程，希望更多学生，尤其是女性学到实用的IT知识，帮助他们缩小学校所学理论与行业实践的距离。我们认为，如果女性从学习编程初期就接触到聪明、有能力的IT女性，同时获得足够支持与鼓励，她们对编程会更有自信，并相信自己也会成长为杰出的IT女性。 我们还希望给她们跨越整个职业生涯的帮助，因为IT女性出于家庭、生育等因素选择性退出的比例远高于男性，所以每当她们遇到职业瓶颈期时，都可以咨询我们并寻求意见。

HBR中文版：也就是说，只要IT公司对内对外都构建起互帮互助、多元包容的文化，在行业中处于劣势的群体比如女性，会是最终受益者？

弗格森：的确如此。此外，你帮助的女性越多，她们就会形成越来越强大的组织和关系网，产生累积效应，IT女性的力量也就越来越强大。如今我们成为对女性友好的标志性公司，至少在澳洲如此，这其实也告诉外界：如果你的员工发展方式是正确的，女性程序员的潜能就能被激发。我们也倾向招募没有经验的毕业生，帮助他们建立自己的事业，让他们了解我们的价值观，而一旦他们认同并适应多元、包容的环境，他们就会成为这一文化最坚定的倡导者。

HBR中文版：但多数IT公司都未能在提高女性程序员比例上有所作为，女性仍面临同工不同酬、“母亲壁垒”、“再证明一次”等偏见。你如何看到这一现象？

弗格森：这些情况的确存在，我们听到很多这类故事，包括我们的中国员工也提到，在她之前的工作环境中，“作为女性，她必须比男性同级更优秀，才能获得升职加薪机会”。我想女性首先要了解偏见，然后有与上级谈判，要求同等待遇的意识和技巧。比如我曾经为一位女性管理者提供咨询，鼓励她与上级沟通，大胆提出自己的加薪要求，结果她与上级谈完后，提议立刻就被通过了——这说明，她一直都没有得到自己应得的工资，而如果她不提出要求，老板就不会主动给她晋升加薪机会。所以女性要做的不仅是做好自己的工作，更要有谈判、争取自身权益的意识和勇气。一旦你“向前一步”，不公就会“退后一步”。

另外，如果你的组织限定了女性的竞争领域，迫使女性展开内部竞争，争取仅有的几个对女性开放的升职或加薪机会，我觉得你应该离开这家公司。事实上，如果女性愿意联合起来帮助彼此，与已经获得优势地位的男性沟通，效果要好得多。比如在一个10人会议中，只有两位女性参加，那么她们可以彼此呼应，重复彼此的论点，避免自己的声音在男性主导的会议中淹没——事实上，我也用过这个策略。

我依然是对IT界女性力量的壮大，持乐观态度。回想我们的前一代女性，很少人当了母亲后仍在职场工作，但现在随着职场妈妈人数的增多，这一群体也在开始发出自己的声音，要求改变人们对“女性必须承担更多家庭责任”的偏见。更重要的是，如果你知道偏见的存在，就能做出更好的应对。比如女性面临的“如履薄冰”偏见，出现这一问题的原因在于组织多样化程度不高。如果你所在公司以男性为主导，整个思维模式都偏男性化，女性很少能找到同性榜样，这种巨大的权力落差就会造成极端化的刻板印象，让女性不知道如何在男性为主导的文化中表现领袖气质。但若你吸收了大量女性，保证性别的均衡，女性的形象和气质就会更丰富——你不必是“女汉子”或“傻白甜”，你更多是一个糅合多种气质、刚柔并济的员工。每个组织都需要更多领导者“画像”，让员工看到领导力的多种可能性。

HBR中文版：我们所谈的问题，现在依然没有得到公众的普遍认知和认同，有效的解决方案也并未得到广泛实施。对此，我们还需要做哪些努力？

弗格森：我认为，我们需要更多公众讨论，加强人们对偏见的认知和改变的决心。同时，这不仅是女性的战争，我们同样需要男性的支持。比如在澳大利亚，我们有一个名为“Male Champions of Change”的组织，参与者都是澳洲最有影响力的CEO和高层领导者。他们为女性发声，并致力于推动男女同工同酬，促进女性就业和晋升等。这样的项目和组织会在不同国家出现，以不同速度推进，因为这是对的方向，也是我们应该做的工作。

更多精彩洞见，请关注微信公众号：思特沃克

Share