上午面试完了，下午给候选人发offer，晚上就被拒了，原因是部门负责人的朋友圈全是凌晨下班的小作文

刚看到个帖子，说上午面完试，下午火速发offer，结果晚上就被候选人拒了，理由是看到部门负责人的朋友圈全是凌晨下班的“小作文”。

我觉得这事吧，从程序员角度很能理解。代码可以熬夜写，但人不可能一直当机器跑。朋友圈其实就是团队文化的“源码”，候选人一扫就能预判未来的生活：加班常态化，写Bug和写周记一样频繁，那谁还敢接手？

网友们有的觉得候选人太玻璃心，但我反而觉得他挺理智。面试时再怎么说“弹性工作制”，朋友圈一翻就全暴露，信息差瞬间消失。这就像我们看开源库的issue列表，文档写得再漂亮，真正的稳定性要看社区怎么吐槽。

从我的角度看，招人其实跟写程序一样，代码要可维护，团队要可持续。天天凌晨写小作文，不是努力，而是设计缺陷。要留人，得先优化制度，而不是怪候选人太挑。 【备注:文末可领最新资料】

面试题：记忆函数

昨天晚上十一点多在公司楼下等代驾，手机电量红到发慌，一个同学还在问“为啥我这递归老超时啊”。我就随口说，别硬算了，用“记忆函数”——就是把算过的结果先存起来，下次碰到同样的输入，直接拿。听着有点像偷懒，但在算法里这是正道。

你可以把复杂函数想成“问题 → 子问题”的拆解。递归会不停地重复同样的子问题，比如斐波那契 F(n)=F(n-1)+F(n-2)，有一堆重复分支。记忆函数（memoization）做的事很朴素：用个字典当小本本，键是输入，值是结果。命中过就不算了，时间复杂度立马从指数级降到线性级，代价是多了一点空间。

我一般就两种：手写 dict，或者 Python 自带的 functools.lru_cache。手写灵活，能控制清空与键格式；lru_cache省心，还带容量上限。

# 手写 dict 版
deffib(n, memo=None):
if memo isNone:
        memo = {}
if n < 2:
return n
if n in memo:
return memo[n]
    memo[n] = fib(n-1, memo) + fib(n-2, memo)
return memo[n]

# lru_cache 版，一行搞定缓存
from functools import lru_cache

@lru_cache(maxsize=None)  # None 表示无限，或给个上限防爆内存
deffib2(n):
if n < 2:
return n
return fib2(n-1) + fib2(n-2)

你们看，思路就那点：先查缓存，有就直接回；没有才递归算出来，再塞回缓存。

斐波那契太教材味儿。来个实际一点的：棋盘从左上走到右下，障碍用1表示，空地0表示，只能向右或向下，问路径数。暴力 DFS 会爆炸，记忆函数稳住它。

defcount_paths(grid):
    m, n = len(grid), len(grid[0])
    memo = {}

defdfs(i, j):
if i >= m or j >= n or grid[i][j] == 1:
return0
if i == m - 1and j == n - 1:
return1
        key = (i, j)
if key in memo:
return memo[key]
        memo[key] = dfs(i+1, j) + dfs(i, j+1)
return memo[key]

return dfs(0, 0)

这个写法的体验就像开导航：走过的路口（(i,j)）存一次，后面再来直接复用，不会反复绕圈。

我得提醒两句，省得半夜再来问我。第一，参数必须可哈希且能唯一标识状态，像列表、字典这种可变对象当键会报错；要么转成 tuple，要么序列化。第二，递归深度太深会栈溢出，Python 默认栈就那点儿，必要时把记忆函数换成自底向上的 DP。

# 记忆函数换成迭代 DP（以斐波那契为例）
deffib_iter(n):
if n < 2:
return n
    a, b = 0, 1
for _ in range(2, n+1):
        a, b = b, a + b
return b

记忆函数的心法其实只有一句：用空间换时间，把“重复子问题”的结果缓存起来。写法上你随意：手写 dict 更灵活，lru_cache 更省事；遇到状态描述复杂的题，先想清楚“键怎么唯一化”，实在递归太深就改迭代。