跳槽到下家工资涨了8000，结果入职当天老板说:挖你的人把你夸得天花乱坠!你要好好干，不然对不起高工资。

刚看到个贴子，说有网友爆料：同事跳槽后工资直接涨了8000，结果入职第一天，老板一句话先敲下来——当初挖你的人把你夸得太狠了，你得对得起这个价。

贴子本身不复杂，但挺扎心。说白了，高薪从来不是白给的，更像一张“预期支票”。钱一多，期待值立马拉满，容错空间反而更小。

网友回帖里有人替这位同事捏把汗，觉得这是下马威；也有人说很正常，拿高工资就得扛高压力。我倒是觉得，两边都没说错。

怎么说呢，跳槽涨薪本质就像坐地铁换快线，确实快，但站得也更挤，一点不稳就容易被盯上。

我的看法是，涨薪本身不是问题，问题在于别把“被夸”当成真本事。职场里，能力要经得起反复验证，不是一次面试就定终身。老板这话听着刺耳，其实也在提醒：钱给到了，舞台也给了，剩下就看你能不能站住。

先说个小场景哈。昨天晚上十一点多，我在公司楼下等外卖，手机刷着某音，系统给我推了个“你可能认识的人”，说是“二级好友”，然后我脑子一抽：这不就是算法题里的“二级关注者”嘛，干脆拿这个例子给你们讲一下，顺便用 Python 写个小而全的解法。

你可以先这么想：在一个关注系统里，A → B 表示 A 关注了 B。现在给你一个用户 u，问题是：有哪些人，属于“二级关注者”？我这里的定义说慢一点啊： 一级关注者：所有“直接关注 u 的人”，也就是所有满足 x → u 的用户 x。 二级关注者：所有“关注了这些一级关注者的人”，也就是所有满足 y → x 的用户 y，其中 x 是一级关注者。

有点绕？你脑子里可以画个图： 别人 → 你，是第一圈； 别人 → 别人 → 你，是第二圈，这第二圈的人就是“二级关注者”。现实里产品喜欢拿这个做“你可能认识的人”“扩散范围”等等，之前我写数据库那篇性能对比的时候也顺手算过类似的关系网。

落到代码上，最关键的一步就是：怎么存这些“谁关注了谁”。一般我们会把关系表给成一堆边 (a, b)，意思是 a 关注 b。如果我要根据“被关注的人”找“粉丝”，就得建一个“被关注 -> 粉丝列表”的表，也就是所谓的“反向邻接表”。这样给定一个人 u，我直接查 followers[u] 就能拿到所有一级关注者。

用 Python 写一下这个结构，顺手把二级也搞出来，代码大概长这样：

from collections import defaultdict

defsecond_level_followers(n, edges, target):
"""
    n: 用户总数（其实用不用都行，看你要不要做校验）
    edges: 关注关系列表 [(a, b), ...]，表示 a 关注了 b
    target: 目标用户 id
    """
# followers[x] = 所有关注 x 的人
    followers = defaultdict(list)
for a, b in edges:
        followers[b].append(a)

# 一级关注者：直接关注 target 的人
    first_level = set(followers[target])

# 二级关注者：关注了这些 first_level 的人
    second_level = set()
for x in first_level:
for y in followers[x]:
# 去掉自己，顺便可以去掉已经是一级关注者的
if y != target and y notin first_level:
                second_level.add(y)

# 一般面试题会让你返回有序结果，方便对比
return sorted(second_level)


if __name__ == "__main__":
# 举个小例子
    n = 6
    edges = [
        (2, 1),  # 2 关注 1
        (3, 1),  # 3 关注 1
        (4, 2),  # 4 关注 2
        (5, 2),  # 5 关注 2
        (6, 3),  # 6 关注 3
    ]
    print(second_level_followers(n, edges, 1))  # 输出: [4, 5, 6]

你看这个例子就挺直观的： 关注 1 的人是 2 和 3，这俩是一级关注者。 关注 2 的是 4、5，关注 3 的是 6，这三位就成了 1 的二级关注者 [4,5,6]。逻辑非常生活化，就跟朋友圈“朋友的朋友”一个意思，跟我以前写的 MQ 扩散场景其实是同一个图论模型，只是那边是消息流，这里是关注关系。

顺手说一下复杂度，别看题简单，该交的作业还是要交的。假设有 N 个用户，M 条关注关系。建 followers 这一步是把每条边看一眼，复杂度是 O(M)；之后找一级关注者，很快；枚举所有一级关注者的粉丝，总的访问次数不会超过边数的一部分，所以整体也就是 O(M) 级别，加上 O(N) 的一点点 set 存储空间，正常社交图都挺扛打的，比我之前排查 TCP 1024 字节那个诡异 Bug 轻松多了。

有几个边角情况，面试官有时候会顺嘴问两句，你提前想好就不慌： 如果目标用户没人关注，那一级集合就是空的，二级自然也是空的，代码里 followers[target] 会直接给个空 list，这时候 first_level 是空 set，for 循环不会进，最后返回空数组，刚好符合预期。 如果有人既是一级又是二级，比如 A 关注你、B 关注 A、你又关注 B，这种环状结构，你要不要把 A 算进二级？上面代码里我明确排除了“已经是一级的”用户，你要是业务上觉得可以重复算，那就把 y not in first_level 那个判断删掉就行。

再多嘴一句实现层面的坑。有些同学一上来就说“我要 BFS，两层遍历”，然后写了个队列，里面不仅塞用户，还塞一个“当前层数”，写着写着就跟树的层序遍历一样，逻辑一下复杂好几倍。这个题其实没那么玄学，二级一共就两圈，你像我这么拆成“先算一级，再算一级的粉丝”就够了，代码短，出 bug 的概率小，上线的时候也不至于半夜被电话叫醒。

-END-

我为大家打造了一份RPA教程，完全免费：songshuhezi.com/rpa.html

虎哥作为一名老码农，整理了全网最全《python高级架构师资料合集》，总量高达650GB