ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

算法岗二面秒挂真相:项目深挖、手撕代码与场景题拆解

算法岗二面秒挂真相:项目深挖、手撕代码与场景题拆解

上周和一位做算法的朋友吃饭,他端着碗说自己投了某头部大厂算法岗,一面聊得挺顺,二面进去不到四十分钟就被请了出来,第二天一早收到流程结束的邮件,从面试到出结果不到四十八小时。他一边扒饭一边感慨:效率是真高。我听完笑了半天,因为这句话我自己也说过,身边至少五六个做算法的朋友都说过。算法岗二面秒挂这件事,在求职季里几乎是绕不开的一道坎,挂得干脆利落,反倒让人怀疑自己是不是连问题都没听懂。

这篇东西想聊的就是这件事。二面为什么会挂得这么快,面试官在那几十分钟里到底在看什么,项目该怎么讲、代码该怎么写、场景题该怎么搭框架,以及挂掉之后怎么把这次失败变成下一次的筹码。不管你是刚投出第一份简历的应届生,还是工作两三年想换赛道的老兵,只要目标是算法岗,这套东西都能直接用上。我把自己和身边人踩过的坑整理了一遍,尽量说人话,能抄的部分直接给模板。

1. 二面秒挂的本质:筛人机制与能力断层

1.1 算法岗面试的四层漏斗

很多人把面试理解成"考试",觉得分数够了就能过。实际情况更像一条逐层收窄的漏斗,每一层筛的东西完全不同,你在上一层的优势到了下一层可能一点用都没有。

第一层是简历筛选。这一层看的是关键词匹配度:方向是否对口、项目是否有量化结果、技术栈是否落在岗位需求上。一份写满"参与""负责""协助"的简历,大概率在这一层就被刷掉,因为看不出你个人的贡献边界。第二层是笔试或机试,考的是编码基本功和算法熟练度,能不能在限定时间内把思路稳定地翻译成没有编译错误的代码。第三层是一面,通常由团队里的骨干工程师来面,重点是基础扎实度和项目真实性,题目难度中等,八股问得比较密。第四层才是二面,面试官一般是组长、资深工程师或者跨团队的交叉面试官,考察维度从"你会不会"切换到"你能不能扛事"。

这四层之间不是难度递增的关系,而是考察维度在切换。一面考官关心的是"这个人基础行不行、简历有没有水分",二面考官关心的是"这个人进来之后能不能独立负责一个方向、遇到模糊问题能不能自己收敛"。你在一面靠背八股和刷题拿到的分数,到了二面基本清零,因为二面根本不按题库出牌。

我见过不少候选人,一面评价是"基础扎实、代码干净",二面评价变成"缺乏深度思考、项目停留在调用层"。同一个人,两天之内两套评价,原因就在这里:一面的评价标准是"合格",二面的评价标准是"优秀且可信"。

1.2 一面与二面之间的能力断层

把两面的差异摊开看,其实非常清楚。下面这张表是我根据自己和朋友们的面试记录整理的,可以对照着自查。

维度一面考察重点二面考察重点断层的具体表现
代码题中等难度,能否写对边界条件、复杂度、可维护性写出来了但说不清为什么这么写
项目你做了什么你为什么这么做、还有没有别的做法只会复述流程,答不出方案取舍
八股概念定义与公式概念背后的假设与失效场景背得出公式,说不清适用边界
场景题较少涉及高频出现,且没有标准答案想到哪说到哪,没有结构
沟通能听懂问题能主动澄清、能控节奏卡住之后沉默,或者硬编
潜力不太考察学习能力、技术判断力遇到没做过的问题直接放弃

这张表最关键的一行是"项目"。一面的项目环节通常只有五到八分钟,面试官问两句就过去了;二面的项目环节能占到整场的一半时间,而且追问是层层往下钻的。你如果说"我们用了一个双塔模型做召回",二面考官一定接着问:为什么是双塔不是单塔,塔的结构怎么定的,负样本怎么采的,采样比例变了指标怎么变,离线涨了在线没涨你怎么排查。

这些问题的共同点是:它们没有标准答案,但每一个都在检验你有没有真的做过决策。答不上来,考官心里就会给你打上"执行层"的标签,而二面要找的是"能自己想清楚"的人。这就是秒挂的核心原因——不是你不够努力,是你在二面这个维度上还没有准备好。

还有一点容易被忽略:二面的面试官时间成本很高,一场四十五分钟,往往同时面三四个候选人做横向对比。一旦你在前十五分钟暴露出"项目讲不清"或者"代码有硬伤",后面的时间他就不会再投入精力去挖掘你的亮点,草草收尾、快速给结论,从候选人的体感上就是"秒挂"。所谓效率高,其实是面试官在做止损。

2. 六种高频死法与现场还原

2.1 项目讲述:只报结果不讲决策

这是最常见的死法,没有之一。典型表现是把项目讲成一份周报:我们做了一个推荐系统,用了双塔召回加精排,最后点击率提升了百分之几。讲完面试官问一句"这个提升是怎么归因的",人就卡住了。

问题出在哪?出在你讲的是"结果"和"名词",而面试官想听的是"决策链"。同样一个双塔模型,背后至少有五六个决策点:为什么选双塔(因为要在毫秒级完成千万级候选的召回)、向量维度定多少(受限于线上存储和检索延迟)、负样本怎么采(随机负样本简单但太容易,混合采样效果更好但工程复杂)、训练和 serving 怎么保持一致、冷启动物料怎么处理。你把这几个点讲清楚,考官立刻知道你参与了设计;你只报模型名和指标,考官只能判断你在执行。

我给一个可以直接套用的讲述结构,四层往下走:业务目标与约束、方案选型与备选、我的具体动作、结果与归因。业务目标是"要解决什么问题",约束是"在什么条件下解决"(延迟预算、存储成本、人力周期),这两层能瞬间把考官带入场景。方案选型要说清楚你否掉了什么、为什么否掉,这层最能体现判断力。我的具体动作必须落到"我改了哪一行逻辑、我发现了哪个 badcase",而不是"我参与了"。结果与归因要说清楚指标怎么来的、有没有做 AB、有没有排除其他变量。

有一段真实对话我印象很深。候选人讲完项目,考官问:"你这个特征上线之后离线 AUC 涨了 0.003,在线 CTR 没动,你怎么解释?"候选人沉默了几秒说"可能是波动"。这一句基本就结束了。正确的回答应该往特征穿越、样本与线上分布不一致、位置偏差、指标口径差异这几个方向去排查,哪怕你没有标准答案,也要展示出你的排查路径。

2.2 代码环节:能跑通不等于能过审

二面的代码题有个特点:题目本身不难,但考官会盯着你的过程看。很多人在本地刷题时习惯了"写完提交、过了就行",到了面试现场还是这个习惯,写完就说"好了",然后等考官点头,结果考官一句"你这个时间复杂度是多少、最坏情况呢",就答不上来。

现场有一个很隐蔽的坑:没有主动处理边界。数组为空、只有一个元素、全是重复元素、数值溢出、字符串含空格,这些都是高频边界。你写完主逻辑不主动说一句"我处理一下空输入的情况",考官会默认你没有这个意识。这个意识在工程里比算法能力更重要,因为线上事故八成来自边界。

另一个坑是变量命名和结构混乱。我见过候选人三十行代码里出现了 a、b、c、tmp、tmp2、res1,考官读代码的时间比他自己写的时间还长。面试官读不懂你的代码,就没法判断你的思路,只能给一个偏保守的评价。代码是写给人看的,这条在面试现场同样成立。

2.3 场景设计:没有框架就会变成闲聊

二面几乎必出场景题,形式通常是"如果让你做一个 XXX,你会怎么做"。比如:给一个内容平台做新用户冷启动的推荐,你怎么设计;给一个电商搜索做 query 改写,你怎么评估效果;模型上线后延迟突然翻了三倍,你怎么排查。

这类题的特点是范围极大、没有标准答案,考官的真正目的是看你能不能把一个大问题收敛成几个可执行的小问题。没有框架的人会怎么答?会从"我觉得可以先做用户画像"开始,然后想到哪说到哪,讲了十分钟还没落到具体模块,考官中途打断问"那你具体会先做哪一步",人就慌了。

有框架的人会先花三十秒明确问题:目标是提升新用户的次日留存还是首次点击率,冷启动阶段有哪些可用信号(注册信息、设备信息、首屏行为),有哪些硬约束(延迟、物料量、冷启动时长)。把边界框住之后再拆模块,模块拆完给一个最小可行的基线方案,最后谈怎么评估、怎么迭代。同样是十分钟,后者的信息密度是前者的好几倍。

场景题还有一个隐性考点:你会不会主动说"我不知道"。有些候选人遇到完全没接触过的领域,硬着头皮编,编到细节处就露馅。更好的做法是先说"这块我没有直接做过,我按通用的思路推一下",然后展示推理过程。考官对"没做过但能推"的容忍度,远高于"没做过还硬编"。

2.4 复杂度与边界说不清

这一条单独拎出来说,因为它在二面挂人原因里排名很靠前,而且完全可以在准备阶段解决。面试官问复杂度,本质是在确认三件事:你知道自己写的东西开销在哪、你能不能在写之前就预估开销、你会不会为了指标牺牲可维护性。

很多人只会说"时间复杂度 O(n)",考官追问"空间呢""最坏情况呢""如果数据量到一亿条还能不能这么写",就答不上来了。这类追问在工程场景里是日常,一个排序算法的选择可能直接决定任务能不能在窗口期内跑完。

我建议在准备阶段养成一个习惯:每写完一道题,用一句话把复杂度和关键假设说完整。比如"时间 O(n),空间 O(k),k 是字符集大小,所以实际是常数空间;这个前提是输入是单字节字符,如果是多字节需要换个处理方式"。这一句话的信息量,比写十行代码更能体现你的工程素养。

2.5 沟通节奏失控与简历细节穿帮

这两条放在一起讲,因为它们都属于"非技术因素导致的秒挂",但杀伤力极大。

沟通节奏失控的典型表现:卡住之后一声不吭地低头想,想了三分钟,考官不知道你在想什么,只能打断;或者考官问"A 方案和 B 方案你选哪个",你答了一堆两个方案的优缺点,就是不给结论。二面考官很看重"这个人能不能在信息不全的情况下给出判断",你一直不给结论,他就认为你不能独立做决策。

简历细节穿帮则更致命。简历上写了"主导 XX 模块优化,性能提升 40%",考官问"40% 是怎么测的、基线是多少、测了几次",答不上来,整份简历的可信度就崩了。二面考官对简历的追问强度是一面的三倍,因为他在判断你能不能扛事,而扛事的前提是信息可信。简历上每一个数字,你都要能还原出它的计算方式、测量环境和波动范围。

3. 项目深挖的答题模板与实操拆解

3.1 四层追问模型

二面考官追问项目,基本遵循一个由外到内的四层模型。提前知道这四层,你就能预判问题、提前准备答案。

第一层是事实层:这个项目解决什么问题、你负责哪部分、周期多长、团队几个人。这层是热身,答得干脆利落就行,别在这里展开太多细节,浪费宝贵时间。第二层是方法层:你用了什么方案、为什么不用别的方案、备选方案的缺点是什么。这层是分水岭,很多人在这里露馅,因为平时只负责执行,没参与选型。

第三层是数据层:训练数据从哪来、样本怎么构造、正负样本比例、特征有多少维、离线指标是什么、在线指标是什么、两者差异怎么解释。这层最能筛人,因为它无法临时编造,做过和没做过的人回答质感完全不同。第四层是反思层:如果重做一次你会改什么、这个方案的上限在哪、线上出了什么事故、你怎么定位的。这层考的是复盘能力和技术判断力,能答好这层的人,基本就稳了。

下面这张表可以直接当准备清单用,每个项目都过一遍。

追问层级高频问题准备要点常见失分
事实层项目目标、你的角色、周期一句话讲清背景,明确个人边界把团队成果说成个人成果
方法层为什么选这个方案、备选是什么准备两个被否掉的方案和理由只会说"业内都这么做"
数据层样本、特征、离线在线指标记住关键数字和口径指标提升说不清归因
反思层重做会改什么、上限在哪准备一个真实事故和排查过程说"没什么可改的"

3.2 一段完整的项目讲述示范

光说结构太抽象,我给一段可以直接改写的示范。假设你做的是一个内容平台的召回优化,讲述可以这样组织,控制在三到四分钟。

先讲背景和约束:"这个项目的背景是首页推荐的召回环节覆盖度不够,长尾内容拿不到曝光。硬约束有三个:召回要在二十毫秒内完成,候选池是百万级,线上不能增加太多存储成本。"

再讲选型和否掉的方案:"我们评估了三个方向:一是扩展现有的协同过滤,成本低但长尾覆盖提升有限;二是引入向量召回,效果上限高但要新建索引服务;三是做规则兜底,快但不可持续。最后选了向量召回,因为它能同时解决覆盖度和相关性,代价是要多做一套索引。"

然后讲你的动作:"我负责的是双塔模型的物料侧和样本构造。物料侧我做了两件事:一是把内容标题和标签做了融合编码,解决了短文本信息量不足的问题;二是针对新内容做了时间衰减的加权,避免老内容霸榜。样本这块我们试了随机负采样和混合负采样,最后用了混合,比例大概是一比三,因为纯随机负样本太容易区分,模型学不到细粒度。"

最后讲结果和归因:"上线后长尾内容的曝光占比涨了大概十几个点,人均停留时长有小幅正向。归因上我们做了两周的 AB,同时看了消融,把向量召回关掉之后指标回落,基本能确认是这个模块带来的。"

这段讲述大概四百字,信息密度很高,考官听完基本能判断你是核心参与者。关键点在于:每个决策都配了理由,每个数字都能说清来源,中间还埋了一个"我们试过但没采用"的细节,这种细节最能让考官相信你真的做过。

3.3 别在项目环节犯的低级错误

有几个错误必须点名。第一是抢功。把团队成果全说成自己的,考官稍微追问协作细节就会穿帮,而且这种穿帮是信誉层面的,很难挽回。第二是贬低前人。说"之前的方案特别蠢",考官会想"你来了会不会也说我们的方案蠢"。第三是编数字。指标记不清就说"大概是这个量级,具体数字我需要回去查",比编一个精确到小数点的假数字安全得多。

第四是答非所问。考官问"为什么用这个损失函数",你答"因为我们团队一直用这个",这不是回答,这是回避。真不会就说"这块是另一位同学负责,我理解是因为样本不均衡,但具体权衡我没有参与",诚实加上一点推理,比硬编好。

4. 手撕代码的现场操作规范

4.1 从读题到落笔的六步流程

二面的代码环节时间通常只有二十到二十五分钟,包括读题、讲解、编码、自测。流程感比代码本身更重要,因为流程能证明你在工程环境里也是这么干活的。

第一步,复述题目。用自己的话把题意说一遍,确认理解一致,重点确认输入输出格式和边界。这一步只花三十秒,但能避免后面全盘跑偏。第二步,问清约束。数据规模多大、有没有内存限制、需不需要考虑并发。数据规模直接决定算法选择,不问清楚就是赌博。第三步,说出思路和复杂度。先把暴力解说出来,再说优化方向,让考官看到你的思考路径。

第四步,写代码。写的时候边写边讲关键行在干什么,不要闷头写。第五步,自测。写完主动拿一个小例子走一遍,再补两个边界例子。第六步,复述复杂度。把时间、空间、最坏情况一次说完。

我给一个完整示范,题目是求最长无重复字符子串。

def length_of_longest_substring(s: str) -> int: # 记录每个字符最近一次出现的下标 last_seen = {} left = 0 ans = 0 for right, ch in enumerate(s): # 只有落在当前窗口内才需要移动左边界 if ch in last_seen and last_seen[ch] >= left: left = last_seen[ch] + 1 last_seen[ch] = right ans = max(ans, right - left + 1) return ans

写完之后要主动补的几句话:时间复杂度 O(n),每个字符最多被访问两次;空间复杂度 O(k),k 是字符集大小,英文字符集下是常数;边界情况包括空串返回 0、全部重复返回 1、含空格和特殊字符时按字符处理不受影响。这几句话说完,考官基本不会再在这个题上为难你。

4.2 代码自检清单与复杂度交代

面试现场不可能跑测试,所以你需要在脑子里过一遍自检清单。我常用的有五条:空输入、单元素、全相同元素、极值(最大最小、溢出)、重复元素。这五条能覆盖八成以上的边界 bug。

复杂度交代也有讲究,不要只说大 O。要区分平均和最坏,要说清空间是额外空间还是总空间,要说明常数因子大不大。比如哈希表方案平均 O(n),但最坏情况受哈希冲突影响;排序方案 O(n log n),但如果数据已经基本有序,插入排序反而更快。这些细节说出来,考官会认为你不是背题,而是真的理解。

还有一个实用技巧:如果时间不够,先把能跑通的主逻辑写完,再口头补充优化方向。考官更愿意看到一个完整但朴素的东西,而不是一个半截的精妙设计。写完主逻辑后主动说"这里如果用堆可以把复杂度降到 O(n log k),我口述一下思路",比闷头写一个写不完的最优解强太多。

5. 场景设计题的万能框架

5.1 四步拆解法

场景题最怕的就是没有结构。我给一个四步框架,任何题目都能往里套。

第一步,把问题框住。用一到两分钟明确三件事:优化目标是什么(点击、转化、留存还是成本)、有哪些硬约束(延迟、成本、人力、合规)、衡量成功的指标是什么。这一步的关键是主动提问,而不是等考官给全信息。你问的问题质量,本身就是评分项。

第二步,拆模块。把大问题拆成三到五个互相独立的子问题,每个子问题给出一个粗略方案。比如做冷启动推荐,可以拆成:新用户没有行为怎么办、新物料没有曝光怎么办、两者都没有怎么办。拆完你就有了一个清晰的答题地图。

第三步,给基线。任何方案都要有一个最小可行的起点,哪怕很粗糙。基线的作用是让讨论有落点,你可以说"第一版我会上规则兜底加热门内容,先保证不出错,再叠模型"。

第四步,谈评估和迭代。离线用什么指标、在线用什么指标、AB 怎么设计、多久看一次、看什么分层。这一步能把"想法"变成"方案",是拉开差距的地方。

5.2 三个高频题型的应对思路

第一类是效果类:离线指标涨了,在线没涨,怎么排查。这类题的排查路径是分层的:先看样本和特征有没有穿越,再看线上线下特征口径是否一致,然后看评估指标和业务指标是否错位,最后看是不是被其他策略稀释了。回答的时候按这个顺序讲,考官会觉得你有方法论。

第二类是性能类:接口延迟突然翻了三倍,怎么定位。路径是:先确认影响范围(全量还是部分)、再看监控分层(入口、服务、存储、下游依赖)、然后看变更记录(最近有没有发布、配置、数据量变化)、最后做压测复现。这类题的关键词是"分层"和"变更",把这两个词说出来,方向就对了。

第三类是数据类:正负样本极度不均衡,模型效果很差,怎么办。可以从采样(欠采样、过采样、混合)、损失函数加权、评估指标换用(不用准确率,用 AUC 或者 PR 曲线)、分场景建模这几个角度答。答的时候要说清每种方法的代价,比如过采样会放大过拟合风险,加权会影响概率校准。

框架讲完,还得提一句:场景题一定要说人话,不要堆术语。考官问"你怎么评估效果",你答"用 AUC 和 GAUC,再做分层看"就足够了,不需要把整个指标体系的公式背一遍。信息密度高不等于术语多,把关键判断说清楚才是本事。

6. 挂掉之后的复盘与补丁

6.1 二十四小时复盘清单

面试挂掉当天记忆最鲜活,一定要趁热复盘,拖过一天细节就模糊了。我自己的做法是把当天所有能想起来的问题按顺序写下来,然后逐条标注状态:答得好、答得一般、完全不会、答错了。这个动作只需要半小时,但价值极高。

接下来做归因。把"完全不会"和"答错了"的问题分类,看它们集中在哪个维度:是项目深度不够、是基础知识有盲区、是场景题没框架、还是表达节奏问题。如果三类以上都有问题,说明是准备阶段的结构性缺失,需要重做一轮准备;如果只集中在一个维度,那就是局部补丁,效率高很多。

我给一张复盘表,可以直接照着填。

复盘项具体记录归因判断补丁动作
项目追问考官问了特征穿越,答得含糊数据层准备不足整理项目数据链路图,标注每个环节的口径
代码题边界没说,复杂度只说了时间流程不规范按六步流程重练十道题
场景题冷启动答成流水账缺框架用四步拆解法重做五道场景题
沟通卡壳时沉默了两分钟节奏失控练习"说出正在想什么"的表达习惯

填这张表的目的是把模糊的挫败感转成具体的待办项。人最怕的是"我不知道自己哪里不行",一旦把问题写下来,焦虑会大幅下降,因为你有了可执行的下一步。

6.2 把短板拆成可执行的训练项

复盘之后最关键的一步是设计训练,而不是继续漫无目的地刷题。刷题解决的是"代码题会不会",解决不了"项目讲不清"和"场景题没框架"。

针对项目讲不清,最有效的办法是录音。挑一个项目,用四层结构讲三分钟,录下来回放。你会发现自己讲了大量"我们",很少讲"我";会发现自己在关键决策处停顿,因为那部分你其实没想清楚。改三遍,效果立竿见影。

针对场景题没框架,最好的练习是找十个题目,每个只花五分钟:两分钟框问题、两分钟拆模块、一分钟给基线。不写代码、不查资料,就是训练收敛能力。练过二十道之后,你会发现在面试现场听到题目就能条件反射地开始拆。

针对基础盲区,不要从头看教材。按复盘表里的具体问题去查,查完写一段自己的话解释给别人听,能讲清楚才算真会。这个方法我在准备交叉面的时候用过一次,效率比通读一遍教程高得多。

最后说一句关于心态的。二面秒挂不代表你能力不行,只代表你在这个特定维度的准备不够。面试本身有很强的运气成分,面试官当天的状态、题目的匹配度、甚至你进场时他刚处理完一个线上事故,都会影响结果。把能控制的部分控制好,剩下的交给概率。

7. 常见问题速查与踩坑心得

7.1 面试现场速查表

下面这些问题是二面现场的高频项,我按类别整理了一份速查表,面试前扫一眼能少踩很多坑。

场景典型表现正确做法
题目没听懂硬着头皮开始写复述题意,确认输入输出和边界
思路卡住低头沉默超过一分钟说出当前想到的两种可能路径,请考官给个方向
被问到不会的技术硬编或者转移话题说明没直接做过,给出推理路径
项目被追问细节说"记不清了"就结束说清记得的部分,并说明哪里需要回去确认
代码写到一半发现错直接删掉重写先说"我这个思路有问题,原因是……",再改
时间不够闷头写最优解先写完能跑通的主逻辑,优化方向口头补充
考官否定你的方案立刻改口附和问清他的顾虑,说明你的取舍依据

这张表里最值得记住的是最后一行。考官否定你的方案,很多时候不是因为你错,而是在测试你会不会坚持自己的判断。直接改口会显得没有主见,正确的应对是认可他的顾虑、补充你的依据、给出折中方案。

7.2 几条只有踩过才知道的经验

第一条,面试前十分钟别看新东西。很多人候场时还在刷题,看到一道不会的,心态立刻崩,进场之后满脑子都是"我完蛋了"。这十分钟用来做点别的:过一遍自己的项目关键词,回忆一下四个追问层级,或者干脆闭眼休息。

第二条,准备三个"事故故事"。二面的反思层最爱问"你遇到过什么线上问题",如果你能讲一个完整的事故:怎么发现的、第一反应是什么、怎么定位、怎么止损、事后怎么加监控,这比你讲十个成功项目更有说服力。因为事故最能体现工程能力,而工程能力正是二面要看的。

第三条,反问环节不要问废话。问"团队的技术栈是什么"、"新人有没有导师"这类问题很容易拿到模板答案。更好的问法是问具体场景:"你们现在这个方向最大的技术瓶颈是什么"、"如果我进来,前三个月最可能接手的是哪块工作"。这类问题能显示你在认真考虑落地,也方便你判断这个岗位值不值得去。

第四条,被挂之后不要立刻追问原因。有些候选人当天就发消息问面试反馈,通常拿不到有效信息,还容易给对方留下不好的印象。隔一周通过正常渠道问,或者干脆不问,把精力放在下一个机会上。反馈的价值远不如复盘自己的记录。

第五条,也是我自己体会最深的一条:二面挂掉之后,短期内重复投同一家公司的同类岗位,成功率不会因为你多刷了几十道题就显著提升,因为挂你的原因是结构性的。真正有效的是换个维度准备,把项目和数据层补扎实,过三到六个月再投,那时候你的变化才是可见的。我自己第一次二面挂掉之后硬刷了一个月题,第二次照样挂,直到把项目的归因逻辑彻底理清楚,情况才发生变化。

最后再分享一个小习惯:每次面试结束后,在手机备忘录里写三行字,第一行是今天最好的一个回答,第二行是最差的一个回答,第三行是下次一定要改的一件事。这个习惯坚持半年,你会发现自己挂掉的理由在逐渐收敛,从一个模糊的"我不行"变成一个具体的"我这个点还没准备好"。这种从模糊到具体的转变,比任何面试技巧都管用。

返回列表