聊研发面试

写在最前面

面试的目标:挑选并【吸引】【能力】【符合【目标组织】需要】的人员

        招聘是唯一的目标就是通过招聘的人选必须要符合组织需要。成功的招聘第一要务就是理清楚组织的需要是什么,哪些是当前需要,哪些是未来的需要,哪些其实只是【个人需要】。

        这其中比较容易出现问题的,就是把个人需要当做组织需要,普通的比如“地域歧视”、“外貌歧视”、“价值观歧视”等等。当然这些都是过于浅显的且危害明显巨大的,但是更多的隐性的【个人需要】被夹杂在各种各样各场面试中而不为己知,带来的问题应该不亚于之前提过的那些肤浅的问题。记得有一次这样的面试经验,面试的岗位是高级技术负责人或是小部门的技术总监,已经是技术第四面。面试官是一个大部门的技术VP。整个面试过程中,我被问及非常多“深入的”问题,例如CPU的亲和力是什么怎么配置,A-NAT和D-NAT怎么解决什么问题怎么实现,SyncFlood 攻击怎么处理,什么是S-ACK,孤儿连接怎么处理,Linux 内存管理与内存映射的原理、一个数据库的IOPS如何计算,GO 的GC与Java 有什么区别等等一系列兼具“深度和广度”的问题。到了问答逆转问答环节,我咨询了面试官团队的用人观以及面试内容与工作职位要求的关系,毕竟很久没遇到面试的时候关于知识点的内容如此丰富的情况了,而且目标岗位并不属于运维或者基础架构部门,甚至不是纯技术岗位。我得到了这样一个回答:“团队必须要有技术追求,因此我希望候选人是一个有着雄厚的技术实力,并且持续对技术保持热情的人,而刚才问的那些问题都是我觉得做一个技术人员必须要掌握的底层原理。”虽然很佩服在这个职级的领导还有如此重视技术并知晓这么多细节的,但是我还是因为这个和其他一些原因婉拒了这个机会。当然我并不会面试内容比较”八股“就简单地否定掉这样一个机会或者是企业,而是是在这个职位上的高级人员面试过程中呈现出很强的个人喜好和观点倾向,那么难免下面的团队做事的方向和内容也会更加偏向于”技术呈现和追求“,从而忽略哪些在业务发展和系统建设过程中那些真正影响结果的,需要”其他能力“去解决的问题会被一直搁置,并且面试过程和内容也无法帮助筛选出具备”其他能力“的人,势必会影响到组织的发展。然而对于企业中的个人而言,我们赖以生存的是业务的生存和发展。

虽然刚才提到了”八股“这个词,并且网上也有越来越多的声音反对”八股“型的面试过程和内容,但是其实我并不准备简单地表态支持或是反对八股。第一性原理是我个人推崇且非常重视的原则,因此在没有充分的理由和证据表明”八股“对达成面试目标没有任何意义的情况下,任何结论都是过于主观的。所以,接下来的问题就是,什么样的面试内容和过程,能够帮助我们达成我们的目标。

符合【目标组织】的需要

           在聊组织需要的之前,我们首先要明白,组织也是有自己的生命周期和阶段的,这往往与业务的阶段高度吻合。不同的阶段做事情的内容、方向和方式有很大的不同,所需要的人才类型也会有非常大的差别。所以很多时候我们发现在阶段交替的时候,人才更迭的速度会比任一阶段中期更加频繁。这其中有管理者的主动为之,也有因为不同人才对不同阶段的适应性不同主动选择相关。一般组织和业务的生命周期可以分为四个阶段。

业务与组织的阶段


探索期扩张期稳定期衰退期增长期爆发期冷静期

 探索期

第一个阶段是探索期,这一阶段从业务诞生开始,主要目的是保证生存,探索并确认核心业务架构(关于业务架构可以参考Zachman EA,ToGOF EA等企业级架构标准的定义)。这一阶段过程中,业务功能少且简单,以各种MVP 的投产为主。产品形态调整极大且快速,但用户量小且增长缓慢。因此这一阶段的人才对解决方案技术和业务架构技术的要求并不高,而且往往是前端要求高于后端。但是由于节奏紧,压力大,变化块,资金缺,企业很难投入足够的精力和成本甚至基本没有投入到人员的培养中,所以软素质或者说潜力在这阶段的重要程度和影响程度并不大,而现成的记忆性知识掌握应该是最核心的硬件需求,并且抗压能力和执行力是最核心的软件需求。当然,这里并不说我们不考虑专家型或高潜型人才,也不是高级能力或软素质可以被忽略,而是要系统性地看待我们的各种成本和竞争力等方面的约束,凡事讲究一个适度而不是追求绝对。

扩张期

      当组织核心业务架构确认之后,业务的发展方向开始变得清晰而明确,就像高楼大厦的地基和框架已经确认好,剩下的就是添砖加瓦和装修。这时候,业务度过了生存危机,进入第二阶段–扩张期。这一阶段用户开始大量涌入,速度超多绝大多数决策者的预期,之前因为用户量过小而来不及思考或者实现的各种性能、容量、稳定性开始爆发式涌现,一遍遍撕扯着用户的体验。但是同时,功能上绝大部分都是围绕核心业务架构的不断丰富和细化,产品调整的不确定性和幅度变得非常小,似乎人人都是预言大师,应用架构显得格外的健壮。于是,组织对人才硬件素质的要求就变成了近乎绝对的解决方案架构(包含基础架构与中间件)知识能力,而业务系统架构师则需要活在解决方案架构师的阴影之下。

     同时,快速增长的业务要求能力水平或成长速度能够与之匹配的研发组织。但是很多时候完全直接招聘能力对应的人才是不可行的,一是这一阶段的问题现象太多,逐个击破时间周期太长成本太高,需要系统性地有技巧地解决,而具备这级素质的人才往往已经是该领域的专家。二是这种专家型人才数量少,撬动成本高,而且招聘和融入的时间也很长。更有效的补充办法或者应该反过来作为主要办法的就是通过人才培养的办法来快速实现团队构成的变更。所以,人才的软素质,尤其是软素质中的成长部分在这一阶段的招聘权重会变得更大,而且这种变化应该在扩张期的第一阶段–增长期就表现出来。一个可行的方案是一定配比的专家型人才带着一群高潜型人才,兼顾到周期、成本,成全当下和未来。

稳定期

     在业务飞速地增长一段时间之后,我们会慢慢发现我们的主模式或主产品用户规模或者营收规模的增速在放缓,甚至你会发现不管做什么,都只是随市场规模扩大的自然增长甚至维持水平。随之而来的就是各种全新的需求,这些需求或多或少了都打破了之前的业务架构,甚至有一些独立于之前业务架构之外的东西。虽然业务依然很健康,营收都不错,但是却慢慢嗅到了熟悉的迷茫感,各种密集的试错、实验又开始了,就像探索期那样。不同的是我们没有之前那种生存的压力。这意味着,我们的业务进入了稳定期,这一阶段最大的目标就是二次探索发现新的增长方向,即进化的或者全新的业务架构,并且保证旧有系统的有更高的稳定性和像新系统一样的迭代效率。

     这一阶段系统的稳定性要求会进一步变高,因为系统故障带来的损失不再能够通过快速的增量所弥补,甚至损失是长期的。同时我们的功能和系统也不像探索期那样即用即抛,我们需要拖着已经成熟的业务系统架构进行频繁的调整。那种难度跟活体生化变种实验差不多,你得保证一个普通人活着的情况下快速地变成金刚狼,成就一个金刚狼牺牲了多少实验对象,然而我们却被要求所有实验对象都必须活着,因为只有一个。

    得益于扩张期中后期的积累和沉淀,其实要做的大型的设计和实现并不会太多,更多的是精细化和自动化的调整,而且不管是扩张期招聘或者培养起来的解决方案专家,都已经获得足够的成长和经验。稳定性要求高,但是用人紧迫性却相对较低。反而是频繁的各种突破性的尝试会不断挑衅你的系统和我们的自尊,我们会发现我们之前引以为豪的设计能力和系统架构变得不堪一击,“为什么这个简单的功能要开发这么久”的质疑声不绝于耳。所以在本阶段中,硬件上的核心的用人诉求是业务应用架构的设计能力,软性诉求是强大的变通力和沟通力。因为有了足够的变更力,我们才能突破之前的固有思维和成形结论,以更加空杯的心态去思考业务和业务架构,并且,你还要能说服别人否定掉他们之前的观点,接受你的观点。

衰退期

     最后你会发现做什么事情都已经于事无补,业务量开始不停地下滑,我们能做的就是尽量延长最后的期限以谋得转移的时间。这时业务会进入最后的阶段,也就是衰退期。衰退期的唯一目的就是延长或者保住目前的状态,技术力变得不再重要,甚至我们在人才上的各种成本、竞争力上的约束会比任何一个阶段都要糟糕。高抗压性可能是你唯一的关注点。

     当然现实会比上面的情况来的复杂的多,由于互联网或者软件模式的低研发成本和周期,我们更容易进入且陷入多模式的状况中,这使得同一个组织往往同时维护多种业务产品,而不同的产品处于不同的阶段。这往往是对用人者最大的且难以自知的挑战。

当下的需求、未来的需求与过去的需求

认清你的阶段与重点     

     在刚才分析业务和组织阶段的时候,我们了解到不同的阶段,团队所面临的的主要问题是有很大变化的,所以我们的主要用人需求重心也应该会有相应的侧重。应当优先考虑当下的需求,次要考虑未来的需求,少量考虑过去的需求。注意这里的的说法是优先与次要,而不是唯一。比如在探索期大量的招聘解决方案型的人才,或者着重考察人才的成长性而不是现有价值,这都是有失偏颇的。从之前的分析看,这都是未来的需求,未来的需求只有当需求出现时,人才的能力价值才能应用和变现。不合时宜的人才结构会耽误重要的、紧急的事情的开展节奏,甚至出现完全错误的思考和做事方法,这是非常危险的信号,一个异常稳定但是却没人用户的系统没有存在的意义和价值。类似的错误还有稳定期重点招聘解决方案人才,这属于过去的需求。

     但是无论如何还是要强调一句这里说的是重点或者说侧重点,而不是唯一,我们可以讨论说任何时候都招聘全能型的人才,组件全明星团队,但是需要结合我们的环境与条件,不管是业务还是用人,都做好基本的SWOT分析。但是不管是何种条件,我其实都比较反对过于单一化的团队,不管是全明星还是全冥星,一个良好的生态是多样和互补的,单一的种群会极度压缩里面每一个个体乃至种群整体的生存空间。

与用人目标一致的考察内容与方式

    与认清自己的用人目标一样重要的是,我们的考察方式与内容要与我们的用人目标保持一致。这也是最常见的执行偏差,比如刚进入稳定期的团队,积累了大量的稳定性的理论和实战经验,这是整个团队引以为傲的资本,但是他们也同时意识到当前平台型的架构可能难以在满足交付周期的条件下同时支撑核心业务与探索型业务的研发工作,中台或者是SOA 会是比较可行的解决方案,于是他们从简历库中筛选了一些有从事过相关项目的专家并开启面试。但是不知道为什么,在这些人的面试过程中,交流的过程大多甚至依然只有与解决方案相关的内容,于是有的候选人稀里糊涂地被pass,有的候选人稀里糊涂的过了,用人单位美滋滋上报了满编的战果,然后很郁闷地发现其中很大一部分入选的优秀候选人并不能带来新的输入。最于此呼应的现象莫过于最近讨论得比较多的招聘自身业务架构师和咨询师但是大量考核内容和重点却是手写算法题了。虽然这里面可能有别的因素,但是能很好的反应这一状况,那就是与用人目标不一致的考察内容与方式,而这里提到的“别的可能的原因”危害更甚且更具隐蔽性。

你的需求还是组织的需求

     我经常会跟其他朋友聊到之前在某个公司的一次有趣的面试经历。当时我面试的岗位是一个部门技术总监或是主架构师,势时是第四面,面试官是一个技术VP。当我认为会聊一些更加偏向行业或技术的认知、判断以及决策相关的内容时,面试的内容却非常出乎我的意料。我们讨论了大量关于网络、操作系统甚至硬件、具体的linux 配置命令相关的内容。我很庆幸这是几年前的面试,那会儿东西我大多都还记得,偶尔还有时间和精力上去实操一下,否则我在这一轮面试可能就被pass 了。面试官给予了我很大的肯定,表示我这个年限和职位,对这些东西还这么了解的人并不多。随后他表示他是技术出生,他很看重技术的素养和对技术的追求,欣赏技术有深度的人,因此他一直把这个当做他的团队的招聘标准。但是当我问及他关注的内容在不同的阶段给他的团队或者业务贡献了多少价值,直接解决过多少与之相关的问题时,我得到的回答的是“这样准没错”。最终我没有选择加入这个公司,虽然这不是唯一但是是我当时拒绝的一个很重要的原因:当一个团队的管理者分不清自我需要还是组织需要,或者强行将不必要的自我需要强加到组织上时,那么团队的走向会出现更大的负面不可预期结果的几率,管理制的职位越高,影响越大。如果你觉得应该是这样准没错的需求,却给不到具体的价值符号的时候,那么请警惕这种需求混淆的谬误可能已经出现了。

另一种评估重点的视角

      之前已经讨论过不同业务的不同阶段的招聘重点,这算是一种纵向的切分。同时,我们之前提到过,很多团队的情况会非常复杂,管理者很难清晰判断团队所处的阶段或者下一个这种简单粗暴的结论,也很难说我招聘一个职位是解决某某业务某某问题的,在平台型横向切分团队边界的情况下更是如此。当然还有很多年轻的面试官,他们并不是团队的管理者,得不到这么深层次的信息,也还没能具备这方面的思考意识。那么提供另一种可以规避掉这些因素的制约的视角就非常必要。

复杂性与成本业务相关性软硬素质低相关高相关硬素质软素质

       先中插个结论,越是软性的素质,复杂性就越高,改变和培养的成本就越高。与之相对应的是业务的相关性,业务相关性越高,复杂性就越高,解决的成本也越高。原因很简单,不管是业务还是软素质都有很强的个体性,越是靠近个体的地方,就越户显现出多样性与随机性。或许这里也能走一遍遇事不决量子力学:微观状态下的个体呈现出不可预测不可归纳的无序状态,但是宏观上却能呈现出更加强的确定性、有序性等。这与我们刚才提到的另一个视角的重点划分有什么关系呢?这其中的逻辑其实很简单,那就是复杂性高的,成本高的优先考察。最后还是老规矩,这是不得已而为之的解决思路,最好的情况还是,你能清晰的定义团队的现状和未来的可能。

浅谈面谈方式 – 再议八股文面试

记忆性的东西

    回到很早之前提到过的八股文面试,也即直接问“你是否知道某某东西的原理”的这种方式。这里从为什么这种面试方案会如此颇受争议聊起,再拓展到相关内容如何考察上去。

    从内容上讲,在我们整个组织需要蓝图中,属于硬件素质中的记忆这一模块,也仅限于记忆了,并且在阶段能力需求中属于探索阶段的能力要求,也就是说这是最基本的考察内容。所以,如果当你问及一个比较资深的人选此类问题时,几乎等同于问一个建筑架构师敷墙用的某某牌子的涂料光泽度是多少,或是一个高级心外科医生重感冒吃感冒药的计量是什么。被理解成不了解专业算是比较友善的解读方式,绝大部分时候会被认为这完全是在侮辱他的专业和技能。或许会有人说:“你刚才不是说这是最基本的考察吗?那这个都说不出来,那不是证明连基本要求都达不到?”在展开进一步的讨论之前,我们可以先问自己一句:这个问题考核的能力,或者这个知识点,在当下或者未来的场景中,能带来什么价值,能直接或者间接解决和规避什么重大问题吗?这个问题是这个职位的人应该去解决的吗?(如果有非常强的招聘规划)如果答案是否定的,那么请参考之前的内容,看看是否我们在不经意间混淆了自我需求和组织需求,甚至有没有弄清楚组织的需求是什么。如果是肯定的,那么针对这个问题该给候选人一个正面的评价还是负面的评价?该加分还是扣分?回到刚才的成本理论与第一性原理,记忆性的东西成本是很低的,而且我们最终的目标是应用性,尤其是在未知条件下突然问题的解决性。所以这个时候,我并不建议直接给出结论,而是尝试把具体技术栈要解决问题和限制给到,看候选人解决问题的思路,这里可以同时考察逻辑分析能力或领域迁移能力,这都属于应用能力。候选人或许可以从问题中快速发现模式,并根据模式从自己固有的经验中快速找到问题的解法,这是领域迁移能力。甚至可能还有候选人在没有经验的条件下,硬生生通过逻辑思维得到一到多种解法,这是更高级的能力,远比记得某某东西难能可贵,如果有这样的人选请一定要想尽办法留下来。而且即便假定候选人记得这个知识点,也不太建议生硬的提问方式,而是抛出问题和约束,如果候选人记得,那么你考察知识点记忆的目的达到了,还给到了候选人足够的尊重和更好的面试体验。同时还可以请候选人自己再分析下这个已知结论的优缺点或是适用场景,或是变更下条件和约束,再看看候选人的分析过程和结论。让候选人回顾项目的当时的决策和实际的建设情况,跟候选人一起讨论还能有哪些可以做得更好的也是不错的选择。

    而且,知识海洋的广袤是无限深远的,记忆点答对率的多少,只能证明彼此知识点交集的大小,而不是对方知识点的幅度,在不能证明自己考察的内容是符合组织需求的情况下,不要发生逻辑错位,用交集大小来证明它集的大小。

    最后,如果实在不能避免做出直接性的提问,那么可以给到问这个问题的原因,对于我们实际做事的意义和价值是什么,能够给到候选人我们的诚意和足够的尊重,消除为问而问的疑虑,同时再次督促我们思考,这个问题考量的内容是自我需求还是组织的需求


一切都是为了实战

      实战才能说明一切,而实战中有无数的细节和个体化的条件会约束和影响你的决策,真实的问题几乎没有可以直接套用的方案。最好的考察方式就是基于实战的思考与权衡,从项目中应用出发,不仅能考察到候选人对知识点的掌握,还能充分了解候选人整个思考和决策的过程,对应用能力的考察更有说服力。STAR 模型会是很好的考察方式,结合前文提到的条件和约束变化面试法会更加有奇效。

回应与看待不一致

很多的时候,候选人会给出跟我们“预设标准答案”大相径庭的回答,如果遇到这种情况,请提醒自己放低你的固有认知,管好自己号码牌。这没准是一次难得的获取新的视角和思路的机会,请你珍惜并积极的参与到讨论中。有可能候选人对知识的记忆是错误的,但是就像刚才说过,这种低成本的东西不重要,你可以将正确的知识点告诉候选人请他再分析一次会是比较好的处理方案,而且还能从侧面观察候选人的变通性。虽然最终可能还是没能达到一致导致你pass 掉候选人,【因为看待问题的方式差异过大,可能在后续的沟通、协作和配合中难以协调】会是比【他的结论是错误的】更好的原因和心态。

不要忘记吸引

     找工作是一场特殊的恋爱。请时刻牢记过程中的位置平等性,世界的多样性,随时不要忘记展现个人(如果你就是直接用人单位)和组织的魅力。

     平等性要求我们沟通的氛围是讨论而不是质问,我们是在寻求伴侣而不是审问犯人,舒缓的环境能让候选人更加接近真实的工作情况,从而让结果更加真实,避免错失良缘。所以很多专业的面试培训都要求我们在正式开始之前要有“破冰环节”,但是你今天怎么来的,吃了没有这种尬聊型的破冰太基础了,没有哪个女孩子因为你这两句尬聊就对你敞开心扉,也不会仅仅因为你没有遵循固定式的开场白就把你否定。氛围的营造和维护要在整个面试过程中处处体现,不要问我具体的方法,只有一句话就是,对面坐的是你未来的伙伴(这里用了一个跟之前类比恋爱及不搭边的代名词,原因只是考虑用爱人太过敏感和特定性,可能误导或引发争议),那你应该以什么样的姿态去聊。

     平等性还要求我们不要一味的去迎合。每个企业有自己的文化,做事的标砖、节奏和风格,就像每个人都有自己的三观和个性一样,一味通过迎合而获得的爱情既不舒适,也不长久。表明你的诉求和观点既是对候选人的尊重,也是对自己的尊重,能避免后续很多不必要的麻烦

多样性要求我们不管是回应答案还是解读答案,从心态到姿态都是提出不一样的看法和视角,而不是否定对方。

©著作权归作者所有,转载或内容合作请联系作者
禁止转载,如需转载请通过简信或评论联系作者。
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,657评论 6 505
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,889评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,057评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,509评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,562评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,443评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,251评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,129评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,561评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,779评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,902评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,621评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,220评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,838评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,971评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,025评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,843评论 2 354

推荐阅读更多精彩内容