不难

我也写过移动端 LRU Cache ，开源而且用得人很多 但我现在没准备要我直接写，我不一定能写好。。。

如果是三年前我找工作那会儿，简单。 如果是现在，很难。 所以这种问题的价值在哪？

这个属于 leetcode 中等难度题，大厂招聘门槛题 你说 BAT 候选人没有做出来，大概率是百度/阿里的，字节出来人没有问题 过去 10 几年互联网大发展，吃了时代红利，很多人浑水摸鱼进来了，根本不认真练习技术 未来 5 年内，ai 辅助编程会把这类程序员清空，大幅度压缩 初级中级程序员的工作岗位，未来会出现一个岗位，AI 编程驾驶员，工资 1 万出头，而名校计算机博士，起薪 200 万人民币 我在二线城市，程序员水平太差了，面试只能降低要求，出 easy 难度题目，比如下面这题 https://leetcode.cn/problems/move-zeroes/description/?envType=study-plan-f&envId=top-100-liked 给定一个数组 nums ，编写一个函数将所有 0 移动到数组的末尾，同时保持非零元素的相对顺序。 好多工作 10 来年的程序员花了 20 分钟都做不出来，不知道干什么吃的 我发给我儿子做，一个小学 5 年级学生，才学了 3 个月 c++，1 分钟之内做出来

@tohuer00 LRU 是个经典且常见的缓存设计啊，这种设计的思路是可以广泛应用在很多地方的。 我觉得考 LRU 比考快排合理多了，一个完全没刷过算法题，但是好好做过项目的人，给提示和时间绝对写的出 LRU 。 但是快排这种设计，没背过算法，有几个人想得出来？那么容易想的出来，就不会 1960 年才提出了

@victorc 我想了几分钟才想出来，这种题和工作经验无关，考思维能力。

我之前见大厂面试还喜欢让人手写 shared_ptr ，个人认为这个比 lru 简单一些。可能这已经变成大厂面试的门槛了？ 不过我更倾向于这跟工作要求有关。虽然我也是写业务，但是业务跟几何打交道，经常碰到类似装箱问题这种 np 问题，或者一些几何算法，或者一些很经典的算法场景例如 dp 。面试的话如果这些算法做不出来，最低需要展现一定的思考深度吧。

我喜欢让候选人写 BFS 或者 DFS 这种，代码也不复杂，能说清楚递归思路也行，能看出来应对面试态度。如果是单出 LRU 我认为难度也适中，不是什么恶心题，涉及 01 背包/动态规划/贪心算法的相关问题其实就有点上强度了。突然让我写上面说的这些我都写不明白，但是如果是去心怡的公司面试，我应该会准备好，最起码不会太离谱。（刚毕业的时候面试到后面可以手写矩阵乘法/各类排序，最后一家公司写的是斐波那契数列递归、回文字符串，虽然现在换了四家公司，再也没遇到写编程题的场景了）

@hylqs 不知道 可能和我从事的行业也有关系? 不是纯互联网了

@yuanyao 我面试一般会先看项目经历, 考察基础知识. 再让面试者说说拿到一个需求后他的工作流程是怎么样的, 再结合几个业务上的问题, 大概就能了解这个人的真实水平 以及他有没有系统设计能力. 一个需求能不能放心的交给他,考虑问题是否全面, 是否有责任心, 靠不靠谱. 虽然说大部分人都是 crud 但写代码跟写可维护的工程是不一样的. 现在大部分业务的代码有什么难度可言, 重要的是对待一个需求的态度是怎么样的, 有没有自己的想法, 别给后人挖坑.