[面试题] 技术骨干转型管理遇挫？从“灯泡开关”算法题看思维跃迁

一位年薪八十万的技术骨干，为了触及百万年薪的门槛，毅然选择竞聘团队负责人。然而半年过去，下属不服、领导不满，冲刺之路变得异常坎坷。这背后，究竟是能力问题，还是赛道选择之误？

这个话题在云栈社区也引发过不少讨论。有观点认为，技术强不等于会带人，写代码是单机游戏，带团队却是多人副本。更有人直言，团队领导最难的技能是背锅与沟通，解决技术BUG的难度反而要往后排。

这确实反映了一个现实：许多技术人将“升职”简单等同于“加薪”，实际上却是换了一条全新的赛道。你的核心任务从“自己把活干完”转变为了“带领别人把活干完”。想要冲击百万年薪，除了过硬的技术功底，开会控场、任务拆分、有效反馈、压力承载这些软技能必须同步点满。

当然，选择管理路径的优势也显而易见：你的影响力会被放大，能调动的资源更多，薪酬的上升空间也更大。但代价是，你必须花费大量精力学习与人打交道，此时，写得再漂亮的代码也不一定能帮你化解管理危机。

面试题：灯泡开关

那天加班到深夜，领导临走前丢过来一道题，说很简单：“灯泡开关，会不？顺手写一下。”办公室里只剩我和头顶那排惨白的日光灯，读罢题目，我不禁笑了——这描述简直和我租住的那条长走廊一模一样。

题目是这样的：一条走廊上有 n 盏灯泡，初始状态全部关闭。
第 1 轮，从第 1 盏开始，切换每一盏灯泡的状态（关变开，开变关）。
第 2 轮，从第 2 盏开始，每隔 2 盏切换一次。
第 3 轮，从第 3 盏开始，每隔 3 盏切换一次。
……
一直进行到第 n 轮。
问：最终有多少盏灯是亮着的？

你的第一反应是不是也和我一样？直接上双重循环，模拟整个过程，完事儿。我当时不假思索，敲出了一个最“直给”的暴力版本：

public class BulbSwitcherSlow {
    // 暴力模拟版，能跑但不建议上生产
    public int bulbSwitch(int n) {
        // false 代表关灯，true 代表开灯
        boolean[] bulbs = new boolean[n + 1]; // 从 1 开始方便一点

        for (int round = 1; round <= n; round++) {
            for (int i = round; i <= n; i += round) {
                bulbs[i] = !bulbs[i]; // 切换开关
            }
        }

        int count = 0;
        for (int i = 1; i <= n; i++) {
            if (bulbs[i]) count++;
        }
        return count;
    }

    public static void main(String[] args) {
        System.out.println(new BulbSwitcherSlow().bulbSwitch(10)); // 打个样
    }
}

跑个小数据，比如 n=10，结果正确。但我手欠，在本地试了一下 n = 100_000_000，风扇瞬间狂转，那声音立刻唤醒了当年给数据库做压测时的“ PTSD ”。冷静一算，这个解法的时间复杂度接近 O(n²)，如果面试时写出这个，考官大概会合上笔记本微笑着说：“下一位。”

我当时脑子有点木，就在办公室里踱步，顺便数头顶的灯。忽然想到：第 i 盏灯会在哪些轮次被按到？不就是所有 i 的约数对应的轮次嘛！比如第 6 盏灯，会在第1、2、3、6轮被切换。所以，一盏灯被切换的次数，就等于它的约数个数。

关键推论来了：只有被切换奇数次的灯，最终才会亮着。

问题瞬间转化了：1 到 n 之间，哪些数字的约数个数是奇数？
这时，尘封的小学数学知识开始攻击我：一个数的约数通常是成对出现的。例如 12：

• 1 和 12
• 2 和 6
• 3 和 4
  看，都是成双成对，所以约数个数通常是偶数。那么，什么情况下约数个数会是奇数呢？只有当有一对约数其实是同一个数，即这个数是完全平方数的时候。比如 9：
• 1 和 9
• 3 和 3 （3只算一次）
  因此，只有完全平方数的约数个数是奇数。

所以，第 i 盏灯最终是否亮起，就取决于 i 是不是完全平方数。那么，1 到 n 之间有多少个完全平方数？答案就是 floor(√n)，即 √n 向下取整。

想通这一点，我立刻删掉了之前那坨循环，写出了一个简洁到极致的 Java 解法：

public class BulbSwitcher {
    // 正解版：O(1) 时间复杂度
    public int bulbSwitch(int n) {
        // 强转一下就行了，Math.sqrt 返回的是 double
        return (int) Math.sqrt(n);
    }

    public static void main(String[] args) {
        BulbSwitcher s = new BulbSwitcher();
        System.out.println(s.bulbSwitch(3));   // 结果 1 -> 只有灯 1 亮
        System.out.println(s.bulbSwitch(10));  // 结果 3 -> 1,4,9 亮
        System.out.println(s.bulbSwitch(9999)); // 心里有数就行
    }
}

写完我自己都乐了。折腾半天，核心代码就这一行：

return (int) Math.sqrt(n);

其他的铺垫，仿佛都是为了证明“我曾经努力思考过”。

这类面试题往往带点“狡猾”。它先抛给你一个看似需要模拟的工程问题，诱导你往暴力求解的方向走。但面试官真正期待的，是你那个“等等，这好像不对”的停顿瞬间——考察你能否从“动手编码”切换到“本质思考”，从“操作灯泡”抽象到“数论规律”。这种思维上的跃迁能力，有时比写出无BUG的代码更为重要。无论是解决算法问题，还是应对从技术到管理的角色转变，都需要这种跳出固有框架、洞察问题本质的能力。