别再问“Python有哪些数据类型”了，求求了。也别再把GIL（全局解释器锁）当成什么屠龙宝刀，好像候选人背不出它的八股文，就不是个合格的Python开发者一样。我跟你讲，这种面试方式，简直是灾难。你筛掉的，可能是真正有才华的实干家；你招进来的，很可能只是个擅长“面试应试”的表演者。
从业这么多年，面过的人没有一千也有八百，我越来越觉得，怎么面试Python这个问题的核心，根本不在于“问题”本身，而在于“方式”。我们到底想招一个什么样的人？一个Python知识问答机器人？还是一个能并肩作战，能把活儿干得漂亮、干得靠谱的工程师？
想明白了这点，整个面试的思路就豁然开朗了。
我的核心观点就一句话：面试不是考试，是模拟一次协同工作。
你把这个想透了，就不会再纠结于那些犄角旮旯的语法糖或者冷门模块的用法。你会开始关注一些更本质的东西。
先从“破冰”开始，不，是“破防”
别搞那些虚头巴脑的自我介绍了。简历上都写着呢。我喜欢单刀直入，直接聊项目。
“我看你简历上写了这个XX项目，看起来挺有意思的，能给我讲讲吗？你在里面主要负责哪块？”
注意，这不是让他复述一遍项目介绍。重点在后面的追问，这才是刺探候选人真实水平的开始。
- “你当时为什么选择用Flask而不是Django？是项目需求决定的，还是有什么特别的考量？”——看他的技术选型能力和思考深度。
- “项目中遇到最棘手的一个技术难题是什么？你是怎么一步步解决的？”——这是重头戏！一个没有故事的开发者，多半是个没有实战经验的开发者。看他描述问题的清晰度，分析问题的逻辑，以及最终解决问题的手段。是自己死磕，还是查阅资料，还是求助同事？这能看出他的问题解决能力和团队协作意识。如果他支支吾吾，说得含糊不清，或者干脆说“没什么难题”，那基本可以亮红灯了。
- “如果现在让你重新做这个项目，有哪些地方你觉得可以做得更好？”——看他的复盘和反思能力。一个优秀的工程师，永远对自己的代码有不满意的地方。这能看出他的成长性和追求卓越的意愿。
这一通聊下来，半个小时，这个人的经验是真是假、技术热情高不高、沟通能力怎么样，基本就有个七七八八了。那些靠包装简历混进来的人，在连续的追问下，很快就会“破防”。
现场编码：别玩那些算法杂耍
我知道，很多公司喜欢出LeetCode原题，尤其是Hard级别的。美其名曰考察算法能力。但说白了，对于大多数业务开发岗，这玩意儿的性价比极低。你是在招算法竞赛选手，还是招一个能写出健壮、可维护业务代码的人？
我的做法是，出一个源于真实业务场景的、被简化了的工程问题。
比如：
- 给一个半结构化的日志文件，写个脚本统计其中每个IP的访问次数，并按次数倒序输出Top 10。
- 实现一个简单的LRU Cache（最近最少使用缓存）。
- 写一个装饰器，用于缓存函数的计算结果。
这些题，好在哪？
- 足够开放：实现方式多种多样，能看出候选人的代码风格和技术取舍。用字典硬撸，还是用
collections.Counter？用普通的列表，还是用heapq来找Top K？高下立判。 - 考察综合能力：它不仅仅是算法，还涉及到文件IO、数据结构、代码组织。候选人能不能写出Pythonic的代码，非常关键。比如，他是用啰嗦的for循环，还是优雅的列表推导式或生成器表达式？他懂不懂得用
with open(...)来确保文件句柄被正确关闭？ - 模拟真实工作环境：我会明确告诉他：“你可以查Google，可以用任何你熟悉的库。” 我要看的不是他记住了多少API，而是他解决问题的思路。他知道要去搜“Python count items in list”吗？他能快速找到并理解
collections模块的用法吗？这才是真实的工作场景。
在整个编码过程中，我不会像个监工一样盯着他。我会时不时地介入，像个同事一样跟他讨论。
“嗯，你这里用字典来实现，挺好的。但如果数据量特别大，内存可能会爆掉，你有什么思路优化吗？”——引导他思考系统设计和性能瓶颈，比如引出生成器的概念。
“你觉得你这个函数需要写单元测试吗？如果需要，你会怎么写？”——看他的工程化素养。一个只管实现功能，不关心代码质量和可维护性的开发者，是团队的定时炸弹。
整个过程，是沟通，是协作，是探讨。我要看的，是他面对一个陌生问题时的反应，他的学习能力，以及我们俩“合作”起来是否顺畅。这远比他能不能在白板上徒手写出一个红黑树重要得多。
深入Python的骨髓，但要问得“活”
当然，Python本身的特性还是要问的。但要换个问法。
不要问：“什么是装饰器？”
要问：“如果我们有很多API视图函数都需要做用户登录验证，你不想在每个函数里都写一遍重复的逻辑，你会怎么设计？”——把问题场景化，看他能不能主动想到用装饰器这个工具。
不要问：“Python里深拷贝和浅拷贝有什么区别？”
要问：“a = [1, 2, [3, 4]]，b = a[:]，然后我执行b[2][0] = 999，你觉得a会变成什么？为什么？”——用一个具体的例子，让他解释背后的原理。这比背诵概念要深刻得多。
不要问：“什么是生成器？”
要问：“我们前面那个日志分析的题，如果日志文件有100G，你的脚本可能会有什么问题？怎么解决？”——逼着他去思考内存效率，自然而然地引出生成器和yield关键字。
把知识点融入到具体的场景里去“拷问”，才能看出他到底是真的理解了，还是只是背熟了面试题。
最终，你要找的，是一个拥有良好工程素养、具备强大问题解决能力、沟通顺畅、并且对技术抱有热情的“战友”。他可能记不住某个函数的具体参数，但他知道去哪里查；他可能没刷过某道偏门的算法题，但他能把一个复杂的业务需求拆解得明明白白，并用清晰、健壮的代码实现出来。
记住，面试的终极目标，是找到那个在凌晨三点系统崩溃时，你愿意打电话把他叫起来，并且相信他能和你一起搞定问题的人。这，才是怎么面试Python这个问题的最终答案。
评论(0)