程序员的困境

最近我为一个内核程序员的职位面试了十几个候选人。这些候选人都来自一些不错的大公司,这些公司在芯片或嵌入式操作系统领域十分有名。这些候选人大多声称自己在内核方面有着十年的在职工作经验。他们的简历看起来非常耀眼——各种相关的项目、术语和奖项……

但他们几乎无人能够回答一个非常基础的问题: 当我们调用标准的 malloc 函数时,内核中会发生什么?

先别吃惊。当我要求其中一位候选人基于 glib 的哈希函数写一个简单的 LRU 缓存框架时,他先是表示从来没用过 glib——如我所料——于是我帮他打开了 glib 哈希 API 的页面,并向他详细讲解了这些 API;然后大约一个小时以后,他只写出几行凌乱的代码。

我不知道其它国家是否也有类似的情况,但在中国,或者更具体一些,在北京,这就是现状。那些在不错的大公司里工作了多年的“资深”程序员们无法在一些简单的、基本的问题上证明自己。

(Credit: flickr

这到底是怎么回事?

当我在这个问题上思索得越多,我就更加相信,这不仅有他们自身的原因,同时也归咎于他们所供职的这些公司。这些公司通常提供了一个稳定的代码堆,往往几年都不会有大更新。这些代码的专有技术把人们的技能框进一个定式,以致于他们只需要遵循现有的路径,而不需要发挥创意。如果你碰巧为这类代码工作,而且与世隔绝了很长一段时间,那么有一天你会发现你自己已经陷入一个可悲的位置——他们在团队或公司内称呼你为 “ 专家 ”,但不幸的是,你无法在市场上找到一份同等待遇的工作。

这就叫作 “ 专家陷阱 ”。日复一日,程序员们都渴望在团队或公司内成为一名专家;但是,当那一天真正到来时,我们却早已作茧自缚。我们在既有代码中钻得越深,我们自己就陷得越深。既有代码是如此稳定(如此宠大、如此好用),让我们渐渐地失去了从无到有独立编写完整项目的能力。更糟糕的是,如果我们的主要工作就是维护这些既有代码、很少开发新功能,那么过不了多久,无论研读了多少代码,我们都会发现自己不会写代码了——哪怕是一个像毕业大作业那样简单的任务。这就是程序员的困境: 我们以编码为生,但那些养活我们的大公司却在无形中磨灭了我们的生存技能。

如何打破这种困境?

对于个人:

  • 首先, 打造你自己的私人项目。你需要不断地打磨自己的技艺。如果工作本身并不能帮助你做到这一点,就捡起那些你感兴趣的问题,然后用你的私人时间去攻克它。通过这个方法,你应该会学到新东西。如果把你的私人项目发布出去,比如在 GitHub 上,你说不定会认识一些人,帮助你大踏步地向前迈进。
  • 不要在一个团队中停留超过两年。强迫你自己四处转转,哪怕在是同一家公司内,你会面对新的挑战和新的技术。试着每隔 18 个月就出去面试工作。你并不需要真的换工作,但是这能让你看到真实的市场需求,以及怎样与时俱进。

对于团队和公司:

  • 给予员工压力和挑战。实行轮岗制度,让“专家”们有机会拓展他们的技能。启动新项目,用战役来磨炼你的勇士。
  • 周期性地举办黑客马拉松活动。这有助于营造一种崇尚创新和创作的企业文化,人们会受到同伴的激励——“擦,这个混蛋居然可以在 24 小时内写出这么漂亮的框架,我也得加把劲儿了!”
1 4 收藏 29 评论

关于作者:CSS魔法

百姓网前端工程师,移动 Web UI 框架 CMUI 作者,自称 “披着前端工程师外衣的设计师”。 个人主页 · 我的文章 · 12 ·     

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 编辑老师,不好意思,倒数第三段有误,丢失了一些内容。望尽快修正。

  • 說得不錯的

  • 的确,现在的语言发展越来越远离底层,越来越抽象了...

  • azure   2013/08/21

    招人思想太陈旧。

  • 叶树深   2013/08/21

    只能说作者病的不轻,通过你的题目我发现,你需要的是一个本份的本科毕业学生,最好是刚学过操作系统和数据结构课程的学生,而不是一个有经验的专家,没有人能够面面俱到的深入到各种基层工作中去,作为专家更是如此,能够在全局把控项目中的各个要素这是专家要做的,将基层工作技能从拥有的技能列表中剔除也是必须的,所以基层工作不是他的强项,这是必然的,通过你的试题我发现,你面试的人都是专家,而你自己应该将自己定位为一个基层工作的码农,专家不是你能做的,因为你不愿意放弃你的基层工作,将其交给学校毕业的学生,你应该找个好专家做你的领导,而不是你自己去做领导。

    • 风华旋舞   2013/08/21

      1、文章开头已经明确说了要招聘什么职位的人,你的评论完全驴唇不对马嘴。
      2、专家不等于领导,领导只需要知其然,专家必须知其所以然,必须在其所专领域有深刻认识和理解,抱有你这种心理的话注定成不了专家。
      3、基础知识忘光等于自斩手脚。

    • WebIllusory   2013/08/25

      那也得考虑搂主要找的到底是什么样的专家罗,若是系统架构师之类,自然面试不需要涉及太过底层的东西;但如果是需要特定专一领域的人才,越是底层才越能验证他真正的技术水平不是。

      其实搂主讲的问题恰恰是我一直的痛处,大公司有深厚的根基不需要过于创新型的人才,于个人的长期发展果真是百害。

  • kk   2013/08/21

    有的公司可以放手让新进来的人写代码,出了问题他很快就能找出原因,他有这底气不需要自己去写。
    不然全部亲力亲为?

  • Tkey   2013/08/21

    招聘思想绝对有问题。。。

  • CrazyMaple   2013/08/21

    第一次听到“专家陷阱”这次。不错的文章,学习到了!

  • 在大公司呆久了就会这样,其实在哪里都保持一颗极客和学习的心,都会越来越强大,哪里有这样的黑客马拉松的活动呢?

  • bigzhang   2013/08/22

    我觉得,也许专家可以不必面面俱到,什么都牛,但是面试的时候,基础的都不会,只能说,专家还是不专。

  • when u see who designed 精子令 二叉树 ,gene软件结构;
    你会感觉这是 WHAT 原因么?
    不是 曹孟德 ?
    不是 用者的智慧 ?
    不是 脑波生产的低等产品 ?

  • cade   2013/08/22

    呵呵,别人都连基础都不会,就只有作者最牛

  • 路过只是缘分   2013/08/22

    老实说文章的描述太过简单和模糊,比如“他们的简历看起来非常耀眼——各种相关的项目、术语和奖项……但他们几乎无人能够回答一个非常基础的问题” 甚至让我感觉像是语言陷阱,把我诱入你想要表达的观点中。

    实际上,从文章所表述的内容来看,我无法分辨那些候选人是否具备你所要招聘的条件(实绩上 我也不清楚你需要应聘者需要哪些条件,文章的表述相当笼统模糊)。

    我不知道你是否有询问过 他们在原先参与的项目中都担任了哪些具体职务,具体的工作内容是什么(也可以先询问了解项目的性质,一个新的项目?一个维护项目?主要是追加还是现有基础上的改修? 这样可以最初步的对候选者进行鉴别,也就是说如果一直从事改修 维护,有可能经常使用现有代码进行简单的仿照 甚至复制,在接下来面试阶段可能需要额外注意这点 进行必要的提问和了解。如果是一种崭新项目,那初步可判定为可能有一定的编码能力 接下来就其编码能力进行深入了解)? 项目中使用到了哪些技术 哪些扩展库? 对于项目中使用的技术及扩展库的熟悉程度如何? 根据以上问题的 可以初步了解到候选人之前以及近期的工作状态及对相关技术的接触度。 根据其回答,再做出相应的后续提问。

    当然,我相信可能他们参与的那些项目所使用的技术 类库 你不一定全部熟悉或者知晓,但如果说碰巧熟悉或者知晓的情况下,可以就这个技术或类库做相关的提问。比如,如果候选者在之前工作中主要担任编码的,你可以就相关技术 让其现场编写一段程序。 如果候选者担任类似顾问或技术总监性质,协助并排除各种异常及疑难编码问题的话,你可以让其现场解决一些相关技术上的异常来考察。通过对应或者说这种对等考察,可以进一步了解候选者在之前项目中所处的真正位置以及其个人的能力。(如果直接按自己熟悉的来考察对方,这样的方法也有失偏颇,毕竟没人能够掌握全部技术 或者永远很清晰的记得某些技术 并时时去追这些技术。并不是所有公司都有20%自由项目时间来从事自己感兴趣的项目用来丰富补充更新自己的技术)
    当然 这样的考察只是对候选者个人能力做一个相对准确的定位,并不说明他是否合适所要招聘的位置。

    之后要做的,不是直接就所要招聘位置技术做相关提问,而是询问他对这些技术是否熟悉,先从他口中得知他对你所需要他掌握精通的技能的一个情况,然后再做相对应的提问。这样可以更贴合实际的提出问题,更准确的定位其是否符合要求,避免出现因自己提出问题的偏差而使对方的回答总难以让自己满意,从而产生负面情绪,这种情绪会严重影响之后面试对对方的判断力。

    最后,关于“如何打破这种困境?” 除了第一点认同外,其它的根本不赞同,其他几点作为课堂上做教育和演讲比较合适,但其实绩与现实不符。你真的做到了吗?(另,“有助于营造一种崇尚创新和创作的企业文化” 太过套话了)

  • 表示不能完全认同,不过还是有些启发。谢谢分享。

  • lei chen   2013/08/22

    写的真是贴切啊,非常符合现代程序员!

  • 一声笑   2013/08/23

    鄙人认为这是社会分工日益精细的结果,不必惊讶。“当你知道底层实现的时候就能写出性能更好的代码”这种话很没有营养,我也可以说,当你知道汽车的轮子怎么造,引擎怎么发动的时候,你开车便会开得更好。

    • none   2013/08/26

      ” 当你知道底层实现的时候就能写出性能更好的代码 “ 这句话怎么就不对了? 我觉得很有道理啊, 当你对底层实现有了解后,编码之于不仅仅是从代码表层看到效率性能,而且会多颗心去思考更深层次的代码结构如何优化问题。

  • 捡石子的人   2013/08/23

    虽然还没有经历过,但在以后的学习和将来的工作中会好好参考这些建议的

  • 朱超   2013/08/26

    我是JAVA程序员,基本上被问到API的东西我都回不上来,但是项目还是一个接一个,薪资还是
    越来越高;那换您找JAVA程序员,是不是你让他把API背下来才肯录用他?
    I GO !

    • jiang   2013/11/01

      不知道你薪资有多高,值得你这么得瑟。 楼主说了,是找内核开发人员,难道这些问题有问题吗,如果今天oracle招人做java的核心东西开发,你觉得你那点水行吗。

  • it漫步   2013/08/27

    写的很好 我发现我也陷入这种情况了

  • 说的不错,不错的建议。可以去尝试下。

  • shuqin1984   2013/09/05

    面试别人的人, 也会遭遇被面试的境遇。 换成自己被面试, 也许自己就成了自己所说的那种人了

跳到底部
返回顶部