北京的 offer已经逆天到这个地步了吗?干脆写50w年薪，49万绩效好了。。。
python约 3 分钟L7，总监，年薪写着35万，乍一看像是北京互联网又开始卷王大战了。结果再往下一扒，基本工资2650，真就离谱到有点幽默了。HR这表一发出来，候选人估计先愣三秒，再怀疑自己是不是看到了实习生工资条。
评论区也挺损，有人说这不就是“高薪全靠想象，落地全看绩效”；还有人说干脆别写35万了，直接写50万年薪，49万算绩效，大家都省事。话糙理不糙，这种offer最骚的地方就在这儿，名头给很大，包裹也给你包得挺圆，一拆开发现固定部分瘦得像在减脂。
北京offer现在有些真不是谈薪，是玩文字游戏。尤其总监这种岗位，工资结构还能切成这样，说白了就是把风险往员工身上甩。你去上班，老板先把饼烙好，至于能不能吃上，那得看年底脸色。
算法题：单词的唯一缩写
这个题一上来最容易写歪的地方，不在哈希表，也不在字符串截取，在“唯一”两个字。
很多人第一反应是：把每个单词都缩写一下，再看有没有重复。代码三分钟能写完，提交大概率也能过一部分。但这题真正别扭的地方是，缩写相同不一定冲突，前提是它们原本就是同一个单词。这类判断，我一般先把规则掰直，不然越写越乱。
题目的缩写规则很简单： 单词长度小于等于 2，缩写后还是自己。 比如 it -> it，dog -> d1g，international -> i11l。
先写个最小的缩写函数，别一上来堆进类里，单独拎出来更容易查：
defabbr(word: str) -> str:
if len(word) <= 2:
return word
returnf"{word[0]}{len(word) - 2}{word[-1]}"
这题常见做法是先预处理字典。 我的习惯不是直接记“某个缩写出现了几次”，而是记成“某个缩写对应哪些原单词”。因为后面判断唯一性的时候，你会发现只看次数不够顺手，集合更直观。
from collections import defaultdict
classValidWordAbbr:
def__init__(self, dictionary: list[str]):
self.mp = defaultdict(set)
for word in dictionary:
self.mp[abbr(word)].add(word)
defisUnique(self, word: str) -> bool:
s = self.mp.get(abbr(word), set())
returnnot s or s == {word}
这段代码不长，但判断顺序得看清楚。
比如字典里没有这个缩写，那它当然唯一。 比如字典里有这个缩写，但集合里只有它自己，那也算唯一。 真正不唯一的是：同一个缩写下面挂了别的单词。
拿一组数据过一下就很清楚：
obj = ValidWordAbbr(["deer", "door", "cake", "card"])
print(obj.isUnique("dear")) # False, d2r 已经被 deer 和 door 占了
print(obj.isUnique("cart")) # True, c2t 没人占
print(obj.isUnique("cake")) # True, 缩写相同，但字典里就是它自己
print(obj.isUnique("door")) # False
这里还有个坑，字典里可能有重复单词。 如果你用列表或者计数，["cake", "cake"] 这种数据容易把自己绕进去；用 set 一下就干净了，这也是上面我为什么不太愿意直接记次数。
时间复杂度也比较实在。初始化扫一遍字典，设总单词数是 n，那就是 O(n)；每次查询就是一次缩写计算加一次哈希查找，基本可以看成 O(1)。