自李博杰透露DeepSeek面试官指责他写代码作弊的风波传开后，众多程序员纷纷在网上分享自己的经历，称在应聘DeepSeek时都需要经历两轮极其严格的代码能力考核。
ID为“军哥程序员”的前阿里技术专家，在视频号上发布内容称，DeepSeek确实要进行双轮代码面试。该博主还补充道，DeepSeek的面试官几乎整个过程中都在关注代码相关问题，普通面试的时长更是达到70分钟之久。
过去十几年里，程序员面试逐渐演化出了一套成熟的对付策略。背题、刷题、共享面试经验，形成了一条龙服务模式，从几块钱的PDF资料到手握十几万的“包过内推”，市面上各种价位的服务应有尽有。只要投入足够的时间准备，想要进入知名公司并非难事。
然而DeepSeek的面试方式，彻底颠覆了这套常规。
你苦心背诵的内容，DeepSeek面试官并不会询问。你反复练习过的题目，面试中也不会出现。DeepSeek提问的那些问题，都需要你在实际工作中真正经历过，否则很难给出合理的答案。
这样的情况清晰地表明，DeepSeek坚持的是“代码即正义”的核心理念。
“代码即正义”在DeepSeek的体现
军哥程序员表示，面试官一上来就开启了摄像头，仅允许做了三四十秒的自我介绍，随后立刻以简历上的项目为切入点展开连环提问。
DeepSeek的面试官向军哥程序员提出了许多问题，每一道题目，都只有真正在一线工作的程序员才可能遇到。
挑选几个典型问题，剖析DeepSeek在招人时的考量逻辑。
“你的会话记忆采取的是message window还是token window？线上环境下选择的原因是什么？”
大型模型本身并不具备记忆功能，即便与它进行了二十轮对话，也不会自动记住第一轮聊天的内容。若要让模型“记住”之前的对话，就需要将历史消息重新发送给它。Message window按照消息条数存储，最近的N条消息全部保留；Token window则按照字数存储，在规定的字数范围内可以保存，超过字数限制的部分则会被截断。
看似简单，但实际上选择哪种方式取决于你的业务场景。如果是客服对话，通常轮次多但每轮内容较短，采用message window即可满足需求；如果是处理长文档或整个代码库分析，每轮的内容会非常长，这时token window将更为合适。
这个问题没有固定的标准答案，面试官真正关心的，是你选择该方案的理由，以及选择错误可能带来的后果。
“Redis进行持久化时，对于会话过期策略如何制定？”
用户与AI进行对话时，会话信息存放在Redis中。由于Redis的使用需要支付费用，因此其存储容量是有限的，不可能无限期保存。会话信息究竟应该保留多久？是用户半小时不发言就清除，还是保留七天？如果用户在一段时间后突然回来，发现之前的对话记录消失，会对使用体验产生何种影响？这些都是实际工作中才会遇到的问题，在开发demo时通常无需考虑。
这个问题在程序员圈内流传着一个颇具代表性的故事。有位运维或开发人员在crontab中设置了一条指令，目的是定期清理磁盘上的日志。该指令在每月30日凌晨执行一次清理操作。然而由于2月没有30日，导致了2月的数据没有被清理，最终在3月的某一天，由于日志累积过多，造成了磁盘空间被完全占满。
“是否处理过并发会话冲突的情况？”
这也是一个在应用中十分常见的问题。比如用户在手机APP上与DeepSeek进行了一半的对话，随后到公司打开电脑网页版DeepSeek继续进行。
虽然使用的是同一个账号，但手机端和电脑端都在向同一个会话写入消息。当手机端刚发送完“帮我修改一下这段代码”的请求时，电脑端可能已经开始读取之前的对话历史。
两个端的会话状态都在向Redis写入数据，是否存在互相覆盖的风险？手机端最后发送的消息，电脑端能否读取到？如果用户在两个端同时发送消息，上下文应该如何整合？是否存在读到无效数据的情况？
“长期记忆采用向量库进行存储，随着记忆量的增加，检索的准确性逐渐下降，应如何进行优化？”
这是考察候选人功底的难题之一。向量库存储的是将文字转换成的一串数字，通过数学相似度来寻找相关记忆。当向量库中只有几千条记忆时，检索准确性很高。但随着记忆条目增至几十万条，噪声记忆开始干扰，真正相关的记忆可能被排挤到靠后的位置。
这道题正是DeepSeek付费大模型在面试中考察的重点内容。
