我这些年面过大概两百个人，也被面过三十几次。有意思的是，我从面试题里学到的东西，大部分不是在准备面试的时候学的，而是在出题和听答案的时候学的。
下面挑四道题讲，每道题背后都有一个我认知被更新的瞬间。
题一：写一个函数判断字符串是否为回文
这题烂大街，我曾经觉得它毫无区分度。直到有一次，一个候选人写完之后问了我一句：
「回文的定义里，要不要忽略大小写和标点？中文的全角标点算吗？如果是 emoji 呢？」
我当时愣住了。因为我出这题两年，从没想过 emoji。
他接着解释：很多 emoji 是由多个码点组成的，简单按字符反转会把它拆坏。他现场演示了一下，一个带肤色修饰符的 emoji 反转之后变成了乱码。
那次之后我改了这道题的评分标准。我不再看代码写得对不对，而是看候选人有没有主动澄清边界。而我自己也学到一个具体的知识点：字符串反转在 Unicode 世界里根本不是一个简单操作。我后来在一个项目里处理用户昵称时，真的踩到了这个坑。
题二：如果一个接口变慢了，你怎么排查
这是我最爱的题，因为它没有标准答案，而且能听出一个人有没有真的在生产环境里干过活。
我听过的答案分三个层次：
- 背书型：「先看 CPU、内存、磁盘、网络。」说完就没了。这类答案通常来自没有真实经验的人。
- 经验型：会说具体工具和具体指标，比如「先看是不是所有接口都慢，还是只有这一个」。这个区分很关键，能问出这句话的人一定处理过事故。
- 结构型：极少数人会先建立框架。有个候选人说：「变慢只有两种可能，要么单次处理变慢了，要么排队了。我先看并发度和处理耗时，把这两个分开。」
最后那个答案我当场记在了本子上。它比我自己的排查方法更清晰。我后来处理事故时真的用上了这个二分法，好几次都直接命中。
面试的时候，最好的情况是候选人教了你东西。这种情况一年也就遇上两三次，但每次都值。
题三：设计一个短链服务
这是系统设计题，我出过大概三十次。
我发现一个规律：候选人的水平和他提问的时机高度相关。
水平一般的人上来就画架构图，画完我问一句「日均多少请求」，他答不上来。水平高的人第一句话是问业务量、读写比、链接有效期、要不要统计点击。
有一次一个候选人问：「短链需要防止被人枚举遍历吗？」这个问题我以前没想过。他解释说如果用自增 ID 转 62 进制，别人可以顺序遍历出所有链接，如果里面有私密内容就出事了。
这个点后来我在自己的项目里用上了。我们有个分享功能，我加了随机后缀，不是为了性能，就是为了防枚举。
题四：这段代码有什么问题（一段有并发 bug 的代码）
我给一段大约 20 行的代码，里面有个检查后再执行的竞态。
有意思的是，能看出问题的人大概占三成，但能说清楚怎么复现的不到一成。
大部分人说「这里有并发问题，加锁就行了」。我追问「怎么证明它有问题」，就卡住了。
这个现象让我反思了很久。我意识到我们这个行业有大量「知道但不会用」的知识——你知道有竞态，但你不会构造一个能稳定复现的测试。
我自己也是。所以后来我专门学了怎么写并发测试：用栅栏控制多个线程在同一时刻进入临界区，跑一万次统计不一致的次数。我第一次写出这种测试的时候，把我们项目里一段用了两年的代码测崩了——一万次里有 37 次结果错误。
三条总结
- 面试题的价值不在题目本身，在它逼出的对话。我现在出题都留大量的追问空间，宁可题目简单，也要能问下去。
- 被问倒的题一定要回去查。我被问倒过很多次，最狠的一次是被问「你说的这个索引失效，你怎么验证的」，我答不上来。回去之后我花了一晚上学执行计划，那一晚学到的东西比之前半年都多。
- 作为面试官，最该警惕的是「我知道答案所以我觉得这题简单」。我出过一道题，我自己觉得基础，结果二十个人只有两个答对。后来我承认，不是他们差，是我的题在考一个特别小众的细节。
最后说个自嘲的。我有一道题出了三年，标准答案是我自己写的。去年我在一个真实项目里遇到了同样的场景，我按自己的标准答案写，上线后出了问题——我的标准答案在数据量大的时候有内存问题。
我改了那道题的答案，也顺便提醒自己：面试官的答案也只是一个答案，不是真理。