从北京L7总监Offer看“大饼式”薪资结构：算法题“单词缩写”的解题启示

L7、产品技术部总监，抬头一看挺像那么回事，结果年薪35万一拆，基本工资才2650，差点以为自己看错小数点。剩下全靠津贴、绩效、年度考核往上垫，这种offer看着像年包，细看像拼多多砍出来的。

评论区也挺损，有人说这不是招总监，这是招“背锅侠体验官”；还有人说干脆直接写50万年薪，49万看绩效心情发，大家都省事。我看完就一个感觉，北京有些公司是真会写字，账面上给你架得很高，落到手里全是条件、系数、考核、执行标准。

最逗的是“总监”这俩字，HR发出来估计自己都得顿一下。名头给足，安全感不给。真接这种offer的人，入职前最好先把绩效规则问明白，不然后面不是当总监，是当算盘。

扯完Offer，正好想起一道经典的面试题：单词的唯一缩写。

这题要是只盯着“缩写怎么生成”，很容易写成字符串题。真上手一写，坑其实在判重。

题目里那个缩写规则不复杂：单词长度小于等于 2，缩写还是它自己；长度大于 2，就变成 首字母 + 中间省略的字符数 + 末字母。比如 deer -> d2r，door -> d2r，cake -> c2e。麻烦的是，给你一个字典，再给一个单词，问这个单词的缩写是不是“唯一”的。这里的“唯一”不是说字典里没有同样的单词，而是说字典里所有别的单词，不能跟它缩写撞车。

这个地方我第一眼就不太信暴力。因为很多人会顺手这么写：每次判断都把字典扫一遍，把每个词缩写出来比一下。能过，但代码味道不对，查询一多就开始肉眼可见地慢。

这题更顺手的写法，是先把字典按“缩写”聚起来。后面判断时只看这个缩写对应的集合里有什么。

看Java代码：

import java.util.*;

public class ValidWordAbbr{
    private final Map<String, Set<String>> abbrMap = new HashMap<>();

    public ValidWordAbbr(String[] dictionary){
        for (String word : dictionary) {
            String abbr = abbr(word);
            abbrMap.computeIfAbsent(abbr, k -> new HashSet<>()).add(word);
        }
    }

    public boolean isUnique(String word){
        String abbr = abbr(word);
        Set<String> words = abbrMap.get(abbr);

        if (words == null || words.isEmpty()) {
            return true;
        }
        return words.size() == 1 && words.contains(word);
    }

    private String abbr(String word){
        if (word == null || word.length() <= 2) {
            return word;
        }
        return "" + word.charAt(0) + (word.length() - 2) + word.charAt(word.length() - 1);
    }

    public static void main(String[] args){
        ValidWordAbbr tool = new ValidWordAbbr(
            new String[]{"deer", "door", "cake", "card"}
        );

        System.out.println(tool.isUnique("dear")); // false
        System.out.println(tool.isUnique("cart")); // true
        System.out.println(tool.isUnique("cake")); // true
        System.out.println(tool.isUnique("door")); // false
    }
}

这里有两个点别漏了。

一个是字典去重。比如字典里同一个单词出现两次，你要是用 List 存，后面判断 cake 可能会被自己坑了。所以我这里直接上 Set，重复单词天然去掉。

另一个是 isUnique("cake") 这种情况。虽然字典里有 cake，但如果这个缩写下面只有它自己，那也算唯一。很多人把“字典里存在”直接判成 false，这题就写歪了。

时间复杂度也很干净：初始化把字典扫一遍，设字典长度是 n，就是 O(n)；每次查询走一次哈希表，基本就是 O(1)。这种题没必要卷花活，核心就是把“查询时现算”改成“构造时预处理”。

这类题我一般就看两件事：一是规则有没有边界，二是“唯一”这种字眼到底是对谁唯一。规则本身不难，难的是别把题意想当然。字符串题很多都这样，看着像拼接，实际是在考你怎么建索引。

说到底，不管是看Offer还是刷算法，都得看清“实际构成”和“判定规则”，别被表面的名头和描述唬住了。想了解更多真实职场生态和技术干货，可以逛逛云栈社区。