北京字节跳动科技有限公司校招技术岗面试经验——求职精灵（finsight.work）

回答框架：一段式自我介绍 + 三个选择理由，每个理由都要有具体事实，最后落到你能贡献什么。

1. 背景：我是计算机专业本科/硕士，技术方向是 Java 后端与分布式系统，做过一个实时日志分析项目，日均处理百万级日志。
2. 技术契合：项目里深度用过 Kafka 与 Redis，字节的后端正是大规模消息队列与缓存的重度场景，我希望在更大流量下验证自己的技术判断。
3. 产品认知：我是抖音深度用户，研究过它的推荐从协同过滤到双塔召回再到多目标排序的演进，这种数据驱动的迭代方式很吸引我。
4. 文化认同：字节强调直接沟通、快速迭代，我在项目里也习惯把问题摆到桌面上讨论，不等指令。
5. 收尾：我希望能先在业务里把工程能力打扎实，再往链路优化或稳定性方向深入。

回答框架：结构 → 插入流程 → 扩容 → 线程安全 → ConcurrentHashMap 的改进，按这条线讲不会乱。

1. JDK8 的结构是数组 + 链表 + 红黑树。插入时先对 hash 做高低位异或扰动，再与 n-1 做与运算定位桶。
2. 桶为空直接插入；冲突则追加链表；链表长度超过 8 且数组长度不小于 64 时转红黑树，查询从 O(n) 降到 O(log n)。
3. 扩容：默认负载因子 0.75，容量翻倍，元素要么留在原位置，要么移到「原位置 + oldCap」，不需要重新计算 hash。
4. 线程安全：HashMap 并发扩容在 JDK7 可能形成环形链表，JDK8 改尾插后仍有数据覆盖问题。
5. ConcurrentHashMap 在 JDK8 放弃分段锁，用 CAS 加 synchronized 只锁单个桶，读操作靠 volatile 不加锁，锁粒度更细、并发度更高。

收尾：如果面试官继续问 size 统计，可以补 CounterCell 分段计数的设计。

回答框架：现象 → 工具定位 → 根因 → 方案对比 → 结果，重点在定位过程，不要一上来就讲怎么改。

1. 项目是实时日志分析系统，数据量约每分钟一百万条。上线后接口 P99 达到 3 秒，远超目标。
2. 定位：用 Arthas 的 trace 逐层看调用链，发现 85% 的耗时集中在一个聚合查询上。
3. 根因：EXPLAIN 显示虽然建了索引，但条件里用了 LIKE '%keyword%'，前置通配符导致索引失效，全表扫描了三百万行。
4. 方案对比：引入 Elasticsearch 能根治，但会增加运维成本与开发周期；改造查询逻辑改成后缀匹配，再对高频结果加 Redis 缓存，成本更低。最终选择后者。
5. 结果：P99 从 3 秒降到 200ms 以内。复盘：先确认瓶颈再选工具，不要一遇到慢查询就上 ES。

先确认条件：数组非空，K 满足 1 ≤ K ≤ 数组长度；「第 K 大」按从大到小排序后的第 K 个，重复元素按位置计。
思路一，小顶堆：维护大小为 K 的堆，堆顶就是当前第 K 大，时间 O(n log k)，空间 O(k)，适合数据流或 K 较小的场景。

public int findKthLargest(int[] nums, int k) {
    PriorityQueue<Integer> heap = new PriorityQueue<>(k);
    for (int x : nums) {
        heap.offer(x);
        if (heap.size() > k) heap.poll();
    }
    return heap.peek();
}

思路二，快速选择：以基准分区，只递归包含第 K 大的那一侧，平均 O(n)，最差 O(n²)，适合静态数组且 K 任意。
思路三，直接排序 O(n log n)，实现最简单，面试中可以作为兜底先说出来。
追问「数据流不断进来怎么办」：小顶堆是标准解，堆大小固定为 K，内存可控；如果要支持重复值，堆里存原值即可，不需要去重。

这是上一题的常见追问，回答要落到「取模等价」和「扩容拆分」两个点上。

1. 定位桶时用 (n - 1) & hash 代替 hash % n。当 n 是 2 的幂时，n - 1 的二进制全是 1，与运算等价于取模，但位运算更快。
2. 全 1 的掩码能让 hash 的低位均匀参与定位，减少冲突；如果 n 不是 2 的幂，掩码会出现 0 位，部分桶永远用不到。
3. 扩容时容量翻倍，元素的新位置只取决于 hash 在新增高位上是 0 还是 1：0 留在原索引，1 移到「原索引 + oldCap」，不需要重新计算 hash，也不用遍历整张表重排。
4. 这也解释了为什么构造时可以指定初始容量，内部仍会向上取整到 2 的幂。
5. 代价是容量不够灵活，可能浪费部分空间，但换来的是定位与扩容的稳定性能。

追问「为什么负载因子是 0.75」：是在空间利用率与冲突概率之间的折中，太低浪费内存，太高链表变长、查询退化。

回答框架：先给判断标准，再区分两类加班，然后用经历证明你能扛，最后说自己的效率方法。

1. 我的态度是：加班本身不是问题，低效才是问题。
2. 字节节奏快是公开事实，我在投递前做过了解，也有心理准备。项目上线、攻克难题这种有明确目标的阶段，我不介意高强度投入，因为每天都有实质进展。
3. 但如果加班来自计划不合理、会议低效或优先级反复，我会先提优化建议，而不是用时间硬堆。
4. 我在项目里习惯每天收尾时列次日三件最重要的事，把最难的工作放在精力最好的时段，尽量把被动救火变成主动排期。
5. 所以我的答案是：需要冲刺时能顶住，平时把效率做扎实，不让加班成为常态。