面试只会问八股？你应该好好思考怎样做一场面试

最新推荐文章于 2024-04-25 14:36:25 发布

双木有兮木有辛

最新推荐文章于 2024-04-25 14:36:25 发布

阅读量516

点赞数

分类专栏：技术漫谈文章标签：八股面试职场和发展面试

本文链接：https://blog.csdn.net/zzt46245/article/details/130790452

版权

技术漫谈专栏收录该内容

1 篇文章 0 订阅

订阅专栏

大家好啊，我是技术大捞，今天要给大家聊的话题是：面试。

国内各大平台有关面试教学的内容，我看到了解到的都是以八股文和应付（糊弄） HR为主，附带公众号吸粉和卖课。

这期呢我不打算讲这些，而是从技术角度上谈一下，技术面试究竟应该面什么？我心目中一场好的技术面试是怎样的？

我个人经历比较坎坷，虽然有几段大厂经历，但是时间都不长，疫情三年呢，每年都换工作，相对应面试的经验呢就比较多。自己也有段时间作为面试官，所以启发了我从两个方向对技术面试进行思考。

虽然面试官的经验比较浅，不过我还是思考了一点东西，感觉已经有分享出来的价值了。未来当我有更深的理解的时候，到时候再重启这个话题再聊一次。

面试误区

误区一：八股文

第一个要说的就是重八股文面试，整个面试过程就是问你一些 Linux命令、Java Spring框架的一些流程机制、事务的四大特性、MySQL 事务隔离级别有哪些等等这些比较浅显且易查的问题。

当然我不否认很多知识点如果熟练的话能节约些时间，但一搜就能得到答案的问题作为面试题实在是意义不大。如果真的在意一些知识点，我觉得可以安排一轮笔试，最好不在面试上浪费时间。

我认为面试较好的情况是相互交流，要问八股你大可以准备个考试，看分数录取。考八股文还有一个坏处在于：常见的问题大家都会背了，于是现在的面试问题，越来越趋向于偏门底层：

以前TCP都问三次握手，现在得问 TIME_WAIT
以前都问 MySQL 索引结构，现在都得问到 MVCC,间隙锁
以前都问 Redis 的数据结构有哪些，现在得扯到渐进式 Hash

当面试题被各大技术公众号、培训机构收录的时候，面试官只能去找一些更冷门，更底层的技术当面试题，候选人得费更大的精力去准备八股文，同时候选人的能力不见得有明显提升。

候选人疲于准备，面试官愁于招人（招进来的人水平不太行）——双输的局面。

误区二：过于开放、悬浮的问题

第二个不愉快的经历是问过于开放的问题。

有面试官问过我你在A和B公司都待过，你觉得这两家公司的区别是什么？

真的，你要是招 CTO 或者战略总裁级别的领导，问这个问题我倒不奇怪，问一个一线工程师或者基层 leader，有多大的意义呢？

这类问题另外一个关键点还在于，面试官问这个问题有助于评价候选人哪方面的能力呢？每个人部门不一样，业务及职责不完全一样，候选人可能答得不一样，可能答的完全是面试官不了解的方面，实在不是一个好的面试题。

何况，面试官真的能站到那么高的角度？以至于他认为自己可以评价我的回答呢？

误区三：不给提示、不做讨论

两个人僵硬地一问一答，类似于

问：xxx的机制是什么
答：是aaa
问：(马上换另一个问题)yyy问题你会怎样解决呢
答：我会先a再b再 c
问：(马上换另一个问题)有没有遇到过 zz 问题
答：没遇到过

问题割裂，没有连贯性，太过跳跃，不符合日常思维流程。我们技术人员不应该是一个考察急智的岗位。
何况针对问题没有深入讨论，容易被候选人糊弄过去。

我认为最能体现候选人的真实能力的不是能答上多少八股文，而是在针对一个问题反复拉锯讨论碰撞中体现出来的。因为讨论细节，异常场景等，能很好地考察一个人的思维严谨性、知识储备，平时的思考积累。

所谓言多必失，少量的答案很有可能是通过记忆给出，背诵一些书籍或者技术大佬博客原文，听着没什么问题，所以我面试呢，会尽量让候选人多表达，多陈述，通过提问、给方案挑毛病的方式和候选人持续地互动。

这样的好处在于：一方面让候选人更多地表达，我能有更多观察的机会避免以偏概全；其次说的多了，候选人容易进入平时的状态，消除面试的紧张感，避免发挥不好的情况出现。

误区四：觉得自己是面试官，高人一等

我有遇到过，面试官直接高人一等地轻视你，给人一种：“我面试你是你的荣幸“的感觉，你在回答的时候摇头晃脑不停看手机，就差点根烟抖腿了。

你讲述的时候，感觉他根本没在听；或者更过分直接嗤笑你的答案，整场面试像和老八共同进餐。

不多别的，面试也是个双向选择的过程，面试官代表的就是整个公司的形象，是候选人了解公司的第一个窗口。如果你用这种态度面试，那你也只能挑到低于一般水平的人员（钱多任性当我没说）。

我面试时如果候选人回答不上问题，我会尽量给一点点提示；如果回答的技术有缺点，我会指出缺点，并让他想补救方案或者换方案；实在差劲的候选人，也不会嗤笑或者鄙视，平淡地说你的技术能力和公司期望的有差距。

总之不能让候选人因为我个人、我的态度，产生一种：什么垃圾公司，我才不想去的想法。

我理解的技术面试

好，说了这么多不愉快的经历，下面我就简单说明一下我理解的技术面试

我认为面试的根本目的：招募和团队合拍的、会分析、能解决实际问题的人。

因此我做技术面试的原则就是几乎不问八股，或者把八股转化为现实场景的问题，另外就是问一些候选人无法准备的问题。

这样首先考察分析能力（能不能很快理解我描述的场景和问题），
顺带也考察了相应的技术底子（能不能快速想到解决方案）。

何况八股文还有一个很明显的弊端：劣币驱逐良币。能力不强的人通过大量的八股知识能通过面试，真实能力不错，但没有背那么多八股的人，反而被拒之门外。

之前有前同事去字节后，讲到内部有人也在吐槽招进来很多都是应试答题厉害，干活依托答辩，这自然和字节重八股的面试有一些关系。当然要说八股的优点的话，就是面试官几乎不用培训和学习，整理一份面试题就可以上马了。

我的面试考虑

把八股文藏在业务问题里

下面我举几个，我曾经面试初级工程师会问的几个问题：

问题1. 如果业务在 Redis 上有一个热点 key，同时又是big key, 会有什么问题呢？为什么会有这些问题？你怎样解决这些问题呢？

问题2. 设计用户表的时候，如果字符串类型的用户名，是全局唯一且不会进行修改的，你会把用户名设计为 MySQL 表的主键吗？为什么？

问题3. 请问下面这个 MySQL 表有什么问题？你会怎样优化？优化理由是什么？

CREATE TABLE `hrms_organization` (
  `id` varchar(32) NOT NULL COMMENT '主键',
  `name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT '' COMMENT '名称',
  `hrms_id` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT '' COMMENT '人事系统id',
  `parent_id` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT '' COMMENT '父组织的 hrms_id',
  `org_level` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT '' COMMENT '组织级别',
  `org_order` int(11) NOT NULL DEFAULT '0' COMMENT '组织排序',
  `org_type` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT '0' COMMENT '组织类型 其他0 部门1 区域2 分公司3 集团4 个人5 大区6 ',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '有效性：0--有效，1--无效',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
  `create_user` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '创建人',
  `update_user` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '更新人',
  `tenant` tinyint(3) unsigned NOT NULL DEFAULT '1' COMMENT '系统租户:1 系统 A,2 系统 B,3 系统 C',
  PRIMARY KEY (`id`),
  KEY `IDX_PARENTID` (`parent_id`),
  KEY `IDX_OR_OR_PA` (`org_type`,`org_level`,`parent_id`),
  KEY `IDX_ID_PARENTID` (`id`,`parent_id`,`org_type`),
  KEY `IDX_NAME` (`name`),
  KEY `IDX_ORGLEVEL_PARENTID` (`org_level`,`parent_id`),
  KEY `IDX_ORGTYPE_PARENTID` (`org_type`,`parent_id`),
  KEY `rds_idx_1` (`org_level`,`name`),
  KEY `index_update_time` (`update_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='人事组织架构表';

## ps： 这个表是某公司生产环境存在的一张表，我看了一下觉得槽点太多，就拿过来又加了一些槽点上去做面试题
## 能优化的点很多，但能答出一小半的都不多，大家也可以看看，挑挑毛病。

可能大家注意到了，我问的问题一般第一问会比较简单，除非技术底子太差或者分析能力太差，一般都能答上来。但我后面一般还会有追问：为什么以及怎样做？

我更喜欢把具体的八股文知识点藏在具体的问题中，比如第二个问题其实就是问：主键索引和二级索引的区别是什么。

其实也是我个人偏向候选人不要停留在八股理论上，而是能和实际场景结合起来。有些人可能背了理论，实际解决问题的时候却想不到。

其次就是希望候选人知其然也能知其所以然，了解了理论，也要思考为什么要这样设计，应对的场景是什么？不这样会有什么问题？
这几乎是一个技术最重要的思维了。这几乎是一个技术最重要的思维了。这几乎是一个技术最重要的思维了。

因为实际上我们业务上遇到的绝大多数问题，前人都已经解决过了，学习一些框架、中间件、底层协议的原理，并不是让我们也去重复造一个轮子，最主要的就是学习这些大佬是如何解决这类问题的
（比如kafka的生产者，合并消息发送，性能优化感觉就借鉴自 tcp 的粘包思想nagle算法。）

第二点前面已经讲过，让候选人多表达。从中观察候选人理解力：（能否很快理解你要问的问题）、分析表达能力（能否找准场景的关键点并清晰地表达）、技术功底以及性格。

候选人性格

性格这一项呢我个人也没有研究过，不过我有一个很简单的评判标准：一场面试聊下来，我是否愿意和这个人一起共事？

曾经有个候选人，在回答不出问题，我补充提示了一句后，冒出了一句：哦，那你之前也没讲清楚啊。我有点无语：如果你认为某个场景不够清晰，可以询问面试官，确定细节。你没问，说明也没想到这里。
提示后没有反思自己思考有盲区，反而怪我没讲清楚，那我觉得这个人某些技术上思维不够严密之外，还有甩锅的倾向，自然是不愿意与其成为同事的。