[经验攻略] 技术面试官视角：离职原因别踩雷，从“敲击计数器”算法看边界思维

在网上看到一位HR分享的面试经历，让人感触颇深。他说上周面试一个技术岗位，前半小时聊得非常顺畅，无论是项目经验、技术栈匹配度都很好。

可当问到离职原因时，候选人的回答让他心里咯噔一下。对方说：“跟部门一个同事闹了矛盾，领导偏私，搞得每天上班很压抑，索性就走了。”

听到这样的理由，面试官恐怕心里已经画上了一个问号。我能理解候选人可能受了委屈，但真不建议在面试时如此直接地倒苦水。你是来争取一个新工作机会的，不是来参加吐槽大会的。

越是把前公司描述得鸡飞狗跳，面试官越容易产生不好的联想。尤其是在技术岗位，团队协作往往是关键。代码写得好是一回事，能否与他人顺畅合作又是另一回事。在成年人的职场里，有些委屈可以自己消化，有些真话则需要包裹一下再说出口。面试桌前的几分钟，比拼的远不止是技术能力，更是为人处世的分寸感。

面试题解析：敲击计数器

“敲击计数器”这类题目，表面看是简单的模拟，真正容易写乱的地方在于“边界条件”和“状态回退”的处理。

我第一次接触这类题时，脑海里浮现的不是某个具体的算法名称，而是一个很生活化的场景：一个人在不断敲击计数器，显示的值会变化，但有些操作并非简单的 +1，可能会触发重置、连续累加，甚至需要按规则忽略无效敲击。如果读题太快，很容易把“敲击动作”和“计数结果”混为一谈，最终代码写得冗长且难以维护。

处理这类问题，我通常不急于使用复杂的数据结构，而是先把核心状态定义清楚。无非就是几个变量：当前计数值、上一次敲击的时间（或类型）、是否连续、是否达到了某个阈值。一旦状态清晰了，剩下的就是按规则推进。

例如，我们可以将题意抽象为一种常见模型：输入一系列敲击的时间点，如果两次敲击的间隔不超过某个 limit，则视为连续敲击；当连续次数达到 k 时，计数器会额外增加一次。下面的写法就比一上来就堆砌 if-else 要清晰得多。

public int countHits(int[] times, int limit, int k) {
    if (times == null || times.length == 0) {
        return 0;
    }

    int total = 0;
    int streak = 1;
    total++; // 第一次敲击先记上

    for (int i = 1; i < times.length; i++) {
        if (times[i] - times[i - 1] <= limit) {
            streak++;
        } else {
            streak = 1;
        }

        total++; // 当前敲击本身算一次

        if (streak == k) {
            total++;   // 达到阈值奖励一次
            streak = 0; // 已结算，避免重复算
        }
    }
    return total;
}

这段代码的关键点不在于循环本身，而在于 streak = 0 这一行处理。很多人会下意识地写成 streak = 1，导致下一个连续段被重复计算。一旦题目带有“成组结算”的性质，这类细节就极易出错。

再比如，有些变种题中的“敲击计数器”不是基于时间，而是基于字符串输入，例如 A 表示敲一下，B 表示清零，C 表示双倍。这类题的本质依然是状态机，只不过状态从“连续次数”转换成了“当前数值”。

public int process(String ops) {
    int counter = 0;
    for (int i = 0; i < ops.length(); i++) {
        char op = ops.charAt(i);
        if (op == 'A') {
            counter++;
        } else if (op == 'B') {
            counter = 0;
        } else if (op == 'C') {
            counter *= 2;
        }
    }
    return counter;
}

这种写法并不花哨，但在实际线上排查问题时反而最稳健。因为你随时可以在循环中插入一行日志来观察状态变化：

System.out.println("i=" + i + ", op=" + op + ", counter=" + counter);

许多同学刷算法题久了容易陷入一个误区：总想着套用现成的模板。其实“敲击计数器”这类题目更像我们日常写的业务代码：处理输入的事件流，维护内部状态，并根据特定条件结算结果。它不一定涉及高深的算法，但特别考验你是否将题目规则拆解干净、思考全面。

我自己在练习这类题目时，通常会先手写三组测试用例来验证逻辑：

// 连续敲击
System.out.println(countHits(new int[]{1,2,3,7,8}, 1, 3));

// 全不连续
System.out.println(countHits(new int[]{1,4,7}, 1, 2));

// 刚好卡边界
System.out.println(countHits(new int[]{1,3,5}, 2, 2));

尤其是“刚好等于边界”的用例，最能检验代码中用的是 <= 还是 <。许多算法题的bug并非源于思路错误，而是边界条件顺手写错了。

所以，不要被“计数器”三个字迷惑。它考察的并非你是否会做加法，而是你能否将一系列规则稳定、无歧义地转化为Java代码。解题时，先列出所有可能的状态，再明确每次敲击后需要更新什么、在什么时机进行结算，代码自然就清晰了。真正的难点从来不在 for 循环怎么写，而在于你有没有把题目背后那点精巧的规则彻底想明白。这种对规则和边界的严谨思考，无论是在解算法题，还是在应对复杂的面试场景时，都至关重要。