今天想认真聊聊星环科技2024届秋招笔试的A卷编程题。我是在秋招投递大数据平台研发方向时做的这套卷子，考完之后最大的感受是：题目本身不算偏难怪，但“务实”程度非常高，很多题一眼就能看出是从他们自己业务场景里抽象出来的，和平时在LeetCode上刷到的经典题型有微妙但关键的区别。这份复盘我会尽量完整还原题型结构、核心题目的解题思路，以及我当时踩过的判题系统的坑，给接下来准备星环笔试的同学一个清晰的地图。
先说结论放前面：星环A卷的编程题部分，重点不在算法竞赛级别的奇技淫巧，而在于三类能力——第一类是快速建模、把业务描述转化成数据结构的能力；第二类是字符串处理和状态模拟的细心程度；第三类是对时间复杂度的敏感度，他们的数据规模卡得很紧凑，不会给你用暴力解法蒙混过关的空间。
1. 今年A卷的整体结构：题型分布和分值逻辑
1.1 题型构成与时间分配
整个A卷在线作答时间120分钟，实际构成是选择题（约20道）+ 两道编程题 + 一道SQL题。这里要先纠正一个误解：星环的笔试虽然叫“编程题A卷”，但前面选择题的比重相当大，而且选择题不全是纯基础八股，会有不少结合场景的灵活性题目，这个在后文重点展开。
分值权重上，两道编程题各占20分左右，SQL题占15分左右，其余分值分散在选择题。这意味着什么？就是如果你选择题靠蒙、编程题AC了一道半，最后的分数很可能还是不够进面试。我身边有同学是算法题全AC了但选择题崩了，最后依然没收到面试通知。所以备考时绝对不能只盯算法题忽略基础。
120分钟的时间分配，我当时的策略是：选择题最多45分钟，编程题第一道控制在25分钟搞定，第二道留40分钟以上，最后留10分钟检查。两道编程题里通常会有一道相对简单、一道较难，千万不要在第一道题上死磕到20分钟还没思路，就果断跳过做后边的，因为第二道题往往是区分度所在，多拿部分测试点分数比第一道题全AC的边际收益更高。
1.2 今年A卷题目场景的变化趋势
和往届对比，2024年A卷编程题场景有两个显著变化：一是大数据组件相关的背景题比重上升，比如出现了分布在海量日志中的特征统计、任务执行依赖调度这类场景；二是字符串/文本处理型题目明显增多，这和星环做数据治理、SQL解析的业务方向是呼应的。
另一个值得注意的趋势是题目给出的数据规模描述更“诚实”了，比如会明确告诉你“日志条数不超过10^6，单条日志长度不超过1000”，这些数值不是白给的，直接决定了你的算法选型。如果你用O(n*m)的复杂度去匹配两个10^5级别的数据集，基本等不到超时，判题平台在构造测试数据时就会把你的错误解法卡掉。
2. 编程题第一道：日志数据解析与聚合——典型的“模拟+哈希”场景题
2.1 题目模型还原
我印象里A卷第一道编程题的大意是这样的（题目有NDA约束，这里只还原题型模型，不做原文复述）：给出一批来自分布式系统的操作事件日志，每一行包含时间戳、节点ID、操作类型（读/写/删除），需要统计指定时间窗口内，每个节点上执行次数最多的操作类型，并按照节点ID从小到大输出。
看起来很基础对吧？但这道题的实际通过率并不高。核心难点在于三处：日志顺序是乱序的，时间窗口可能是跨小时的（如15:59到16:01），而且要求输出次数最多操作类型，存在并列时按操作类型的字典序输出。
这类题之所以放在第一道，考察的就是两件事：第一，你能不能快速用哈希表建好“节点ID -> 操作类型 -> 次数”的映射；第二，你能否处理窗口边界不落入“简单遍历”陷阱。
2.2 完整解题步骤：从建表到排序输出
我用Python给出核心代码骨架，这是我在笔试时验证过可AC的实现思路：
from collections import defaultdict import sys def parse_log_line(line): parts = line.strip().split() timestamp = parts[0] # 格式：2024-09-15 15:59:30 node_id = parts[1] op_type = parts[2] # Read / Write / Delete return timestamp, node_id, op_type def time_to_minutes(ts): # 将时间戳转换为当天第几分钟，方便做窗口比较 hh, mm, ss = map(int, ts.split(' ')[1].split(':')) return hh * 3600 + mm * 60 + ss def solve(logs, window_start, window_end): stat = defaultdict(lambda: defaultdict(int)) start_min = time_to_minutes(window_start) end_min = time_to_minutes(window_end) for line in logs: ts, node, op = parse_log_line(line) cur_min = time_to_minutes(ts) if start_min <= cur_min <= end_min: stat[node][op] += 1 result = [] for node in sorted(stat.keys()): ops = stat[node] max_cnt = max(ops.values()) # 按操作类型字典序取最小者，处理并列情况 best_op = min(op for op, cnt in ops.items() if cnt == max_cnt) result.append((node, best_op, max_cnt)) return result这段代码的优化空间其实很大，笔试时我用了字符串直接比较时间戳，避免解析成整数，因为题目给定的时间戳格式是定长的，字符串字典序等价于时间先后顺序，能省不少事。这里我只写了解析版本为了更易读，实际提交时建议直接用字符串切片。
2.3 判题系统在这个题上的隐藏测试点
这一题的隐藏测试点有几个值得注意：
- 时间窗口的起止时刻都在日志中出现过吗？如果没有，要保证窗口比较逻辑用
<=而非<。 - 窗口内的节点在某个操作类型上一次都没出现过，但其他节点有，这时输出要不要包含该节点？答案是不包含，因为“无操作”不该被输出，这是我试错试出来的。
- 并列情况如果理解错“按字典序最小输出”，会挂掉至少2个测试点。题目描述是“如果次数相同，输出字母序小的操作类型”。
这一题整体难度不高，但AC率不理想的原因在于很多同学把时间直接split(":")转成整数后就忘了恢复原格式，或者没有考虑跨天（虽然题目限制了同一天，但边界值测试里仍然可能出现00:00:00）。
3. 编程题第二道：任务依赖下的最大并行执行时间——拓扑排序的实战变体
3.1 题目场景底层逻辑
第二道编程题才是真正的分水岭，场景是这样的：数据平台上有N个数据处理任务，任务之间存在依赖关系，比如任务B依赖任务A的输出，每个任务有一个预估执行耗时。现在假设有无限并行计算资源，凡是没有未完成依赖的任务都可以立即开始执行，要求计算完成全部任务的最短时间。
这题本质上是带权拓扑排序的最早完成时间问题。如果你了解关键路径这个概念——项目管理里的“最短完成时间”依赖于最长依赖链——那么这题就是一个套了业务壳的关键路径长度求解。
为什么星环会考这类题？因为他们的产品线里有大量工作流调度、任务编排的场景，分布式环境下DAG（有向无环图）调度是基础中的基础。
3.2 解法推导：为什么答案是“最长路径和”
很多同学看到“并行执行”就会想成贪心，比如按拓扑序先后把任务扔进时间轴。但要注意：无限并行意味着所有任务只要入度为零就可以同时开始，所以某个任务的完成时间 = max(所有依赖它的前驱任务的完成时间) + 自身耗时。最终的整批任务完成时间则是所有任务完成时间中的最大值，本质上就是DAG中从任一入度为零的节点到任一出度为零的节点的最大路径权重和。
这个结论我直接用反例验证一下：任务A耗时10，任务B耗时1且依赖A，任务C耗时1且依赖A。如果贪心认为“最早能开始的任务耗时长，应该先安排”，那就完全错了——并行资源下任务A同时决定B和C的启动时间，总完成时间永远是11（如果在初始化上再加一个虚拟源点，则虚拟源点耗时0）。
3.3 基于拓扑排序的动态规划实现
给出一版完整的可AC代码：
from collections import deque import sys def min_completion_time(n, edges, costs): """ n: 节点数，节点编号从0到n-1 edges: 依赖边列表，[(pre, nxt), ...] costs: list[int], 每个任务的执行耗时 """ graph = [[] for _ in range(n)] indeg = [0] * n for pre, nxt in edges: graph[pre].append(nxt) indeg[nxt] += 1 # dp[i] 表示任务i的最早完成时间 dp = [0] * n q = deque() for i in range(n): if indeg[i] == 0: q.append(i) dp[i] = costs[i] visited = 0 while q: u = q.popleft() visited += 1 for v in graph[u]: dp[v] = max(dp[v], dp[u] + costs[v]) indeg[v] -= 1 if indeg[v] == 0: q.append(v) # 一般题目保证无环；如果不保证，visited < n 说明有环 return max(dp) if visited == n else -1关键点在于dp[v] = max(dp[v], dp[u] + costs[v])——只有当v的所有前驱都处理完毕，dp[v]才会收敛到正确值，因为这依赖于所有入度边上的贡献都被max比较过。
这里有一个非常隐蔽但致命的细节：题目里如果存在多个入度为零的任务，它们可以同时开始，所以初始时把所有源点的dp设为costs是合理的。但如果题目给的是“只能同时执行K个任务”（有限并行度），模型就完全不同了，退化成带资源约束的调度问题，那就不是拓扑排序能解的了。我看到好几个同学把“无限并行”理解成了“有限并行”，然后试图用贪心模拟时间轴，白白浪费了大把时间。
3.4 判题数据的边界陷阱
这个题我提交了三次才完全通过，前两次都是因为边界处理问题：
- 独立任务链：一条链上1->2->3->4，每个耗时都很大，正确答案是所有耗时之和。
- 多入度节点：节点0和节点1都指向节点2，节点3指向节点2，那么dp[2]必须取三者中耗时最长路径，而不是仅仅max(直接前驱)。
- 环检测：题目虽然声明DAG，但测试里很可能包含一个带环用例来验证你的容错。如果你不判断
visited == n直接返回max(dp)，遇到环就会返回一个错误的偏大值。
我在笔试时还犯过一个低级错误：costs数组在初始dp赋值后，我又在循环里重复加了一次costs[v]，导致所有路径耗时变成了两倍。这种低级错误需要靠最后的自测数据来防住。
4. SQL题专项：多表关联与窗口函数的考察方式
4.1 星环SQL题的特色
星环作为一家以数据库和大数据平台为核心产品的公司，笔试中的SQL题考察方式和互联网大厂有区别。互联网大厂常见的SQL题是单表查询、聚合、子查询居多，星环的SQL题更偏向多表关联、窗口函数、以及数据质量维度的处理，比如去重、填充缺失值、识别重复记录这类实际数据仓库ETL里的常见操作。
我回忆这道SQL题大致的业务场景是：订单表、用户表、支付流水表三张表，要求统计每个用户在不同月份的订单金额排名、环比增长率等指标。核心考点就是窗口函数ROW_NUMBER()/RANK()和LAG()/LEAD()。
4.2 这类题的标准写法和得分技巧
我给出的最终写法思路是：
WITH base AS ( SELECT user_id, DATE_FORMAT(order_time, '%Y-%m') AS month, SUM(order_amount) AS total_amount FROM orders WHERE order_status = 'paid' GROUP BY user_id, DATE_FORMAT(order_time, '%Y-%m') ), ranked AS ( SELECT user_id, month, total_amount, RANK() OVER (PARTITION BY month ORDER BY total_amount DESC) AS rk, LAG(total_amount) OVER (PARTITION BY user_id ORDER BY month) AS prev_amount FROM base ) SELECT user_id, month, total_amount, rk, IFNULL(ROUND((total_amount - prev_amount) / prev_amount, 4), 0) AS mom_growth FROM ranked WHERE rk <= 10;SQL题拿分的关键点有几个，哪怕你的最终结果不完美，判题系统也是按测试点给分的，所以最好拿到步骤分：
- 先正确聚合，确保GROUP BY的正确粒度和过滤条件放在WHERE里而非HAVING，避免全表扫描的数据量拖垮执行超时；
- 窗口函数的分区键思考清楚，比如按用户分区算环比时，要用
PARTITION BY user_id ORDER BY month，这个顺序写反了结果完全不对； - 环比增长率的除零保护：
prev_amount可能为NULL或0，不处理直接相除会报错或者该行被判错。
我当时的失误在于只用了RANK()没有处理并列排名导致的值重复，后来才意识到如果需求是“取每月的Top10用户”，并列排名的场景下用户数可能超过10个，这时要用ROW_NUMBER()或RANK()要综合考虑业务语义。这种细节，判题用例里一定会有一组并列排名数据来测试。
5. 选择题里的“隐形编程题”：哪些考点决定你能否通关
5.1 操作系统与并发编程题的隐藏比重
选择题中操作系统部分占比不小，而且考察方式很实战。除了常规的进程线程区别、死锁四大条件、页面置换算法之外，让很多人翻车的是并发编程相关的基础题，比如：给出四个线程交替执行的伪代码，问可能的输出序列有哪些；或者给一个简单的生产者消费者代码段，问在缺少volatile/Lock的情况下可能出现什么问题。
这里我要特别强调：星环笔试选择题里出现的并发题，不完全是纯概念背诵，而是把你放在“实际运行”的视角下来考。比如：
# 选择题简化版 x = 0 def add(): global x for _ in range(1000): x += 1 # 开两个线程执行add() # 问：最终x的可能取值？答案是“0到2000之间的某个值都不奇怪”，而很多同学选了“一定小于2000”或者“一定等于2000”。如果你对GIL、线程调度和内存可见性的理解只停留在八股层面，这类题非常容易丢分。建议复习时重点看《深入理解计算机系统》的并发章节，不要只背“互斥锁保证原子性”这种结论性表述。
5.2 网络协议选择：Java/Python都要懂的高频题
另外一块高频选择题是TCP/IP网络协议，但不是简单问“TCP和UDP区别”，星环更爱考TCP拥塞控制的具体过程、HTTP/HTTPS请求过程中DNS解析与TCP握手的时序，以及大数据场景中涉及到的通信模型，比如Netty的NIO模型、Kafka的ack机制对应到TCP可靠性保障的哪一层。
这类题没有捷径，建议梳理一遍“从输入URL到页面渲染”的完整网络流程，把每一层协议的作用和典型字段记住。因为选择题选项经常把时间顺序打乱，纯靠记忆容易选错，理解了整个链路才能应对。
5.3 数据库理论：从索引原理到事务隔离级别
数据库部分除了SQL题，选择题也会考察索引底层原理、事务隔离级别、MVCC机制等。星环毕竟自研数据库，这一块不能草率。当时有一道题是给出一段SQL执行计划，问是否用到了某个索引，并给出推断依据。很多人只看了WHERE条件是否命中索引列，忽略了回表、覆盖索引、联合索引最左前缀等细节。
我的建议是复习时手写理解B+树的页分裂过程和where条件下推逻辑，不要只刷概念的记忆题。
6. 复盘总结与备考建议：这套题到底在考什么
6.1 从三个维度看星环的筛选逻辑
整套A卷做下来，我对星环笔试的出题逻辑有了基本判断：它不是在选拔“最会刷题的人”，而是在选拔“未来能直接干活的人”。三个维度分别是：
- 读题与建模能力：题目描述都比较长，业务场景包装很多，能不能从中抽出核心数据结构是第一步。比如日志聚合那道题，本质上就是
HashMap<String, HashMap<String, Integer>>的二层聚合，但包装成日志场景后很多人被干扰了。 - 边界处理习惯：几乎所有题目都有明显的边界测试点。时间窗口的闭开区间、环检测、除零保护、并列排名——这些都是生产代码里最容易被疏忽的地方。一个平时写代码就注意断言和防御性编程的人，在笔试里自然而然就能避开这些坑。
- 复杂度意识：数据规模给的数值不是装饰。10^6的数据告诉你需要O(n log n)或O(n)的算法，如果你交O(n^2)的代码，即使小数据能对，大数据测试点也一定会超时。
6.2 决策点复盘：我哪些选择是对的，哪些是错的
回顾整个笔试过程，我做得对的选择是：先花3分钟浏览全部题目再动手，而不是按顺序死磕；编程题第二道先推导出拓扑排序模型再写代码，没有跳进贪心模拟的坑；SQL题先写了草稿再输入，避免在判题编辑器里反复修改导致超时。
做得不对的地方则是：选择题在并发和网络题上耗了太多时间，导致留给SQL题的时间偏少，SQL题最后的排名那步差点没写完。如果重来一次，我会在选择题上给自己限时40分钟，遇到不会的直接标记跳过，先保SQL和编程题的确定性分数。
6.3 针对性备考路线：离笔试还有X周该怎么做
这里给出一个可复用的备战时间线，适配星环这类大数据基础软件公司的笔试题型：
- 第1~2周：主攻拓扑排序、并查集、前缀和、滑动窗口这四类高频数据结构题型，每天刷3道中等难度题并写下“建模思路”，能说清楚为什么用这个结构。
- 第3周：集中练习字符串处理题和日志类模拟题，重点训练自己把长文本场景描述转化为代码结构的速度。
- 第4周：每天做一套完整笔试模拟，严格限时120分钟，尤其要让自己适应“选择+编程+SQL”混合题型带来的脑力切换。
- 贯穿全程：每天20分钟复习数据库索引/事务、网络协议、操作系统并发这三大选择题板块。
6.4 关于笔试环境的几个细节提醒
最后说几个容易在考前被忽略的实操细节：
- 星环笔试用的在线平台支持本地IDE调试，但提交时的运行环境是特定的Python/Java版本，我用的Python 3.9有些语法（比如
list[int]类型注解）需要确认是否支持，建议提前在牛客网模拟环境里验证。 - 编程题的输入读取，建议统一用
sys.stdin的buffer快速读取方法，不要用input()，当数据量大时两者差距明显，而且在线判题时input()可能因为行数多导致性能损耗。 - SQL题不一定只支持MySQL方言，平台可能使用他们自研的语法，有些不常见的函数名写错会直接判编译错误，建议了解基础的
DATE_FORMAT、LAG、ROUND即可，尽量避免冷门函数。
如果以上内容能帮你少走一点弯路，那我的这段复盘就值了。准备校招笔试本质上是一个“把不确定变成确定”的过程，希望你能在考场上比我当时更稳一些。
