8 年经验的全栈开发，技术面过程中面试官应该提什么样的问题？

[nulIptr]

今天面试的时候遇到的，我自我介绍完了之后开始问我 python 装饰器语法/垃圾回收/不可变数据类型
第一个我稍微说了两句
第二个我说不知道 python 怎么处理的，讲了下 go/c#怎么垃圾回收
第三个问题我懵逼了，从来没听过这种说法。我说没听过，可能是类似于其他语言里面的值类型引用类型？然后稍微讲了两句。

然后面试官的语气中带着点失望：“这种基础问题都回答不上来啊”

我就说这些问题考察应届生可以，问我我确实答不上来，要不聊聊项目相关的或者聊聊功能设计？
面试官表示这是其他人负责的，他这块只问技术原理

然后我跟他说了几句片汤话就主动结束了面试。。。

写了几年 python 连这些基础都不知道确实有点惭愧，活该我失业找不到工作

[xuanbg]

面 5 年以上的我就都不问技术方面的问题了，直接问做事的方法论。这个不会就是不会，背八股没用。

[accelerator1]

现在的时代背景下，还问这种问的话，很可能面试官也问不出有深度的问题，只能问“茴”字的几种写法了。

[zhouyin]

@wdhwg001
能回到出这些问题 你司付多少钱一月

[wdhwg001]

@zhouyin 这些真的是 mid 级在不包含系统设计的纯技术轮该问的问题，而且是 Python 后端应该会的部分…

而且其实这里面很多问题都真的一点也不过分，甚至你切换一下主力语言的话，这些问题大部分都可以平移过去的。

至于薪酬，国内的 mid 普遍给的都是 30-60 吧，但这不是我司的数据，因为我司并不在国内…

[zhouyin]

@wdhwg001
国内 mid 30-60 乍一看还是比较高的 你去 zhipin 上看看百分之九十五都达不到而且坑少

python asyncio 开发速度和运行效率完全比不上 go
你那种钻研深度 得不偿失 只会越走越窄

[lyxxxh2]

@wdhwg001
搜了下 python immutable,马上理解了是啥。
我用了一年了的 python,你问那些 我全都回答不上。
至于后面的,一个也没听说过。
用 python 就是写项目,让我手写个线程 进程池啥还是没问题。
解释原理.. gg 没系统去学。

[wyntalgeer]

@wdhwg001 #24 然后被 AI 薄纱是吧，玩 Python 不搞工程不搞项目搞起特性来了？ Python 本就不是效率优先的语言，你搞什么特性都是多余的

[LindsayZhou]

@wdhwg001 #8
我觉得挺对的。
我只是做过一年半的运维，已经三年多没认真写过 python 的东西了，都知道上面楼主的那些问题。
正常 python 开发不会确实有点太水了。

[needhourger]

@wdhwg001
从这个问题中的部分讨论已经可以看出来
哪怕程序员里对于技术理论的认知也是分两派的
实践派和原旨派
一部分人觉得学一门语言就要事无巨细的对这个语言的特性了如指掌。
另一部分人觉得语言只是工具，需要熟悉工具但并不应该钻死在工具上，工具完全可以要用的时候再去看说明书。
于我而言我跟倾向于后者，也就是实践派
计算机领域的相关技术日新月异，人不应当浪费自己的时间在一些细枝末节的实现上。
说实话您说的这些东西让我第一时间都不能完全回答上来，因为很多事情对于实践派而言很有可能是日常确实会用，并且很有可能日常用过，但是一下在抛出这么些专业的名词真的会第一时间把人唬住。并且，除非是经常性踩的坑，不然没必要专门记住其背后复杂的细节。
说到底两派人对于知识的获取以及只是组织存储的方式大相径庭。

当然对于这两派并没有拉一踩一的意思。

[iloveayu]

没事这很正常，找工作就像相亲，气场不合总有看不顺眼的地方。
如果你是应届毕业的，这些八股轻松背诵，但他可能直接就问架构设计了。
“活该我失业找不到工作”，这根本不是你的问题。

[ghostwind]

mysql char 是几个字节这种如何

[linzyjx]

5 年以上我觉得真没必要问这种基础问题了，尤其在这种 AI 的时代。人应当越来越聚焦一些核心的东西上，边边角角的东西知道有这个东西就好，不太去深究细节也行。5 年以上的工程师，做东西的经验、方法论，以及对一个工程项目的整体认知会更重要。
但真要说，目前面试市场如此，如果是失业/主动投的状态，那有些八股还是要准备准备，毕竟你不知道会遇到什么人。如果面试官知道你是在职/内推的背景过来面，还问这种玩意的，那确实比较 NT 。

[lozzow]

其实面试的时候问他有没有空余时间做自己的项目工具才行,要对写代码有热爱才能写好代码

[wdhwg001]

@needhourger
所以考察这些实际上也是对实践派到底写过多少复杂代码的考量。

我确实是那种不愿意使用任何我看不懂的东西的人。我觉得这不算什么坏事，甚至于我会觉得代码里出现某种魔法是一个挺让我不安的事情的。

放在前端里，这种习惯会要求我去了解 async await 的 babel 结果，去了解 react 和 vue 的渲染流程，去了解 vite 的打包流程。

放在后端里，这种习惯会要求我去了解请求是怎么经过 router 再到达 handler 的，response 又是怎么一路传递出去的。

我觉得这实际上是个挺好的习惯，因为这种积累可以让我在写代码的时候回避很多隐形的坑，并且在遇到麻烦的问题的时候不至于无从下手。后者尤其关键，因为这种了解会赋予一个模糊的“知道哪里可能是故障点”的直觉，在切换框架和语言的时候也很容易上手。

如果说只会写业务才叫实践派，那其实更是和 AI 没什么区别了，Claude 4 目前写出来的业务代码质量已经很高了。但 AI 目前最缺乏的就是运用它可以复述出来的庞大知识去解决复杂故障的能力，这就是需要人介入的地方。