关于程序员:提升技术招聘有效性-|-为什么企业总考算法题

3次阅读

共计 2596 个字符,预计需要花费 7 分钟才能阅读完成。

前些年技术圈有个经典名梗:

广受谷歌员工欢送的 macOS 包管理器 Homebrew 的开发者,技术大佬 Max Howell,去谷歌面试时因为不会做一道十分根底的算法题——翻转二叉树,而被谷歌拒了。

过后圈内炸了锅,有人感觉是大佬不屑于去做,有人顺带吐槽了本人的相似经验 ……

其中一位网友的评论切中要害:“大佬不会做翻转二叉树,但他依然开发出了 Homebrew;你虽会做,但却开发不来。”

问题出在哪呢?

至多咱们能发现谷歌的这道题并没能挖掘出大佬真正的技术实力,从招聘指标来看,其实是有些失败的。

大佬在之后在技术论坛里做出了解释:

他抵赖本人过后的确不晓得二叉树,但强调了谷歌不能因而拒掉他。

尽管他不懂很多 CS 实践,但他开发出了在乎用户体验、饱受好评的 Homebrew,“真正开源世界中一颗闪亮的星”,他认为这跟 CS 实践没有半点关系。

他表白了一个清晰无力的观点:实际比实践更加重要。

01 为什么总出算法题?

企业为什么执着于出算法题呢?

有三方面起因:

省时省力:技术岗位的次要工作是实现工程项目,并没有太多工夫和资源来针对岗位需要来制订题目。

算法题则无需编程语言或环境的配置,甚至用白板都能间接进行考核,对企业很不便。

算法题容易评估:企业要出跟理论我的项目相干的题型,就须要更多的工夫和资源来设计和评估,许多简单的细节难以量化和评估。

算法题有标准答案和主观指标,如工夫 / 空间复杂度来间接评估候选人的程度。

企业的“保底思维”:算法题考查了程序员的基本功,像一个大漏斗,留下来的至多基本功不错,外面可能存在适合具体岗位的人选。

但只考算法题存在着许多局限性。

02 算法题的局限

2.1 理论我的项目有时不须要懂太多算法

有人会说,算法考核的都是根底,若连根底都不会,那怎么证实他有更强的实战能力呢?走路都不会,又怎么加入短跑较量呢?

但算法与理论我的项目的关系,并非上楼梯似的递进,而更像水分子跟水一样的层级关系。人类真正理解水分子结构不过几百年,但不障碍人类始终在用水。

就像打造一个游戏引擎,须要学习很多算法,但游戏设计师应用游戏引擎来设计游戏,却不须要懂太多算法。

其实,许多算法早已被封装好,集成在各种工具和框架中,除非底层开发工作,比方开发新的游戏引擎,许多岗位早已不须要接触这些算法原理了。

事实工作中,如何很好地实现业务需要,更多取决于候选人如何很好地去应用相干的工具与框架。

2.2 算法题匹配不了简单的工程问题

算法题通常是形象、简化、规范的,理论我的项目中的问题往往是具体、简单、多变的。

招聘时的算法题,往往事后设计了一个最优解,让候选人在限定工夫内解出。

但事实中,工程问题往往不仅没有标准答案,有时甚至连问题在哪,是否能用现有技术解决都不分明。

比方招聘中,企业会让候选人写一个从 A 到 B 点的最短门路算法。这类题目通常被精心设计,数据被结构,肯定存在最优解,问题的输出和边界条都绝对简略和标准。

但理论的交通系统我的项目中,存在着拥挤、施工、事变多种路况,步行、汽车、公交多种形式、用户随便更改目的地,以及要实时同步交通数据,这些都是要候选人花更多精力思考的简单状况,而非仅需记忆相似 Dijkstra 的一个算法就能搞定。

我的项目代码是真实世界的,存粹的算法代码只存在于阉割版的证实实践里。

只有实践,而无奈高效实现的算法也并不少,比方 Kruskal 算法很早就呈现,但很久之后才找到了较好的实现形式,变得实用。

技术人才的外围价值,是用代码实现具体的性能,而非仅懂实践概念。

2.3 AI 新浪潮的冲击

招聘中,候选人往往须要闭卷限时解答算法题。

但事实中简单的我的项目,技术人员能够长时间沟通交流、合作,并且自行查阅材料。

随着 AI 倒退,查阅实践算法常识,更是轻而易举,记忆算法的价值大幅削弱。

这是我用 AI 工具实现的“关键词呈现频率统计”性能,其中波及到了 Porter Stemming 和 Snowball Stemming 等词干提取的算法,而我对这些算法无所不知。

目前算法题考核招聘形式,无奈还原理论场景中的材料搜寻、沟通协调等相干能力。

总之,通过算法题先筛人,再进一步靠面试判断岗位匹配度,“先筛人,后匹配”的模式,仅是拐弯抹脚开掘能力的形式。

不仅会漏掉如 Howell 那种有后劲、创造力、有特长的技术大佬,也容易招到一群只会做算法题,但不足沟通合作、解决理论问题等领有工程能力的人。

好比打靶并没刻意瞄准靶心,只是先让本人手别抖,这样“弹孔”容易稳固地集中在某一区域,招到一群类似的“优良”人才,但却可能偏离岗位的“靶心”。

有没有什么办法,能间接冲着“靶心”瞄准,反过来从岗位登程,间接招到匹配该岗位人才的形式呢?

03 ShowMeBug 基于岗位的“实战题型”

ShowMeBug 致力于深挖技术实力,为企业找到技术岗位的最佳匹配人选,专门打造了基于岗位的“实战题型”。

从岗位需要登程,ShowMeBug 自研能力模型,将岗位能力细化为逐条能力维度,再基于能力维度,推导出具体的技能与知识点。同时也反对企业自行调整。

这些知识点,是 ShowMeBug 与各类行业大佬单干,总结大量过往实战我的项目案例提炼得出。

确保了什么样的岗位,就能明确须要什么样能力,并出相应的题目考核这些能力,使得通过测评的的候选人完满匹配岗位的需要。

比方,除了像 Java、JavaScript、C++、Python 等考核编程语言能力的根底编程题,也有像 Vue、SpringBoot 等,考核候选人应用前后端框架进行需要实现能力的题目。

下图中,就是一道考查候选人“是否可能解决耗时工作”的实战编程题:

这道题目模仿了一个常见的场景:用户在前端点击按钮后,须要优化接口,让后端将耗时工作放入不同线程中异步执行,从而让前端不须要期待所有工作实现能力收到响应,优化用户体验。

同时,ShowMeBug 题库也反对“开卷有益”性能,企业能够在试卷设置 AI 编程助手。最大限度还原候选人事实中的工作环境,考核他的实战工作能力。

总之,企业在招聘时,可间接应用 ShowMeBug 的 5000+ 道题目间接进行考核,节省下大量工夫与精力;

企业也可针对不同岗位,通过调整相应的能力维度、技术与知识点,来自定义想要考核的题目,满足本身个性化的招聘需要;

“实战题型”的内容与 AI 助手,也很好地把候选人放在了实在工作环境下,去解决贴近理论我的项目的问题,最大限度地在屏幕前间接还原他的实在技术能力,助力企业精准择优。

正文完
 0