企业官网建设流程全解析

2023年秋招那阵儿，我刚好帮几个学弟学妹做过笔试前的突击串讲，其中小红书Android岗的第三批笔试让我印象很深。这场笔试不像很多大厂那样纯考LeetCode冷题，它明显带着“小红书风格”——Android技术栈考察比例不低、题目叙述长、场景贴近真实业务，而且第三批次的题在重复率极低的情况下，还能做到和大厂常规题库拉开区分度。这篇就结合我当时带人复盘的过程，把这场笔试考了什么、怎么准备、有哪些容易被忽略的坑，一次性写透。

1. 小红书第三批笔试的整体观感：题量、时长与批次差异

先给没参加过的人一个直观概念。小红书秋招笔试走的是牛客网这类在线笔试平台，Android开发岗和客户端开发岗统一用一套卷子，不是单独出Android卷。第三批笔试的时长一般是90到120分钟，题量在20道左右，包含单选、多选、填空和两道手撕代码题，其中代码题占分最重，属于“一道AC与否直接决定过不过线”的那种权重。

批次之间的差异值得提前说清楚。小红书秋招笔试是分批开放、分批考的，第一批和第二批的题目偶尔会在牛客、力扣讨论区被回忆出来，但第三批的题目重复率极低，基本不用指望靠背题碰运气。它的题目风格也跟前两批不太一样，第三批更偏向“业务场景结合基础原理”，比如给你一个具体的列表卡顿问题，让你挑出可能导致卡顿的原因，这种题要求你真正做过优化，光靠背书很难蒙对。

另外，第三批笔试的时间点通常在九月中下旬到十月初，这时候大厂笔试撞车严重，很多人是在一天内连打两场笔试的状态下去做的。我带的学弟当时就是下午刚做完美团笔试，晚上接着打小红书，脑子已经接近过载。所以如果你也面临类似情况，我的建议是：考前把小红书近两年的技术文章和开源项目扫一遍，对“社区、内容分发、图片加载、Feed流”这些业务关键词建立条件反射，比临时刷十道难题有用得多。

2. 开场定生死：两道手撕代码题的高频模型与解题套路

代码题是整场笔试的胜负手，小红书Android岗的代码题整体难度在力扣中等偏上，偶尔压到困难题的边，但不会出那种需要冷门数据结构的题。从我和身边人复盘的结果看，第二批和第三批的代码题集中在几类模型上。

2.1 数组与区间处理：最常见的“送分题”陷阱

小红书的业务大量涉及内容排序、推荐位调整、笔记列表分页，所以数组和区间处理的题出现频率极高。第三批有一道题跟“合并重叠区间”非常接近，但它不是直接给你一个二维数组让你合并，而是加了一层业务包装：给定一组笔记的曝光时间段，要求统计总曝光时长，重叠部分只计一次。这种题本质上就是合并区间，但很多人死在读题上——把开始和结束时间看反了，或者忘了处理“一个区间完全包含另一个区间”的情况。

合并区间有两个关键点：一是先按左端点排序，二是维护当前区间的右边界，并不断和下一个区间的左端点比较。具体来说，排序后初始化当前区间的左端点start和右端点end，遍历每个区间时，如果下一个区间的start小于等于当前的end，就说明重叠，把end更新为两者中的较大值；否则就把当前区间收割掉，然后更新start和end。这里最容易出错的是边界条件——区间相接（比如[1,2]和[2,3]）算不算重叠，题目里一般会明确说明“无重叠”是指首尾相接，如果没说明，就按实际业务逻辑推断。曝光时长场景下，首尾相接的两个时间段算连续曝光，不该重复统计。

2.2 动态规划：第三批的压轴题常客

DP是不少人的噩梦，但小红书笔试的DP题有个特点：状态定义比较直白，难在递推公式的细节上。第三批有一道题让我印象很深，类似“打家劫舍”的变体——一排笔记，每篇有一个点赞数，但不能同时选相邻的两篇，求最大点赞总数。这是个非常经典的线性DP，状态转移方程就是dp[i] = max(dp[i - 1], dp[i - 2] + value[i])，但笔试加了个限制：第一篇和最后一篇也被视为相邻（因为是循环列表）。

循环数组的处理方式有两种，第一种是把数组拆成两个场景分别跑DP——不考虑第一篇、不考虑最后一篇，取较大值；第二种是状态压缩加环形标记。用第一种方案的代码要干净很多，适合笔试场景。我见过不少人在这一步翻车：拆了场景但忘了把dp数组重新初始化，或者两个场景共用一个dp数组导致状态污染。所以如果笔试遇到环形DP，我强烈建议写两个独立函数分别处理，宁可代码多几行，也不要为了“优雅”引入难排查的bug。

2.3 字符串与模拟题：考验“读题耐心”的题型

第三批笔试题里经常出现长叙述的字符串模拟题，这类题算法本身不难，但输入输出的格式细节多。比如有一道题要求处理“笔记话题标签”的解析，输入是带#分隔的字符串，要求提取出符合特定规则的话题词并按字典序排序去重输出。考察的无非是字符串分割、排序、去重，但很多人栽在“话题词可以包含字母数字和下划线，但首字符不能是数字”这种规则上。

遇到这类题，第一件事不是写代码，而是把规则逐条列在草稿纸上，标出每个规则对应的输入样例。写的时候用一个单独的布尔函数去判断“合法话题词”，不要把所有逻辑堆在主流程里，这样既好调试又不容易漏规则。输出格式上要注意题目要求的是按字典序还是按原出现顺序，以及去重是严格区分大小写还是不区分，这些细节在样例里通常会埋坑。

3. 选择题里的Android主战场：从热词反推高频考点

小红书笔试的选择题对Android考的相当细，而且角度刁钻。结合我看到的考生回忆和我自身的技术积累，我把出现过的、以及大概率会出现的考点分成几类，每一类背后都有明显的小红书业务影子。

3.1 AMS与Activity启动流程：考的是“链路记忆”而非单点记忆

Activity管理服务（AMS）相关的题在客户端笔试里出现频率极高，小红书也不例外。但第三批的题目不再是简单问“Activity启动时系统会调用哪个方法”，而是给出一条包含多个环节的链路，让你选出顺序正确的一项，或者故意在某一步插入一个无关选项，考察你有没有把整个流程串起来。

从startActivity到界面可见，核心链路是：startActivity通过Binder跨进程通知AMS，AMS对Activity进行生命周期调度并维护任务栈，然后通知应用进程创建Activity并回调onCreate、onStart、onResume。要特别注意的是，onResume执行完后界面才真正可交互，而onStart只是“可见但不可交互”。选择题非常容易在这里挖坑：问你“哪个回调执行后Activity才可交互”，答案是onResume而不是onStart。

另外一个高频变体是启动模式。标准模式（standard）会多次实例化，单顶模式（singleTop）只要栈顶是同一个实例就复用，单任务模式（singleTask）会在目标任务栈里查找并清除其上的Activity，单实例模式（singleInstance）则整个系统只有一个实例且独占一个任务栈。小红书偏爱考singleTask和singleInstance的区别，尤其结合“从通知栏点击跳转到一个页面，希望栈里只有一个该页面实例”这种业务场景来出题。

3.2 消息循环与Handler机制：为什么主线程不能做耗时操作

很多客户端笔试题绕着Handler转是意料之中的，小红书的题也不例外。比较常见的是问你“在主线程中执行Thread.sleep(5000)会发生什么”，又或者“handler.postDelayed的精准度如何”。这些题表面考Handler，实际考你有没有真正理解消息循环的机制。

主线程从Looper.loop()进入无限循环，从消息队列取消息并分发处理。如果你在某个消息的处理函数里执行了耗时操作，这个循环就被卡住了，后续的UI刷新、触摸事件、四大组件回调全都排队等着。postDelayed的“延迟”也不是精确的定时任务，它只是把消息按时间戳插入队列，如果队列前面有耗时消息，实际执行时间会延后。选择题里要区分“延迟时间从调用时刻起算”这个描述，严格来说postDelayed是按它被插入队列的时间起算的，而不是实际入队时间，这个细节容易被忽略。

还有个连环坑是Looper和Handler的绑定关系。子线程里默认没有Looper，如果直接new Handler()会抛异常，必须先Looper.prepare()再Looper.loop()。笔试题偶尔会把“在子线程中创建Handler是否必须调用prepare”作为判断题，答案是必须，除非用HandlerThread，它内部已经封装好了这一步。

3.3 自定义View与触摸事件分发：小红书业务的重中之重

小红书App的核心就是信息的上下滑动浏览，自定义View和触摸事件分发的考察权重极高。选择题常考dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent三个方法的调用顺序，以及requestDisallowInterceptTouchEvent的作用。

标准的事件分发顺序是：Activity.dispatchTouchEvent到ViewGroup.dispatchTouchEvent，再依次尝试每个子View的dispatchTouchEvent，如果子View的onTouchEvent返回true，事件就由子View消费；如果子View都不消费，则父View的onTouchEvent处理，最后回到Activity。requestDisallowInterceptTouchEvent(true)的作用是禁止父View拦截后续事件，典型场景是内层水平滑动的列表嵌套在垂直滑动的列表里，内层不想让外层抢走滑动。

从这个角度看真题，第三批考过一道“列表中嵌套横向滑动条目，水平滑动容易误触变成垂直滑动”的题，问你怎么解决，答题思路就是三层：触摸事件分发的消费优先逻辑、requestDisallowInterceptTouchEvent的使用、以及滑动角度差值的阈值判断。

3.4 图片加载与内存优化：把“小红书为什么不卡”当成一道题拆解

图片加载是小红书笔记流的核心，所以笔试里出现相关题目很自然。选择题角度比较多的包括：Bitmap的内存计算、inSampleSize采样压缩、LruCache缓存淘汰策略、Glide的四级缓存流程。

Bitmap内存计算是最经典的一题：一张宽width像素、高height像素的图片，采用ARGB_8888格式，每个像素占4字节，内存占用就是width * height * 4字节。如果你把一张1920 * 1080的图片加载进内存，不开任何压缩，大概需要1920 * 1080 * 4 = 8294400字节，约7.9MB。对一个Feed流来说，滑几屏就上GB了，所以必须用inSampleSize做采样，用RGB_565（每个像素2字节）节省内存，或者用复用与缓存减少重复分配。

Glide的四级缓存顺序是：活动资源（ActiveResources）、内存缓存（LruCache）、磁盘缓存（DiskLruCache）、网络/来源。选择题爱考的是“第一次加载一张网络图片，缓存读取顺序是什么”，答案是先查活动资源、再查内存缓存、再查磁盘缓存，都没有才走网络。还有个容易错的点是：内存缓存的键由图片URL、宽高、变换等组合而成，不同尺寸的同URL图片不是同一个键。

3.5 布局优化与渲染性能：RecyclerView是永远的神

小红书笔试第三批有一道让我印象很深的题：给定一个列表页滑动掉帧的场景，让你选出有效的优化手段，并排除掉无效手段。选项包括setItemViewCacheSize、setHasFixedSize(true)、setDrawingCacheEnabled(true)、asyncLayoutInflater等。

setHasFixedSize(true)的作用是告诉RecyclerView Item的尺寸固定，可以跳过某些测量步骤，但如果Item高度会变化，开了这个反而会导致显示异常。setItemViewCacheSize是设置额外的ViewHolder缓存数量，对快速滑动时减少重复绑定有一定帮助，但治标不治本。setDrawingCacheEnabled在大部分场景已经被官方不建议使用，开错了反而增加内存占用。

真正有效的优化还包括：布局扁平化（用ConstraintLayout减少层级）、ViewHolder里减少不必要的findViewById（用ViewBinding）、图片加载做尺寸匹配和裁剪、预加载下一页数据。选择题的坑通常在于“看似相关实则无用”的选项，比如hardwareAccelerated设置——这个选项本身能加速渲染，但如果你问的是“列表滑动掉帧”，它远不如减少布局层级来得直接。

4. 隐藏的进阶考点：从搜索热词里挖技术风向

我整理这次笔试相关的搜索热词时，发现几个很有意思的高频词——android studio hedgehog、AGP 8、R8、APEX、OpenOCD、OTA、动态图标主题。这些词放在一起，能明显看出2023年秋季Android技术栈的关注点，而这恰好也是笔试选择题的“元考点”。

4.1 AGP与R8：构建工具链的版本兼容性

2023年Android Studio已更新到Hedgehog版本（2023.1.1），内部默认的Gradle插件（AGP）版本到了8.x。很多人问“Hedgehog是否支持AGP 8”，实际上是反了——Hedgehog本身就包含对AGP 8.x的支持，但在老项目上升级AGP 8会有很多兼容性坑，比如compileSdk最低要求、JDK版本要求、namespace配置要求。

笔试考构建工具的题目不会让你写gradle脚本，但会在选择题里问你“R8的作用是什么”。R8是ProGuard的替代品，负责代码压缩、资源压缩、混淆和优化。和ProGuard相比，R8在压缩率和编译速度上都有提升。容易考到的点是：开启R8后，哪些代码会被移除（不可达代码）、哪些要保留（通过keep规则显式声明的类和方法）、为什么反射调用需要keep（因为R8无法静态分析反射目标，不加规则会被混淆或移除）。

这块想速成的话，建议把AGP 8的变更日志过一遍，重点记住几条：默认使用namespace、BuildConfig默认关闭、JDK 17为编译默认版本。笔试不会出太深，但知道这些能帮你排除不少干扰项。

4.2 ABI与动态模块：Android动态图标和APEX背后的系统分区逻辑

搜索热词里“android动态图标主题”和“android apex”这两个词值得展开说。动态图标是Android 13开始支持的主题化图标能力——系统根据壁纸颜色动态调整应用图标的色调和背景。这类题目看似是系统功能题，实际上考的是你对Monochrome图标、AdaptiveIconDrawable的理解。选择题大概率会问“实现动态图标需要提供哪几种图层”，答案是前景层（foreground）、背景层（background）以及单色层（monochrome），缺一不可。

APEX则是一个相对冷门但2023年多次被提及的概念。它是Android引入的一种可更新的系统组件包格式，用于让某些系统组件通过OTA更新而不需要完整刷机。选择题如果考APEX，一般问的是它的特点：可以独立更新、具有版本控制、更新失败可以回滚。这些选项属于“多选一眼就能看出正确描述”的送分题，前提是你知道APEX和普通APK的差异——APEX是一个APK容器，但更新优先级更高且支持启动时激活。

4.3 OpenOCD与蓝牙调试：嵌入式调试与车载Android的交叉点

搜索热词里“android openocd”和“android 车载”放在一起看，说明2023年下半年行业对Android Automotive和底层调试的关注度明显上升。OpenOCD本身是嵌入式开发常用的片上调试工具，用于通过JTAG/SWD接口对芯片进行调试。在Android场景里，它主要面向开发板、车机、IoT设备的底层调试。

笔试不太可能直接考OpenOCD的具体命令（除非你是做大屏或车机专项），但它背后考察的是调试思维：当你需要调试一个系统服务或Native层问题时，如何定位问题边界。如果选择题里出现“如何调试系统Server进程的问题”，候选答案可能有：adb logcat、dumpsys、OpenOCD连接JTAG、gdb attach。正确的思路是先通过dumpsys和logcat定位到具体模块，再决定是否需要底层调试工具介入，而不是一开始就上OpenOCD。

车载方向更值得关注的是蓝牙相关的题目，因为车载系统里蓝牙电话、蓝牙音频是核心功能。Android蓝牙协议栈在2023年前后经历了从BlueZ到Bluedroid的全面切换，选择题可能涉及蓝牙权限（BLUETOOTH_CONNECT、BLUETOOTH_SCAN）、BLE广播与扫描的区别、经典蓝牙与BLE的通信模型差异。这块对非车机方向的人来说属于“复习了就能拿分，不复习就瞎蒙”的性价比区间，建议考前用半天把蓝牙基础概念过一遍。

4.4 内容URI与FileProvider：跨应用文件共享的历史包袱

热词里一堆content://长串，是搜索时自动带出来的URI示例。Android 7.0开始强制要求应用间共享文件使用content://协议，禁止直接传file://路径，否则抛FileProviderException。小红书作为典型的图片密集型应用，笔试考这个概率不小。

FileProvider的原理是通过AndroidManifest里配置<provider>节点，定义file_paths映射，把内部路径映射成可外传的content://URI。不同App的authority不一样，所以你会看到各种com.baidu.searchbox.fileprovider、com.ss.android.uri.key之类的长串。选择题考的是：跨应用传递图片路径时，为什么用content://而不是file://？答案核心是：file://暴露了真实路径且缺乏权限控制，content://则通过URI授权（grantUriPermission）临时授予对方读写权限，更安全。

另一个相关考点是ExternalStorage和分区存储。Android 10（API 29）开始强制分区存储，应用访问公共目录需要申请权限且只能访问自己创建的文件；Android 11进一步放开MANAGE_EXTERNAL_STORAGE权限但需特殊声明。这类题目比较容易出现在多选题里，判断哪个操作在分区存储下是被允许的。记住一个原则：分区存储下，应用可以无权限读自己App专属目录下的文件，访问公共媒体文件（图片、音频、视频）需要读取权限，访问其他应用的专属目录则被禁止——除非用户通过系统文件选择器主动授权。

5. Android方向的备考侧重点：哪些分能拿、哪些分不要强求

在线笔试的备考策略和面对面面试完全不同：面试可以靠表达和思路加分，笔试只看最终结果。尤其是选择题，你没有任何解释机会，对就是对、错就是错。所以这场笔试的备考策略应该是“扬长避短、稳拿基础分”。

5.1 复习优先级排序：先框架、后细节、再冷门

选择题复习的优先级，我建议按以下顺序排：

1. 四大组件与启动模式：这是必考基础题，把onCreate/onStart/onResume/onPause/onStop/onDestroy的调用时机和栈内变化梳理清楚，再背熟四种启动模式的区别，就能应对八成相关题。
2. 消息循环与线程：Handler、Looper、MessageQueue的关系，主线程和子线程的数据更新边界，runOnUiThread与Handler.post的异同。这块属于“理解了不会错、不理解靠背很难背完”的考点。
3. RecyclerView与列表优化：ViewHolder复用、区别notifyDataSetChanged和notifyItemChanged、LayoutManager的预取机制。小红书是做Feed流的，列表相关题目几乎必出。
4. 图片加载与内存管理：Bitmap内存计算、缓存策略、OOM的常见触发场景和规避方案。
5. 网络与数据解析：HTTP/HTTPS、OkHttp拦截器、Retrofit注解、JSON解析的性能问题。这些是客户端开发的基本功，笔试会偶尔穿插。
6. 冷门拓展：如上文提到的APEX、OpenOCD、主题化图标，复习不在多，知道核心概念即可。

5.2 多选题的答题策略：宁缺毋滥还是放手一搏

在线笔试的多选题是最容易丢分的题型。小红书的多选题一般是“每题有几个正确选项，全部选对才得分，少选、多选、错选都不得分”。在这种规则下，我的策略是“只选确定正确的选项”，不确定的坚决不选。因为多选一个错误项，整题分数归零；少选一个正确项，同样是零分。与其赌一个不确定的选项，不如保守一点把确定的分拿稳。

举个例子，考“下列哪些操作可能导致OOM”这类题时，加载超大Bitmap、在循环中创建大量短生命周期对象并持引用、使用Handler持有Activity引用导致泄漏，这三项你确定是对的，就选三项。如果第四个选项“在onDraw里new一个Paint对象”你不太确定，那就不选——虽然它实际也可能导致内存抖动，但笔试的“可选可不选”边界模糊，落袋为安更重要。

5.3 编程题的代码规范：判题机为什么对你的代码零容忍

笔试编程题用的是在线判题系统，它不会看你的代码风格，但会对格式和边界有极其严格的约束。我复盘过不少“明明逻辑对但就是没AC”的案例，常见原因有：

1. 多行尾输入处理错误：牛客这类平台常常需要你从System.in循环读取到文件末尾，很多人只读了一次nextLine就以为输入结束了，导致少处理一组数据。
2. 边界指数组下标越界：比如处理循环数组时，i % n的写法在n = 0时会抛异常，而输入限制里可能没说n不会为0。
3. 输出格式多一个空格或换行：有些题目要求每行末尾不能有尾随空格，判题机会严格比对。这个最冤，但出现频率不低。
4. 数据范围超int：有些题目的数据范围看起来不大，但中间计算结果会溢出int，要用long。比如动态规划里累加点赞数时，n到10万时就可能超int上限。

长期养成的习惯是把“数据范围读取-边界判断-输入输出格式”这三个环节当成编程题的一部分来对待，而不是写完核心逻辑就交卷。笔试的时候宁可留出五分钟检查这些细节，也不要赶着提交然后看着“通过率0%”怀疑人生。

6. 实战复盘：一份典型的小红书第三批笔试时间分配方案

很多考生倒不是在知识点上落败，而是败在时间分配上。第三批笔试的代码题通常放在最后，但选择题前面的确容易卡太久，导致编程题只剩十几分钟。我给学弟学妹定的时间分配方案是这样的：

总时长120分钟，题量22道，其中选择题17道、编程题2道，另有几道填空/简答。

• 前60分钟做选择和填空：每道选择题最长不超过3分钟，超过就标记跳过。填空题如果遇到不会的，果断放弃填一个最可能的答案，不要恋战。
• 中间30分钟做第一道编程题：第一道通常比第二道简单，务必做出来并AC，这是全卷的保底分。
• 最后30分钟做第二道编程题：如果15分钟内没有完整思路，立刻退回暴力解法拿部分分。笔试平台一般按测试样例给分，暴力解法只要能通过部分样例，就比空着强。
• 剩余时间检查：优先检查输入输出格式、边界条件，再回头看不确定的选择题（但要克制改答案的冲动，除非找到明确错误）。

这个方案有一个前提：你对Android基础知识足够熟。如果选择题十几道全都在“犹豫”，这个时间分配是撑不住的。所以考前最后一周，我建议拿牛客上的小红书历年真题（第一批和第二批回忆版）做一次限时模拟，感受一下真实节奏。

7. 一些值得额外聊的细节：题型之外的信息差

最后这部分我想说一点不一定直接考、但对整场笔试有隐形帮助的内容。

7.1 善用编辑器里的代码片段模版

笔试平台的在线编辑器不像IDE那么好用，没有自动补全、没有自动导包、没有“整理代码”的快捷键。所以平时刷题的时候，建议把常用的模板写到本地笔记里，考前过一遍：

• 快速IO模板：BufferedReader+StringTokenizer，而不是直接用Scanner。笔试数据量大的时候，Scanner会慢得怀疑人生。
• 常用数据结构的手写模板：并查集、前缀和、树状数组、堆的调整。虽然笔试不强制你手写，但万一平台不让你引入某些工具类，手写模板能救命。
• 调试输出模板：用System.err.println打印中间结果而不影响答案输出，这是在线笔试环境里一个非常实用的技巧。

7.2 留意笔试邀请邮件里的“注意事项”

很多人把笔试邀请邮件当成普通通知扫一眼就过去了，但这封邮件里往往藏着关键信息：是否开摄像头、是否允许切屏、是否可以用本地IDE、是否支持Java/Kotlin/C++多语言。小红书第三批笔试明确要求开摄像头和防切屏，如果考试中途切出考试页面，会被系统记录甚至直接判违规。有些人习惯本地写代码再粘贴到网页，在防切屏模式下这个操作要格外小心，提前弄清规则再决定是否使用这种方式。

另外，如果用本地IDE，务必确认你本地的语言版本和平台一致。比如平台用Java 8，你本地用的是Java 17，某些API在Java 8里不存在，提交后编译就直接挂了。笔试前配好一个“最保守、最兼容”的本地环境，反而比追求新版特性更稳。

7.3 简历方向与笔试的联动

我后来复盘学弟拿到面试的历程，发现一个容易被忽略的点：笔试成绩不是孤立的，它会和你的简历方向联动。小红书Android岗的笔试考察风格是“基础扎实 + 业务敏感”，如果你简历上写了做过列表优化、图片加载、性能优化相关的项目，笔试里对应的题目通常就是你展示优势的地方。

所以笔试前重新读一遍自己的简历，把与技术栈相关的项目输出整理成几句话：用了什么方案、解决了什么问题、达到什么量化结果。虽然笔试不考自我介绍，但这个梳理过程能帮你在面对“下列哪些方案可以提升列表滑动流畅度”这样的题目时，瞬间从自己的实践经验里找到答案，而不是靠猜。

7.4 心态管理：第三批是机会，不是“剩余批次”

很多考生默认第三批是“别人挑剩下的时间点”，觉得不如前两批光鲜。实际上，秋招笔试分批是招聘流程的设计，不代表第三批的岗位饱和度低。第三批笔试往往在九月底十月初，这个时间点有一部分前期拿到意向书的候选人会释放名额，岗位总量未必少，再加上第三批笔试的题目重复率低、区分度高，一份扎实的笔试成绩更容易让面试官眼前一亮。

我带的学弟就是第三批笔试通过后拿到面试机会的，他后来跟我说，笔试成绩在面试官沟通时被主动提起过——“笔试表现不错，尤其是代码题写得干净”。这说明笔试不只是敲门砖，它会在后续面试里持续赋能。

所以如果你正好分到了第三批，不要有“是不是没坑了”的焦虑，把精力全部放在“用这份卷子证明自己的技术深度”上，反而更能发挥出真实水平。祝准备秋招笔试的各位都能稳定发挥，把该拿的分都装进兜里。