个人技术博客：点击跳转
对于前端工程师来说，“跳槽”通常是提升收入水平的有效途径，但它也同时意味着你需要花费额外的时间和精力去准备面试，尤其是对于那些只有中小公司从业经历且首次备战大厂的技术人员而言是非常困难的。你看到很多人因为进入一线互联网公司而薪资大涨，却没有看到为了拿到这样的结果，他们在3~6个月的备战周期里付出了多少心血。那么我们应该如何看待技术面试，又如何更好地备战前端技术岗位的面试呢？本章就来聊聊面试那些事儿。
如何提升大厂面试的成功率？一个主要的战略就是“以战养战”。很多候选人都能够耐心地花上1~2个月的时间来整理和复习专业知识，但是面试的表现却总是不尽如人意，因为“知识储备”和“面试技巧”本来就是两码事。所谓“以战养战”，就是不断地参加面试，以此来提升自己的面试技巧，直到自己内心毫无波澜，这个时候再去冲刺大厂，成功的几率通常会大幅度提高，这本质上也是一个熟能生巧的过程。因为你怕面试，缺乏面试技巧，所以才更要去面试。其实，备战大厂和备考是非常类似的，我们上学时每个学期都要参加期末考试，但却很少会为此而感到特别焦虑，即使考试前会觉得紧张，也很少会达到焦虑的程度，因为你平常的主要任务就是学习，几乎每天都会写作业做练习题，不仅要参加月考和期中考试，还要做各种各样的真题试卷。经过大量的日常练习和模拟考试后，基本的知识点你早已了如指掌，对自己的学习情况基本上也有了比较准确的判断，期末考试不过就是走个流程罢了。
其实面试的最佳状态也是如此，只是候选人大都会花费大量的时间去复习知识点，而对实战演练的关注度不够，有的甚至压根都没怎么复习，仗着学校学历的优势直接投递大厂，可能自己觉得只是想满足一下好奇心，结果却莫名其妙地在面试记录里永久地留下了差评记录，导致未来的1~2年甚至更长的时间里，HR都不愿意再给你面试的机会。复习的过程中，你的知识储备一直在增加，但面试本身的技巧不会因此而提高，以至于很多人在真正进行面试的时候会紧张到语无伦次，甚至在压力面试或者边界测试的环节直接情绪崩溃。所以你要多练习去实战，实战的心态和做练习是完全不同的，只有反复经历这样的刻意练习，你才能够在真正的面试中稳定发挥自己的潜能。需要注意的是，千万不要拿大厂去做面试练习，大厂的面评都是有记录的，如果评价不好，就会对后续造成难以评估的影响。
参加实战练习的方式有很多种，比如找已经身在大厂的朋友帮自己做模拟面试，很多技术论坛也提供这样的服务，由大公司的资深面试官来帮你模拟面试并提供指导，当然最简单粗暴的方式就是在招聘软件上按待遇水平划分梯度来投简历，直接参加面试，这样做的好处是你会遇到各种不同风格的面试，心理承受能力会得到快速提升，拿到的优质Offer也可以有助于你增加信心，并帮助你撬动更好的Offer。需要注意的是，每次面试之后你都需要整理面试中的知识点，查漏补缺，夯实基础。当然，这个阶段通常也需要在掘金网、牛客网等技术论坛上多看看别人的面试经验，看这些内容并不是让你评估自己能答上来多少道题，而是针对那些不会的题去查漏补缺。在真正面对大厂的考核之前，所有的准备过程都是练习，你需要从这个过程中汲取更多的东西，针对自己实战中答得不够好的点再去加强，去调整自己表达的提纲，或者去完善简历的细节等，等到真正冲击一线企业的时候，你可能早就因为重复练习的次数太多而内心毫无波澜了。
大公司的面试通常都有一套标准化的流程，这就意味着只要你满足了客观要求，很大概率是能够拿到Offer的。前端岗位面试的要点大致可以分为简历、基础知识、数据结构和算法、框架&工程能力和综合素质这几个关键模块，比较合理的节奏是用3~6个月的时间将它们各个击破，然后去接受市场的检验，下面我们就针对这些关键点进行逐一解读。
首先是简历环节，作为考核流程的第一道门槛，大多数候选人对于它的重视程度是远远不够的。简历其实是面试官对你做事情态度的第一次考察，而面试的过程，更多的是对简历内容的真实性进行检验。当面试官不认识你的时候，简历其实就是你建立第一印象的机会，如果你还以为简历就是“简单讲一下自己过去的工作经历”，那就真的是想得太简单了，有的候选人甚至连简历上的排版都懒得对齐，从这个细节面试官就可以看出他做事情的态度。在网上找一个简洁的简历模板并不会花费你太多时间，但至少在某种程度上表现出你对这个岗位的重视，关于如何组织简历的内容，我们来讲讲2个比较重要的部分。
首先是项目经历，很多候选人在写项目经历时，都是先大致陈述一下自己所用的技术栈，然后描述某个项目做了一件什么事情、实现了哪些页面或功能。其实这是一种非常典型的无效描述，因为它几乎没有向面试官传递任何能够为你加分的信息。那比较推荐的做法是什么样的呢？你可以遵循STAR原则，也就是通过Situation（背景）、Target（目标）、Action（行为）、Result（结果）来梳理自己的项目，简短地描述项目的背景和目标，最好各用一句话概括就可以了。首先因为业务细节很可能是涉密信息所以不方便详细介绍，其次是面试官更感兴趣的是你在项目中使用的技术、处理问题的思路、自己的收获和成长、对团队的贡献等内容，也就是关于Action和Result的部分，而且面试本身就是为了评估你是否符合公司岗位的要求，而不是为了评估你之前参与的业务。这里如果有设计文稿或者数据支撑是最好的，你可以先简单介绍一下你使用的技术栈，然后用一些比较具体的例子来体现自己的技术、业务或是管理能力，举例如下。
-
承担了某个问题的技术攻关任务。
-
负责了某个系统的整体架构和技术选型。
-
沉淀了可复用的组件或模块。
-
进行了性能优化使得某些性能指标得到了提升。
-
负责的紧急或重要业务取得了良好的结果。
-
带领了其他研发人员一起做事。
-
推动了某种SOP流程，提高了团队的协作效率。
……
必要的时候，你也可以准备一些脱敏后的设计图或是作品以备在面试时进行展示。你需要知道的是，对于项目经历的描述本质上是一道证明题，它需要你列举项目经历中的事实和数据，来说服面试官相信你拥有较高的技术能力、业务熟悉度或者团队管理能力，而不是真的让你去讲项目本身的业务细节。在面试过程中做项目陈述的时候依然可以遵循STAR原则，能够条理清晰地表达是职业化的表现，当然前提是你在面试前已经对这些内容进行过多次练习。
其次是关于技术能力的描述，大致可以分为编程语言、计算机及网络原理、设计模式及架构、数据结构算法、框架原理、全家桶的使用、性能优化和其他加分项（比如某个细分领域的专项经验），每个点写1~2句话基本上就很丰富了，如果还是觉得写不出，有一个更简便的办法，就是找到目标部门的招聘信息，围绕着其中的招聘要求来写就可以了，当然底线是写在简历上的技术点是你真的能讲清楚的。这里需要注意的是，应尽量使用“熟练掌握”“了解”等字眼而避免使用“精通”，它极有可能加强你面试的难度，可能是某个面试官正好也对这方面有研究想要切磋一下，也可能是运气不好遭遇了喜欢故意刁难的面试官，无论是哪一种，对于候选人来说都是不利的。
总的来说，简历是你提供给面试官的“开放题考纲”，你写在简历上的东西，面试官必然会默认你已经掌握了，而且还有一些自己的思考和认知，千万不要给自己挖坑，连自己写在简历上的内容都讲不清楚是非常减分的。简历并不是你过往工作的“流水账”或是“功劳簿”，而是只要面试官说一句“请开始你的表演”，你就至少能条理清晰地讲10~15分钟的内容，把用到的技术从底层原理、设计思想、最佳实践等各个方面都讲得清清楚楚的，让听你讲的人感受到你对技术有追求、对业务有思考、对团队有贡献，这并不是即兴演讲，而是多次刻意练习之后才能做到的。多花一些时间打磨简历和自己的表达能力，等到真正面试的时候，你一定不会后悔。
在常规的面试流程里，简历通过评估后，你需要面对的第一轮考验就是考察你的前端基础，除了考察领域基本知识的掌握情况之外，这个环节其实也是对候选人态度和信息过滤能力的考察。为什么这么说呢？因为大家知道基础知识主要就是靠背诵，我们开玩笑称之为“八股文”。在这个环节中，其实不同的候选人需要面对的挑战也各不相同，在校生记忆力比较好，但很可能由于缺乏实践经验导致对一些知识点理解不深，很难顶住面试官对细节的追问；而社招候选人离开学校太久，对理论知识和最佳实践会有更深的理解，这时记忆反而成了较大的挑战，但如果你有练习前文中介绍的记忆法，那么相信记忆对你来说也并不困难。
有经验的面试官通常会在评估社招候选人时更关注他对知识理解的深度，而评估校招候选人时则优先关注知识的广度，如果把评估标准对调一下，很容易产生“怎么连这么简单的东西都不知道”的错觉。这也是笔者希望大家认真准备简历的原因，面试是有一定灰度和主观性的，想给你机会的面试官会帮助你挖掘亮点，而不想给你机会的面试官会揪住你的弱点不放，简历的印象分这种时候可能就会为你争取到额外的机会。笔者自己在面试中两种状况都遇见过，不得不说后一种真的会让整个面试过程特别压抑。有的人说这些东西平时又用不到，而且并不影响平时做业务开发，我为什么要浪费大量的时间来背这些东西呢？
之前有个创业的朋友跟我讲，其实每一个小的创业公司，都希望自己做出的产品是可迭代的，首先做出一个产品，获得了一批用户，然后根据用户的反馈来做功能迭代，接着吸引更多的用户，继续打磨这个产品，不断地积累直到最后将该产品做成功。每个创业者都是这样希望的，因为对公司来说这样做的成本是最小的，但实际上你会发现大部分中小企业都不太可能拥有这样幸运的机会，一路走来都是摸爬滚打、跌跌撞撞。今天做这个项目，明天做那个项目，最开始的两三年对一个小公司来说活下来就是最大的问题，谁都很难保证自己当下在做的事情对未来一定是有积累的，有的时候你不得不去做一些看起来没什么意义的事情。面试备战中背基础知识也是类似的道理，当你还没有能力去改变规则的时候，抱怨其实是没有用的。当你知道哪些事情是必须做的时候，只要下决心去攻克它就可以了，而不是说去抱怨这个规则来唤起其他人的共鸣，因为抱怨太廉价。
关于基础知识笔者想说的是，它并不是研究得越深越好。因为复习的时间总是不够的，你需要做的是**“在有限的复习时间内尽可能拿到更高的分数”，而不是去追求所谓的“吊打面试官”**。比如说编译原理，现代化的主流前端技术底层几乎都是基于它，很多朋友曾问我是否需要买那本厚厚的《编译原理》来进行系统地学习，我通常都会开玩笑说“你要觉得显示屏高度不够的话就买吧”。大部分前端工程师连工作中最常用的技术栈都还没掌握好，更不用提那些工作中几乎用不到的底层知识了，“掌握这些知识就会变得很厉害”可能只是你一厢情愿的错觉罢了。技术是个无底洞，我们不会的东西太多了，你不了解编译原理，很可能只需要学习一下the-super-tiny-compiler这个开源项目就可以了。它是一个非常简短的项目，实现了一个简易的编译器，代码中有非常详细的注释，你可以通过阅读源码来了解编译原理的各个阶段所做的事情，代码的范式、用到的设计模式等，然后尝试自行实现，遇到思路卡住的地方再返回去阅读源码，等最终自己“造出轮子”后，你掌握的编译原理知识基本上就够用了，然后在项目中遇到问题时可以考虑通过Babel、EsLint和PostCSS插件来解决，试着去编辑一下抽象语法树，如果能在团队内部做一些技术分享那就更好了。再比如面试考察候选人对于V8引擎的了解时，实际上有很大概率都会落到三个知识点上。第一就是对象的快慢属性，第二就是Orinoco垃圾回收，第三就是V8执行JavaScript为什么快，这些知识点会涉及V8如何解释执行JavaScript的一些过程，你只需要按照关键词去搜索一些资料进行专题学习就可以了，很多读者的收藏夹里可能都有V8团队官方博客的网址，但可能连一篇完整的文章都没有读下来过。
之所以说基础知识是对态度的考察，是因为社区里交流的面试经验或面试专题已经可以涵盖90%以上的题目了，基础知识的考点根本就不算是什么机密，只是你自己没有给予足够的重视罢了，比如常见的“数组和链表的区别”这道题，有人就只了解基本数据结构和两者在选型方面的倾向，但有人就会顺藤摸瓜去复习单链表、双向链表、循环链表以及全O(1)复杂度的数据结构和LRU算法等，还有人会结合框架源码来谈谈相关算法的使用场景，题目本身并不是什么秘密，但最终的面试结果可能就会大相径庭。你需要经常提醒自己，基础知识的复习是一个限时游戏，你需要在深度探索和广度发散之间找到平衡。
数据结构和算法的考核已经成为面试大厂必须要面对的挑战了，它是对候选人聪明程度和抽象能力的考察，某种程度上也是对于其做事态度的考察，因为不愿意学习数据结构和算法而直接打消了面试大厂的念头的人并不是少数。由于大学里并没有专门的前端专业，很多开发者都是通过自学或培训班转行进入这个领域的，在这样的背景下想要通过自学来掌握数据结构和算法题这类相对抽象的知识，需要付出的努力可想而知。
那我们该如何攻克这个模块呢？笔者认为误导性最大的建议就是“刷题”，准确地说是在还没有学习基础知识的情况下开始刷题，这就好像上学的时候不看课本直接做课后题一样，很容易导致事倍功半。数据结构和算法基础本来就是一门课程，有其自身的基本理论知识和技巧，解题的过程其实就是从实际问题中识别出抽象模型的过程，如果你连常见的抽象模型和它们的特点都不知道，那么面对题目的时候就会没有任何逻辑线索，刷题也是没有意义的。你所做的事情可能只不过是看着题目发呆20分钟，脑子里一片空白，然后去看答案背代码，刷了很多类似的题后，你可能会因为总结出了一些解题套路而沾沾自喜，殊不知很多技巧可能早就作为数据结构的特性写在书本里了，根本就不需要你自己再发明一次。这种备战方式会让你的面试表现更依赖于记忆力和运气，而不是逻辑思维，刷过的题自然很容易就能做出来，没刷过的题或者稍微变换一下就可能束手无策，更不用说关于数据结构的选型思路或算法复杂度分析的话题了。所以希望你在刷题之前，先建立基本的知识体系，搞清楚各个抽象结构的特点和常见操作的编程套路，认真做课后练习，然后再去刷题，这时你会发现自己更容易识别出题目的特点，是在考栈、队列、链表还是其他结构，适合采用哪种算法等，这样可能并不需要刷太多的题就能够达到大厂面试的要求，毕竟你面试的不是算法岗位。当然这方面的知识掌握得越牢固，给面试官的印象通常也会越好。
很多算法题的解法并不唯一，在真正面试的时候，你可以先使用暴力解法写出一个能运行的程序，然后再尝试使用复杂度更低的方法，这样即便没能写出更优的解法，至少也能保证这个环节是可以通过的。如果实在觉得没有思路，可以请面试官给予一些提示，或者要求更换题目。毕竟如果面试通过的话，你就是面试官未来的同事，尝试沟通一下又有什么关系呢？
框架和技术能力的考核通常会出现在第二轮面试中，用于考察候选人的技术深度、技术广度和工程化能力，最常见的问题就是项目经历和框架源码原理的掌握，如果你在写简历时已经觉得自己的“项目没亮点”或者“技术没深度”，可能更好的选择是推迟面试的计划，专门花一些时间去做相关的积累，既可以针对自己工作中的项目来进行挖掘，也可以另起炉灶自己做一些技术性更强的项目，而不是因为看到别人拿到心仪的Offer就觉得迫不及待，满脑子都是如何为了面试而“临时抱佛脚”。
首先如果你在日常开发中没有做项目复盘的习惯，那么一定要从现在开始养成这个习惯，每个需求迭代做完后尝试从项目、技术和管理三个方面去反思一下，最好能主动去找自己的直属领导或导师去沟通。笔者在做一线开发时，对工作中经手的所有项目都会编写《开发纪要》，内容包括这个项目有哪些协作方，每个人提供的资料分别是什么，重要的会议记录，过程实施中出现了什么问题，自己的代码设计方案，每天的工作日志，遇到了什么问题，自己有什么想法和建议，等等。等到特性发布上线后，自己会专门拿出一天的时间来，针对遇到的每个问题去查查业界的解决方案，或者提出自己的技术规划，并在未来的1~2个月内落实。这种方式虽然看起来很傻，但对于理清思路真的很有用，大家做的项目都是一样的业务开发，但我相信用心的人会收获更多。后来笔者把自己的《开发纪要》沉淀成了文档模板，分享给其他同事，要求自己指导的实习生每一轮迭代完成之后必须主动把《开发纪要》发给我，我会和他们一起来进行简单的复盘梳理。当你真正用心去做一些事的时候，进步就会更快，也正是这些看似无关紧要的小习惯，最终造成了你和别人之间的巨大差距。
其次，你可以去技术社区找一些整体设计方案类的文章，然后参考作者的思路来尝试复现一套系统，最好是能够与自己的工作实践结合起来，也就是所谓的“造轮子”，这里的关键点在于你一定要自己动手把这个系统做出来。在字节跳动的新人培训会上，主管经常会问新人这样一个问题：“字节跳动为什么要花很高的成本来深耕垂直类领域，而不是直接收购其他公司呢？”其实这其中的道理是一样的，因为只有“躬身入局”才能获得对市场的“一手信息”，从而建立正确的认知，并以此作为商业决策的依据。你可以尝试自己动手去落实一个项目，无论是关于埋点、告警监控、低代码搭建、数据可视化等任何一个领域都可以，在这个过程中你可能会产生很多关于细节的疑问或者新的想法，这时候再跟朋友讨论或者直接联系文章的作者进行咨询通常都会有不小的收获，很多时候你甚至会发现自己的思路和别人有非常多的契合点，这对自己而言是非常棒的精神鼓励。
对于你工作中使用的主流开发框架，无论是React、Vue还是Angular，如果日常开发中确实没有遇到过什么技术问题，则可以去官方代码仓库中的Issues里面去找，可能会有意想不到的收获，里面的问题算得上是应有尽有，尤其是框架版本迭代的时候有可能会带来非常多意料之外的影响，比如Vue2.x版本中对于nextTick方法的底层实现就发生过好多次更改，在应用层引发了很多莫名其妙的问题，这其实就是从问题下沉到实现原理，再下沉到设计思想的问题，很值得去研究和探讨。否则当面试官问你“使用框架的时候有没有遇到过什么问题，是怎么解决的呢？”你只能云淡风轻地回一句“没有遇到过”，然后两个人四目相对，场面尴尬至极。
面试的前期通常比较侧重于对面试者基础知识和技术能力的考察，而越到后期越注重对综合素质的考察。如果你想要在综合素质的考察中表现得出色，除了平时需要关注程序的设计思想、业界的技术会议、技术活动等以做好谈资的积累，还需要刻意练习自己口头表达的逻辑性和条理性，也就是掌握职场技能中非常重要的“结构化思维”。逻辑思维能力并不一定是与生俱来的，它是一项技能而不是一种天赋，这就意味着普通人通过学习和练习也可以掌握。关于“结构化思维”的话题，你在网上可以找到很多相关的资料，它们可能涉及“金字塔原理”或者“麦肯锡方法”之类的关键词，笔者接下来只做一些简单的介绍。无论多好的方法，都是只有通过练习和实践把它变为自己的技能后你才会受益，“知道但做不到”的人满大街都是，希望你不要成为其中的一员。
**“结构化思维”**通俗地讲就是指你在描述一件事情之前，对于如何描述这件事要有一个“自顶向下”或是“分解结构”的思维框架，相当于头脑中要有一个大纲，这样在表达的时候更容易表现出思维的条理性，而不是让人觉得你想到哪说到哪。比如这样一道智力题，200毫升的水怎么放到100毫升的杯子里？很多人可能会说喝掉一半水，或者说换个大杯子，或者其他什么答案，越脑洞大开越开心，还觉得自己想象力特别丰富，问题在于这道题压根就不是用来考察想象力的，工作中更需要的是逻辑思维能力。
那么我们如何让自己的表达更具有条理性呢？首先200毫升的水为什么无法直接放进100毫升的杯子里，因为水比较多而杯子的容积比较小，那么解决这个问题的两个主要方向一是尝试减少水的量，二是尝试增加杯子的容积。然后再分别向着这两个方向进行完善，这样对方就更容易跟上你的思路了，因为他心里已经有了一个提前声明的认知结构（就是指分为两个主要方向）。如果你仔细想想就会发现，上面的思路似乎并不完备，比如我们可以将水冻成特殊形状的冰块，变成固体后它也能放在杯子里，这种情况下水的量也没有减少，杯子的容积也没有变大，但依然可以满足题目的要求，你可能会突然意识到最初的思维框架并没有考虑到水的形态造成的影响，那这道题是做错了吗？不重要。还记得吗，面试考核的重点永远都是你，面试是为了评估你，对面试官而言重要的是看到你面对一个问题时是如何分析、思考和规划的，有条理地描述自己如何分析一个问题比问题的答案更重要，而且复盘和纠偏本来就是日常工作中经常发生的事情。
下面再来看一个经典的三分法结构“是什么，为什么，怎么样”的实例。有一次技术群里大家在讨论一道前端面试题“TCP连接为什么要握手三次”，当时就有人抛出答案说，因为服务端的socket是有数量限制的，他说的可能是对的，但是我确实没能明白这个答案与问题有什么直接关系，也有人给出了这样的回答“因为三次握手更可靠，客户端首先发送XXX报文给服务端……”我当时看到这个题，脑子里很快就拟定了“是什么、为什么、怎么样”的提纲，接着就在群里分享了自己的思路，如下。
-
先提及自己会按照“是什么”“为什么”“怎么样”这三个点来解答，给听的人一个基本的认知框架和心理预期。
-
是什么？首先讲什么是TCP，它是一个安全可靠的全双工连接。
-
为什么？然后讲为什么三次握手就可靠，只有两次握手的话可能会发生什么问题。
-
怎么样？最后详细聊聊TCP连接在三次握手时报文中的关键信息。
如果把“结构化”的陈述从答案中去掉，其实内容与你给出的答案基本上是一致的，但有了“结构化”的辅助，整体的回答就会让对方觉得条理更清晰了。如果你对HTTP3有一定的了解，就会知道它的底层是基于UDP来传输的，但依然需要做到可靠传输，在解答完整个题目后，你就可以很自然地主动引导话题“其实说到可靠传输，尽管HTTP3中使用的协议是UDP，但是……”，这样在面试中很容易就能把话题延续下去，把一个话题聊开聊透是能够有效提高面试官好感度的，不过这对于你的知识储备也是一种考验。
当然上面的示例并不是唯一的“三点结构”，当我们复盘项目时可能会按照**“事前、事中和事后”三个阶段来进行拆分，再比如谈及能力模型时通常会按照“技术、业务、管理”三个部分来进行拆分，再比如之前提及的STAR原则就需要4个维度，业务上做用户留存分析时常用的AARRR漏斗模型**，就是将用户生命周期分为5个阶段……更复杂的问题可能需要更复杂的方法论来解决，它们的价值就在于帮助你将高复杂度的问题分解为多个或者多级低复杂度的问题，从而为解决问题找到突破口。结构化思维的练习其实就是帮助我们练习职场中分析和思考问题的基本模式。至于如何更有效地培养结构化思维，你可以阅读更多专业的书籍，本书就不再展开了。
除了表达技巧，平时对于行业动态的关注也很重要，你可以尝试自己写技术博客，关于如何写作，前面的文章已经介绍过了，你需要做的是主动思考，而不仅仅是摘抄知识点；另外也可以多关注国外的技术会议，你会发现面试中遇到的很多开放题，通常都可以从一些业界大咖在技术演讲中分享的观点里找到解答思路。为什么提到国外的技术会议？因为国内技术大会的技术分享更关注于技术的实现细节和业务实践的应用，如果没有相关的背景知识或领域知识是很难听懂的；而国外的技术大会在设计思想和问题本身上的探讨非常多，很多都是在讲自己遇到了一个什么问题，是怎么思考的，怎么解决的，现场演示的代码看起来也比较简单，因为很多复杂的技术方案都沉淀到底层了，这些知识对于大家在面试时回答开放题是非常有帮助的。比如面试中可能经常会被问到React和Vue框架该如何选型，你可能已经有自己的答案了，但如果你看过尤雨溪在2019年JSConf上的主题演讲《在框架设计中寻求平衡》，再结合自己的认知，也许就能得出更棒的答案。另一方面，国外的技术分享视频中经常会带有大量的动画，这对于开发者理解一些抽象的概念或者过程也是非常有帮助的，希望你不要错过。
每一份令人羡慕的成功背后，都有着不为人知的努力和付出，你会发现其实备战大厂面试的思路与我们以前上学时学习考试并没有什么本质区别，认真去做了，结果总不会太差，愿你能坚定地做自己喜欢的事，愿你能早日取得心仪的Offer。关于面试的话题，如果你还有什么希望深入探讨的，欢迎直接与我联系.