1
0
mirror of https://github.com/Snailclimb/JavaGuide synced 2025-06-16 18:10:13 +08:00

[feat] add 技术文章精选集

This commit is contained in:
guide 2021-11-13 09:03:37 +08:00
parent 4b020ed970
commit b2ba399ef8
5 changed files with 594 additions and 23 deletions

View File

@ -53,7 +53,8 @@ module.exports = config({
items: [
{ text: "Java书单精选", icon: "book", link: "https://gitee.com/SnailClimb/awesome-cs" },
{ text: "Java学习路线", icon: "luxianchaxun", link: "https://zhuanlan.zhihu.com/p/379041500" },
{ text: "Java开源项目精选", icon: "git", link: "https://gitee.com/SnailClimb/awesome-java" }
{ text: "Java开源项目精选", icon: "git", link: "https://gitee.com/SnailClimb/awesome-java" },
{ text: "Java技术文章精选集", icon: "star", link: "/high-quality-technical-articles/" }
],
},
{ text: "IDEA指南", icon: "intellijidea", link: "/idea-tutorial/", },
@ -71,41 +72,35 @@ module.exports = config({
},
],
sidebar: {
// 应该把更精确的路径放置在前边
"/about-the-author/": [
"internet-addiction-teenager", "feelings-after-one-month-of-induction-training", "feelings-of-half-a-year-from-graduation-to-entry",
"my-article-was-stolen-and-made-into-video-and-it-became-popular",
],
// 应该把更精确的路径放置在前边
'/tools/': [
{
title: "数据库",
icon: "database",
prefix: "database/",
collapsable: false,
title: "数据库", icon: "database", prefix: "database/", collapsable: false,
children: ["CHINER", "DBeaver", "screw"]
},
{
title: "Git",
icon: "git",
prefix: "git/",
collapsable: false,
title: "Git", icon: "git", prefix: "git/", collapsable: false,
children: ["git-intro", "github技巧"]
},
{
title: "Docker",
icon: "docker1",
prefix: "docker/",
collapsable: false,
title: "Docker", icon: "docker1", prefix: "docker/", collapsable: false,
children: ["docker", "docker从入门到实战"]
},
],
'/high-quality-technical-articles/': [
{
title: "面试", icon: "mianshixinxi-02", prefix: "interview/",
children: ["the-experience-and-thinking-of-an-interview-experienced-by-an-older-programmer", "technical-preliminary-preparation"]
},
],
'/idea-tutorial/':
[
{
title: "IDEA小技巧",
icon: "creative",
prefix: "idea-tips/",
collapsable: false,
title: "IDEA小技巧", icon: "tips", prefix: "idea-tips/", collapsable: false,
children: [
"idea-refractor-intro",
"idea-plug-in-development-intro",
@ -113,10 +108,7 @@ module.exports = config({
]
},
{
title: "IDEA插件推荐",
icon: "plugin",
collapsable: false,
prefix: "idea-plugins/",
title: "IDEA插件推荐", icon: "chajian1", collapsable: false, prefix: "idea-plugins/",
children: [
"shortcut-key", "idea-themes", "improve-code", "interface-beautification",
"camel-case", "code-glance", "code-statistic",

View File

@ -1,2 +1,2 @@
// import icon
@import '//at.alicdn.com/t/font_2922463_74fu8o5xg3.css'
@import '//at.alicdn.com/t/font_2922463_7kdnrkx8wsh.css'

View File

@ -0,0 +1,213 @@
---
title: 从面试官和候选者的角度谈如何准备技术初试
category: 技术文章精选集
tag:
- 面试
---
> **内容总结:**
>
> 从面试官和面试者两个角度探讨了技术面试!非常不错!
>
> - 通过技术基础考察候选者,才能考察到候选者的真实技术实力:技术深度和广度。
> - 实战与理论结合。比如,候选人叙述 JVM 内存模型布局之后,可以接着问:有哪些原因可能会导致 OOM , 有哪些预防措施? 你是否遇到过内存泄露的问题? 如何排查和解决这类问题?
> - 项目经历考察不宜超过两个。因为要深入考察一个项目的详情,所占用的时间还是比较大的。一般来说,会让候选人挑选一个他或她觉得最有收获的/最有挑战的/印象最深刻的/自己觉得特有意思的项目。然后围绕这个项目进行发问。通常是从项目背景出发,考察项目的技术栈、项目模块及交互的整体理解、项目中遇到的有挑战性的技术问题及解决方案、排查和解决问题、代码可维护性问题、工程质量保障等。
> - 多问少说,让候选者多表现。根据候选者的回答适当地引导或递进或横向移动。
>
> **原文地址:** https://www.cnblogs.com/lovesqcc/p/15169365.html
## 考察目标和思路
首先明确,技术初试的考察目标:
- 候选人的技术基础;
- 候选人解决问题的思路和能力。
技术基础是基石(冰山之下的东西),占七分, 解决问题的思路和能力是落地(冰山之上露出的部分),占三分。 业务和技术基础考察,三七开。
## 技术基础考察
### 为什么要考察技术基础?
程序员最重要的两种技术思维能力,是逻辑思维能力和抽象设计能力。逻辑思维能力是基础,抽象设计能力是高阶。 考察技术基础,正好可以同时考察这两种思维能力。能不能理解基础技术概念及关联,是考察逻辑思维能力;能不能把业务问题抽象成技术问题并合理的组织映射,是考察抽象设计能力。
绝大部分业务问题,都可以抽象成技术问题。在某种意义上,业务问题只是技术问题的领域化表述。
因此,**通过技术基础考察候选者,才能考察到候选者的真实技术实力:技术深度和广度。**
### 技术基础怎么考察?
技术基础怎么考察?通过有效的多角度的发问模式来考察。
#### 是什么-为什么
是什么考察对概念的基本理解,为什么考察对概念的实现原理。
比如:索引是什么? 索引是如何实现的?
#### 引导-横向发问-深入发问
引导性,比如 “你对 Java 同步工具熟悉吗?” 作个试探,得到肯定答复后,可以进一步问: “你熟悉哪些同步工具类?” 了解候选者的广度;
获取候选者的回答后,可以进一步问:“ 谈谈 `ConcurrentHashMap``AQS` 的实现原理?”
一个人在多大程度上把技术原理能讲得清晰,包括思路和细节,说明他对技术的掌握能力有多强。
#### 跳跃式/交叉式发问
比如:讲到哈希高效查找,可以谈谈哈希一致性算法 。 两者既有关联又有很多不同点。也是一种技术广度的考察方法。
#### 总结性发问
比如:你在做 XXX 中,获得了哪些可以分享的经验? 考察候选人的归纳总结能力。
#### 实战与理论结合
比如,候选人叙述 JVM 内存模型布局之后,可以接着问:有哪些原因可能会导致 OOM , 有哪些预防措施? 你是否遇到过内存泄露的问题? 如何排查和解决这类问题?
比如,候选人有谈到 SQL 优化和索引优化,那就正好谈谈索引的实现原理,如何建立最佳索引?
再比如,候选人有谈到事务,那就正好谈谈事务实现原理,隔离级别,快照实现等;
#### 熟悉与不熟悉结合
针对候选人简历上写的熟悉的部分,和没有写出的都问下。比如候选人简历上写着:熟悉 JVM 内存模型, 那我就考察下内存管理相关(熟悉部分),再考察下 Java 并发工具类(不确定是否熟悉部分)。
#### 死知识与活知识结合
比如,查找算法有哪些?顺序查找、二分查找、哈希查找。这些大家通常能说出来,也是“死知识”。
这些查找算法各适用于什么场景?在你工作中,有哪些场景用到了哪些查找算法?为什么? 这些是“活知识”。
#### 学习或工作中遇到的
有时,在学习和工作中遇到的问题,也可以作为面试题。
比如,最近在学习《操作系统导论》并发部分,有一章节是如何使数据结构成为线程安全的。这里就有一些可以提问的地方:如何实现一个锁?如何实现一个线程安全的计数器?如何实现一个线程安全的链表?如何实现一个线程安全的 `Map` ?如何提升并发的性能?
工作中遇到的问题,也可以抽象提炼出来,作为技术基础面试题。
#### 技术栈适配度发问
如果候选人(简历上所写的)使用的某些技术与本公司的技术栈比较契合,则可以针对这些技术点进行深入提问,考察候选人在这些技术点的掌握程度。如果掌握程度比较好,则技术适配度相对更高一些。
当然,这一点并不能作为筛掉那些没有使用该技术栈的候选人的依据。比如本公司使用 `MongoDB``MySQL` 而一个候选人没有用过 `Mongodb` 但使用过 `MySQL`, `Redis`, `ES`, `HBase` 等多种存储系统,那么适配度并不比仅使用过 `MySQL``MongoDB` 的候选人逊色,因为他所涉及的技术广度更大,可以推断出他有足够能力掌握 `Mongodb`
#### 创造有个性的面试题库
每个技术面试官都会有一个面试题库。持续积累面试题库,日常中突然想到的问题,就随手记录下来。
## 业务维度考察
### 为什么要考察业务维度?
技术基础考察,容易错过的地方是,候选人的非技术能力特质,比如沟通组织能力、带项目能力、抗压能力、解决实际问题的能力、团队影响力、其它性格特质等。
### 为什么不能单考察业务维度?
因为业务方面通常比较熟悉,可能就直接按照现有方案说出来了,很难考察到候选人的深入理解、横向拓展和归纳总结能力。
这一点,建议有针对性地考察下候选人的归纳总结能力:比如, 微服务搭建或开发或维护/保证系统稳定性或性能方面的过程中,你收获了哪些可以分享的经验?
## 解决问题能力考察
仅仅只是技术基础还不够,通常最好结合实际业务,针对他项目里的业务,抽象出技术问题进行考察。
解决思路重在层层递进。这一点对于面试官的要求也比较高,兼具良好的倾听能力、技术深度和业务经验。首先要仔细倾听候选人的阐述,找到适当的技术切入点,然后进行发问。如果进不去,那就容易考察失败。
### 设计问题
- 比如多个机器间共享大量业务对象,这些业务对象之间有些联合字段是重复的,如何去重?
- 如果瞬时有大量请求涌入,如何保证服务器的稳定性?
### 项目经历
项目经历考察不宜超过两个。因为要深入考察一个项目的详情,所占用的时间还是比较大的。
一般来说,会让候选人挑选一个他或她觉得最有收获的/最有挑战的/印象最深刻的/自己觉得特有意思的项目。然后围绕这个项目进行发问。通常是从项目背景出发,考察项目的技术栈、项目模块及交互的整体理解、项目中遇到的有挑战性的技术问题及解决方案、排查和解决问题、代码可维护性问题、工程质量保障等。
## 面试官如何做好一场面试?
### 预先准备
面试官也需要做一些准备。比如熟悉候选者的技能优势、工作经历等,做一个面试设计。
在面试将要开始时,做好面试准备。此外,面试官也需要对公司的一些基本情况有所了解,尤其是公司所使用技术栈、业务全景及方向、工作内容、晋升制度等,这一点技术型候选人问得比较多。
### 面试启动
一般以候选人自我介绍启动,不过候选人往往会谈得比较散,因此,我会直接提问:谈谈你有哪些优势以及自己觉得可以改进的地方?
然后以一个相对简单的基础题作为技术提问的开始:你熟悉哪些查找算法?大多数人是能答上顺序查找、二分查找、哈希查找的。
### 问题设计
提前阅读候选人简历,从简历中筛选出关键词,根据这些关键词进行有针对性地问题设计。
比如候选人简历里提到 `MVVM` ,可以问 `MVVM``MVC` 的区别; 提到了观察者模式,可以谈谈观察者模式,顺便问问他还熟悉哪些设计模式。
### 宽松氛围
即使问的问题比较多比较难,也要注意保持宽松氛围。
在面试前,根据候选人基本信息适当调侃一下,比如一位候选人叫汪奎,那我就说:之前我们团队有位叫袁奎,我们都喊他奎爷。
在面试过程中,适当提示,或者给出少量自己的看法,也能缓解候选人的紧张情绪。
### 学会倾听
多问少说,让候选者多表现。根据候选者的回答适当地引导或递进或横向移动。
引导候选人表现他最优势的一面,让他或她感觉好一些:毕竟一场面试双方都付出了时间和精力,不应该是面试官 Diss 候选人的场合,而应该让彼此有更好的交流。很大可能,你也能从候选人那里学到不少东西。
面试这件事,只不过双方的角色和立场有所不同,但并不代表面试官的水平就一定高于候选人。
### 记录重点
认真客观地记录候选人的回答,尽可能避免任何主观评价,亦不作任何加工(比如自己给总结一下,总结能力也是候选人的一个特质)。
## 作出判断
面试过程是一种铺垫,关键的是作出判断。
作出判断最容易陷入误区的是:贪深求全。总希望候选人技术又深入又全面。实际上,这是一种奢望。如果候选人的技术能力又深入又全面,很可能也会面临两种情况:
1. 候选人有更好的选择;
2. 候选人在其它方面可能存在不足,比如团队协作方面。
一个比较合适的尺度是:
1. 他或她的技术水平能否胜任当前工作;
2. 他或她的技术水平与同组团队成员水平如何;
3. 他或她的技术水平是否与年限相对匹配,是否有潜力胜任更复杂的任务。
**不同年龄看重的东西不一样。**
对于三年以下的工程师,应当更看重其技术基础,因为这代表着他的未来潜能;同时也考察下他在实际开发中的体现,比如团队协作、业务经验、抗压能力、主动学习的热情和能力等。
对于三年以上的工程师,应当更看重其业务经验、解决问题能力,看看他或她是如何分析具体问题,在业务范畴内考察其技术基础的深度和广度。
如何判断一个候选人的真实技术水平及是否适合所需,这方面,我也在学习中。
## 给候选人的话
### 关注技术基础
一个常见的疑惑是:开发业务系统的大多数时候,基本不涉及数据结构与算法的设计与实现,为什么要考察 `HashMap` 的实现原理?为什么要学好数据结构与算法、操作系统、网络通信这些基础课程?
现在我可以给出一个答案了:
- 正如上面所述,绝大多数的业务问题,实际上最终都会映射到基础技术问题上:数据结构与算法的实现、内存管理、并发控制、网络通信等;这些是理解现代互联网大规模程序以及解决程序疑难问题的基石,—— 除非能祝福自己永远都不会遇到疑难问题,永远都只满足于编写 CRUD
- 这些技术基础正是程序世界里最有趣最激动人心的地方。如果对这些不感兴趣,就很难在这个领域里深入进去,不如及早转行从事其它职业,非技术的世界一直都很精彩广阔(有时我也想多出去走走,不想局限于技术世界);
- 技术基础是程序员的内功,而具体技术则是招式。徒有招式而内功不深,遇到高手(优秀同行从业者的竞争及疑难杂症)容易不堪一击;
- 具备扎实的专业技术基础,能达到的上限更高,未来更有可能胜任复杂的技术问题求解,或者在同样的问题上能够做到更好的方案;
- 人们喜欢跟与自己相似的人合作,牛人倾向于与牛人合作能得到更好的效果;如果一个团队大部分人技术基础比较好,那么进来一个技术基础比较薄弱的人,协作成本会变高;如果你想和牛人一起合作拿到更好的结果,那就要让自己至少在技术基础上能够与牛人搭配的上;
- 在 CRUD 的基础上拓展其它才能也不失为一种好的选择但这不会是一个真正的程序员的姿态顶多是有技术基础的产品经理、项目经理、HR、运营、客满等其它岗位人才。这是职业选择的问题已经超出了考察程序员的范畴。
### 不要在意某个问题回答不上来
如果面试官问你很多问题,而有些没有回答上来,不要在意。面试官很可能只是在测试你的技术深度和广度,然后判断你是否达到某个水位线。
重点是:有些问题你答得很有深度,也体现了你的深度思考能力。
这一点是我当了技术面试官才领会到的。当然,并不是每位技术面试官都是这么想的,但我觉得这应该是个更合适的方式。

View File

@ -0,0 +1,361 @@
---
title: 一位大龄程序员所经历的面试的历炼和思考
category: 技术文章精选集
tag:
- 面试
---
> **内容总结**
>
> 本文的作者,今年 36 岁,已有 8 年 JAVA 开发经验。在阿里云三年半,有赞四年半,已是标准的大龄程序员了。
>
> 下面是本文作者关于面试和个人能力提升的一些小建议(很实用)
>
> 1. 个人介绍,是对自己的一个更为清晰、深入和全面的认识契机。
> 2. 简历是充分展示自己的浓缩精华,也是重新审视自己和过往经历的契机。不仅仅是简要介绍技能和经验,更要最大程度凸显自己的优势领域(差异化)。
> 3. 我个人是不赞成海投的,而倾向于定向投。找准方向投,虽然目标更少,但更有效率。
> 4. 技术探索,一定要先理解原理。原理不懂,就会浮于表层,不能真正掌握它。技术原理探究要掌握到什么程度?数据结构与算法设计、考量因素、技术机制、优化思路。要在脑中回放,直到一切细节而清晰可见。如果能够清晰有条理地表述出来,就更好了。技术原理探究,一定要看源码。看了源码与没看源码是有区别的。没看源码,虽然说得出来,但终是隔了一层纸;看了源码,才捅破了那层纸,有了自己的理解,也就能说得更加有底气了。当然,也可能是我缺乏演戏的本领。
> 5. 要善于从失败中学习。正是在杭州四个月空档期的持续学习、思考、积累和提炼,以及面试失败的反思、不断调整对策、完善准备、改善原有的短板,采取更为合理的方式,才在回武汉的短短两个周内拿到比较满意的 offer 。
> 6. 面试是通过沟通来理解双方的过程。面试中的问题,千变万化,但有一些问题是需要提前准备好的。
>
> **原文地址** https://www.cnblogs.com/lovesqcc/p/14354921.html
从每一段经历中学习,在每一件事情中修行。善于从挫折中学习。
## 引子
我今年 36 岁,已有 8 年 JAVA 开发经验。在阿里云三年半,有赞四年半,已是标准的大龄程序员了。
在多年的读书、学习和思考中我的价值观、人生观和世界观也逐步塑造成型。我意识到自己的志趣在于做教育文化方面因此在半冲动之下8 月份下旬,裸辞去找工作了。有限理性难以阻挡冲动的个性。不建议裸辞,做事应该有规划、科学合理。
尽管我最初认为自己“有理想有目标有意愿有能力”,找一份教育开发的工作应该不难,但事实上我还是过于乐观了。现实很快给我泼了一瓢瓢冷水。我屡战屡败,又屡败屡战。惊讶地发现自己还有这个韧性。面试是一项历炼,如果没有被失败击倒,那么从中会生长出一份韧性,这种韧性能让人走得更远。谁没有经历过失败的历练呢?失败是最伟大的导师了,如果你愿意跟他学一学的话。
在面试的过程中,我很快发现自己的劣势:
- 投入精力做业务,技术深度不够,对原理的理解局限于较浅的层次;
- 视野不够开阔,局限于自己所做的订单业务线,对其它关联业务线(比如商品、营销、支付等)了解不够;
- 思维不够开阔,大部分时间投入在开发和测试上,对运维、产品、业务、商业层面思考都思考不多;
- 缺乏管理经验,年龄偏大;这两项劣势我一度低估,但逐渐凸显出来,甚至让我一度不自信,但最终我还是走出来了。
但我也有自己的优势。职业竞争的基本法则是稀缺性和差异化。能够解决大型项目的架构设计和攻克技术难题,精通某个高端技术领域是稀缺性体现;而能够做事能做到缜密周全精细化,有高并发大流量系统开发经验,则是差异性体现。稀缺性是上策,差异化是中策,而降格以求就是下策了。
我缺乏稀缺性优势,但还有一点差异化优势:
- 对每一份工作都很踏实,时间均在 3 年 - 5 年之间,有一点大厂光环,能获得更多面试机会(虽然不一定能面上);
- 坚持写博客,孜孜不倦地追求软件开发的“道”,时常思考记录开发中遇到的问题及解决方案;
- 做事认真严谨,能够从整体分析和思考问题,也很注重基础提升;
- 对工程质量、性能优化、稳定性建设、业务配置化设计有实践经验;
- 大流量微服务系统的长期开发维护经验。
我投出简历的公司并不多。在不多的面试中,我逐渐意识到网上的“斩获几十家大厂 offer”的说法并不可信。理由如下
- 如果能真斩获大量大厂 offer ,面试的级别很大概率是初级工程师。要知道面试 4 年以上的工程师,面试的深度和广度令人发指,从基础的算法、到各种中间件的原理机制到实际运维架构,无所不包,真个是沉浸在“技术的海洋”,除非一个人的背景和实力非常强大,平时也做了非常深且广的沉淀;
- 一个背景和实力非常强大的人,是不会有兴趣去投入这么多精力去面各种公司,仅仅是为了吹嘘自己有多能耐;实力越强的人,他会有自己的选择逻辑,投的简历会更定向精准。话说,他为什么不花更多精力投入在那些能够让他有最大化收益的优秀企业呢?
- 培训机构做的广告。因为他们最清楚新手需要的是信心,哪怕是伪装出来的信心。
好了,闲话不多说了。我讲讲自己在面试中所经受的历练和思考吧。
## 准备工作
人生或许很长,但面试的时间很短,最长不过一小时或一个半小时。别人如何在短短一小时内能够更清晰地认识长达三十多年的你呢?这就需要你做大量细致的准备工作了。在某种程度上,面试与舞蹈有异曲同工之妙:台上五分钟,台下十年功。
准备工作主要包括简历准备、个人介绍、公司了解、技术探索、表述能力、常见问题、中高端职位、好的心态。准备工作是对自身和对外部世界的一次全面深入的重新认知。
初期,我以为自己准备很充分,简历改改就完事了。随着一次次受挫,才发现自己的准备很不充分。在现在的我看来,准备七分,应变三分。准备,就是要知己知彼,知道对方会问哪些问题(通常是系统/项目/技术的深度和广度)、自己应当如何作答;应变,就是当自己遇到不会、不懂、不知道的问题时,如何合理地展示自己的解决思路,以及根据面试中答不上来的问题查漏补缺,夯实基础。
这个过程,实际上也是学习的过程。持续的反思和提炼、学习新的内容、重新认识自己和过往经历等。
### 简历准备
最开始,我做得比较简单。把以前的简历拿出来,添加上新的工作经历,略作修改,但整体上模板基本不变。
在基本面上,我做的是较为细致的,诚实地写上了自己擅长和熟悉的技能和经验经历,排版也尽力做得整洁美观(学过一些 UI 设计)。不浮夸也不故作谦虚。
在扩展面上,我做的还是不够的。有一天,一位猎头打电话给我,问:“你最大的优势是什么?”。我顿时说不上来。当时也未多加思考。在后续面试屡遭失败之后,一度有些不自信之后,我开始仔细思考自己的优势来。然后将“对工程质量、性能优化、稳定性建设、业务配置化设计有深入思考和实践经验”写在了“技能素养”栏的第一行,因为这确实是我所做过的、最实在且脚踏实地的且具备概括性的。
有时,简历内容的编排顺序也很重要。之前,我把掌握的语言及技术写在前面,而“项目管理能力和团队影响力”之类的写在后面。但投年糕妈妈之后,未有面试直接被拉到不合适里面,受到了刺激,我意识到或许是对方觉得我管理经验不足。因此,刻意将“项目管理能力和团队影响力”提到了前面,表示自己是重视管理方面的,不过,投过新的简历之后,没有回应。我意识到,这样的编排顺序可能会让人误解我是管理能力偏重的(事实上有一位 HR 问我是不是还在写代码),但实际上管理方面我是欠缺的,最后,我还是调回了原来的顺序,凸出自己“工程师的本色”。后面,我又做了一些语句的编排上的修改。
随着面试的进展有时也会发现自己的简历上写得不够或者以前做得不够的地方。比如在订单导出这段经历里我只是写了大幅提升性能和稳定性显得定性描述化因此我添加了一些量化的东西2w 阻塞 => 300w+1w/1min作为证实比如8 月份离职,到 12 月份面试的时候,有一段空档期,有些企业会问到这个。因此,我索性加了一句话,说明这段时间我在干些啥;比如,代表性系统和项目,每一个系统和项目的价值和意义(不一定写在上面,但是心里要有数)。功夫要下足。
再比如,我很详细地写了有赞的工作经历及经验,但阿里云的那段基本没动。而有些企业对这段经历更感兴趣,我却觉得没太多可说的,留在脑海里的只有少量印象深刻的东西,以及一些博客文章的记录,相比这段工作经历来说显得太单薄。这里实质上不是简历的问题,而是过往经历复盘的问题。建议,在每个项目结束后,都要写个自我复盘。避免时间将这些可贵的经历冲淡。
每个人其实都有很多可说的东西,但记录下来的又有多少呢?值得谈道的有多少呢?过往不努力,面试徒伤悲。
**简历更新的心得**
- 简历是充分展示自己的浓缩精华,也是重新审视自己和过往经历的契机;
- 不仅仅是简要介绍技能和经验,更要最大程度凸显自己的优势领域(差异化);
- 增强工作经历的表述,凸显贡献,赢得别人的认可;
- 复盘并记录每一个项目中的收获,为跳槽和面试打下好的铺垫。
### 个人介绍
面试前通常会要求做个简要的个人介绍。个人介绍通常作为进入面试的前奏曲和缓冲阶段,缓和下紧张气氛。
我最开始的个人介绍个性啊业余生活啊工作经历啊志趣啊等等似乎不知道该说些什么。实际上个人介绍是一个充分展示自己的主页。主页应当让自己最最核心的优势一目了然需要挖掘自己的经历并仔细提炼。我现在的个人介绍一般会包括个性比如偏安静、做事风格工作认真严谨、注重质量、善于整体思考、最大优势owner 意识、执行力、工程把控能力)、工作经历简述(在每个公司的工作负责什么、贡献了什么、收获了什么)。个人介绍简明扼要,无需赘言。
个人介绍,是对自己的一个更为清晰、深入和全面的认识契机。
### 公司了解
很多人可能跟我一样,对公司业务了解甚少,就直接投出去了。这样其实是不合理的。首先,我个人是不赞成海投的,而倾向于定向投。找准方向投,虽然目标更少,但更有效率。这跟租房一样,我一般在豆瓣上租房,虽然目标源少,但逮着一个就是好运。
投一家公司,是因为这家公司符合意向,值得争取,而不是因为这是一家公司。就像找对象,不是为了找一个女人。要确定这家公司是否符合意向,就应当多去了解这家公司:主营业务、未来发展及规划、所在行业及地位、财务状况、业界及网络评价等。
在面试的过程中适当谈到公司的业务及思考,是可加分项。亦可用于“你有什么想问的?”的提问。
### 技术探索
技术能力是一个技术人的基本素养。因此,我觉得,无论未来做什么工作,技术能力过硬,总归是最不可或缺的不可忽视的。
原理和设计思想是软件技术中最为精髓的东西。一般软件技术可以分为两个方面:
- 原理:事物如何工作的基本规律和流程;
- 架构:如何组织大规模逻辑的艺术。
**技术探索,一定要先理解原理。原理不懂,就会浮于表层,不能真正掌握它。技术原理探究要掌握到什么程度?数据结构与算法设计、考量因素、技术机制、优化思路。要在脑中回放,直到一切细节而清晰可见。如果能够清晰有条理地表述出来,就更好了。**
**技术原理探究,一定要看源码。看了源码与没看源码是有区别的。没看源码,虽然说得出来,但终是隔了一层纸;看了源码,才捅破了那层纸,有了自己的理解,也就能说得更加有底气了。当然,也可能是我缺乏演戏的本领。**
我个人不太赞成刷题式面试。虽然刷题确实是进厂的捷径,但也有缺点:
- 它依然是别人的知识体系,而不是自己总结的知识体系;
- 技术探究是为了未来的工作准备,而不是为了应对一时之需,否则即使进去了还是会处于麻痹状态。
经过系统的整理,我逐步形成了适合自己的技术体系结构:[“互联网应用服务端的常用技术思想与机制纲要”](https://www.cnblogs.com/lovesqcc/p/13633409.html) 。在这个基础上,再博采众长,看看面试题进行自测和查漏补缺,是更恰当的方式。我会在这个体系上深耕细作。
### 表述能力
目前,绝大多数企业的主要面试形式是通过口头沟通进行的,少部分企业可能有笔试或机试。口头沟通的形式是有其局限性的。对表述能力的要求比较高,而对专业能力的凸显并不明显。一个人掌握的专业和经验的深度和广度,很难通过几分钟的表述呈现出来。往往深度和广度越大,反而越难表述。而技术人员往往疏于表达。
我平时写得多说得少说起来不利索。有时没讲清楚背景就直接展开兼之啰嗦、跳跃和回旋往复这种方式可能更适合写小说让面试官有时摸不着头脑。表述的条理性和清晰性也是很重要的。不妨自己测试一下Dubbo 的架构设计是怎样的? Redis 的持久化机制是怎样的?然后自己回答试试看。
表述能力的基本法则:
- 先总后分,先整体后局部;
- 先说基本思路,然后说优化;
- 体现互动。先综述,然后向面试官询问要听哪方面,再分述。避免自己一脑瓜子倾倒出来,让面试官猝不及防;系统设计的场景题,多问一些要求,比如时间要求、空间要求、要支持多大数据量或并发量、是否要考虑某些情况等。
### 常见问题
面试是通过沟通来理解双方的过程。面试中的问题,千变万化,但有一些问题是需要提前准备好的。
比如“灵魂 N 问”:
- 你为什么从 XXX 离职?
- 你的期望薪资是多少?
- 你有一段空档期,能解释下怎么回事么?
- 你的职业规划是怎样的?
高频技术问题:
- 基础:数据结构与算法、网络;
- 微服务:技术体系、组件、基础设施等;
- DubboDubbo 整体架构、扩展机制、服务暴露、引用、调用、优雅停机等;
- MySQL索引与事务的实现原理、SQL 优化、分库分表;
- Redis : 数据结构、缓存、分布式锁、持久化机制、复制机制;
- 分布式:分布式事务、一致性问题;
- 消息中间件:原理、对比;
- 架构: 架构设计方法、架构经验、设计模式;
- 性能优化: JVM、GC、应用层面的性能优化
- 并发基础ConcurrentHashMap, AQS, CAS线程池等
- 高并发IO 多路复用;缓存问题及方案;
- 稳定性:稳定性的思想及经验;
- 生产问题:工具及排查方法。
### 中高端职位
说起来,我这人可能有点不太自信。我是怀着“踏实做一个工程师”的思想投简历的。
对于大龄程序员,企业的期望更高。我的每一份“高级工程师”投递,自动被转换为“技术专家”或“架构师”。无力反驳,倍感压力。面试中高端职位,需要更多准备:
- 你有带团队经历吗?
- 在你 X 年的工作经历中,有多少时间用于架构设计?
- 架构过程是怎样的?你有哪些架构设计思想或方法论?
如果不作准备,就被一下子问懵,乱了阵脚。实际上,我或许还是存着侥幸心理把“技术专家”和“架构师”岗位当做“高工”来面试的,也就无一不遭遇失败了。显然,我把次序弄反了:应当以“技术专家”和“架构师”的规格来面试高级工程师。
好吧,那就迎难而上吧!我不是惧怕挑战的人。
此外,“技术专家”和“架构师”职位应当至少留一天的时间来准备。已经有丰富经验的技术专家和架构师可以忽略。
### 好的心态
保持好的心态也尤为重要。我经历了“乐观-不自信-重拾信心”的心态变化过程。
很长一段时间,由于“求成心切”,生怕某个技术问题回答不上来搞砸,因此小心谨慎,略显紧张,结果已经梳理好的往往说不清楚或者说得不够有条理。冲着“拿 offer ”的心态去面试,真的很难受,会觉得每场面试都很被动那么难过,甚至有点想要“降格以求”。
有时,我在想:咋就混成这个样子了呢?按理来说,这个时候我应该有能力去追求自己喜爱的事业了啊!还是平时有点松懈了,视野狭窄,积累不够,导致今天的不利处境。
我是一个守时的人,也希望对方尽可能守时。杭州的面试官中,基本是守时的,即使迟到也在心理接受范围内,回武汉面试后,节奏就有点被少量企业带偏了。有一两次,我甚至不确定面试官什么时候进入会议。我想,难道这是人才应该受到的“礼待”吗?我有点被轻微冒犯的感觉了。不过我还是“很有涵养地”表示没事。但我始终觉得:面试官迟到,是对人才的不尊重。进入不尊重人才的公司,我是怀有疑虑的。良禽择木而栖,良臣择主而事。难道我能因为此刻的不利处境,而放弃一些基本的原则底线,而屈从于一份不尊重人才的 offer 吗?
我意识到:一个人应当用其实力去赢得对方的尊重和赏识,以后的合作才会更顺畅。不若,哪怕惜其无缘,亦不可强留。无论别人怎么存疑,心无旁骛地打磨实力,挖掘自己的才干和优势,终会发出自己的光芒。因此,我的心态顿时转变了:应当专注去沟通,与对方充分认识了解,赢得对方心服的认可,而不是拿到一张入门券,成为干活的工具。
有一个“石头和玉”的小故事,把自己当做人才,并努力去提升自己,才能获得“人才的礼遇”;把自己当石头贱卖,放松努力,也就只能得到“石头的礼遇”。尽管一个人不一定马上就具备人才的能力,但在自己的内心里,就应当从人才的视角去观察待入职的企业,而不仅仅是为了找一份“赚更多钱”的工作。
此外,焦虑也是不必要的。焦虑的实质是现实与目标的差距。一个人总可以评估目标的合理性及如何达成目标。如果目标过高,则适当调整目标级别;目标可行,则作出合理的决策,并通过持续的努力和恰当的出击来实现目标。决策、努力和出击能力都是可以持续修炼的。
## 面试历炼
技术人的面试还是更偏重于技术,因此,技术的深度和广度还是要好好准备的。面试官和候选人的处境是不一样的,一个面试官问的只是少量点,但是多个面试官合起来就是一个面。明白这一点,作为面试官的你就不要忘乎所以,以为自己就比候选人厉害。
我面的企业不多,因为我已经打算从事教育事业,用“志趣和驱动力”这项就直接过滤了很多企业的面试邀请。在杭州面试的基本是教育企业,连阿里华为等抛来的橄榄枝都婉拒了(尽管我也不一定能面上)。虽然做法有点“直男”,但投入最多精力于自己期望从事的行业和事业,才是值得的。
我所认为的教育事业,并不局限于现在常谈起的在线教育或 K12 教育,而是一个教育体系,任何可以更好滴起到教育效果的事业,包括而不限于教学、阅读、音乐、设计等。
### 接力棒科技-高工
面的第一家。畅谈一番后,没音讯了。但我也没有太在意。面试官问的比较偏交易业务性的东西,较深的就是如何保证应用的数据一致性了。
此时的我,就像在路上扔了一颗探路的小石子,尚未意识到自己的处境。
### 网易云音乐-高工
接着是网易云音乐。大厂就是大厂。一面问的尽是缓存、分布式锁、Dubbo、ZK MQ 中间件相关的机制。很遗憾,由于我平时关于技术原理的沉淀还是很少,基本是“一问两不知”,挂得很出彩。
此时,我初步意识到自己的技术底子还很薄弱,也就开始了广阔的技术学习和夯实,自底向上地梳理原理和逻辑,系统地进行整理总结,最终初步形成了自己的互联网服务端技术知识体系结构。
### 铭师堂-技术专家
架构师面试的。问的相对多了一些DB, Redis 等。反馈是技术还行,但缺乏管理经验。这是我第一次意识到大龄程序员缺乏管理经验的不利。中小企业的技术专家线招聘中,往往附加了管理经验的需求。应聘时要注意。
缺乏管理经验,该怎么办呢?思考过一段时间后,我的想法是:
- 改变能改变的,不能改变的,学习它。比如技术原理的学习是我能够改变的,但管理经验属于难以一时改变的,那就多了解点管理的基本理论吧。
- 从经历中挖掘相关经验。虽然我没有正式带团队的实际经验,但是有带项目和带工程师,管控某个业务线的基本管理经验。多多挖掘自己的经历。
### 字节教育-高工
字节教育面试,我给自己挖了不少坑往里跳。
比如面试官问,讲一个你比较成就感的项目经历。我选择的是近 4 年前的周期购项目。虽然这是我入职有赞的第一个有代表性的项目,但时间太久,又没有详细记录,很多技术细节遗忘不清晰了。我讲到当时印象比较深的“一体化”设计思想,却忘记了当时为什么会有这种思想(未做仔细记录)。
再比如,一个上课的场景题,我问是用 CS 架构还是 BS 架构?面试官说用 CS 架构吧。这不是给自己挖坑吗?明明自己不熟悉 CS 架构,何必问这个选择呢,不如直接按照 BS 架构来讲解。哎!
字节教育给我的反馈是:业务 Sense 不错,系统设计能力有待提高。我觉得还是比较中肯的。因此,也开始注重系统设计实战方面的文章阅读和思考训练。
经验是:
- 做项目时,要详细记录每个项目的技术栈、技术决策及原因、技术细节,为面试做好铺垫;
- 提前准备好印象最深刻的最代表性的系统和项目,避免选择距离当前时间较久的缺乏详细记录的项目;
- 选择熟悉的项目和架构,至少有好的第一印象,不然给面试官的印象就是你啥都不会。
### 咪咕数媒-架构师
好家伙,一下子 3 位面试官群面。可能我以前经历的太少了吧。似乎国企面试较高端职位,喜欢采取这种形式。兼听则明偏听则暗嘛。问的问题也很广泛,从 ES 的基本原理,到机房的数据迁移。有些技术机制虽然学习过,但不牢固,不清晰,答的也不好。比如 ES 的搜索原理优化,讲过倒排索引后,我对 Term Index 和 Trie 树 讲不清楚。这说明,知道并不代表真正理解了。只有能够清晰有条理地把思路和细节都讲清楚,才算是真正理解了。
印象深刻的是,有一个问题:你有哪些架构思想?这是第一次被问到架构设计方面的东西,我顿时有点慌乱。虽然平时多有思考,也有写过文章,却没有形成系统精炼的方法论,结果就是答的比较凌乱。
### 涂鸦智能-高工
应聘涂鸦智能,是因为我觉得这家企业不错。优秀的企业至少应该多沟通一下,说不准以后有合作机会呢!看问题的思维要开阔一些,不能死守在自己想到的那一个事情上。
涂鸦智能给我的整体观感还是不错的。面试官也很有礼貌有耐心,整体架构、技术和项目都问了很多,问到了我熟悉的地方,答得也还可以。也许我的经验正好是切中他们的需求吧。
若不是当时想做教育的执念特别强,我很大概率会入职涂鸦智能。物联网在我看来应该是很有趣的领域。
### 跟谁学-技术专家
“跟谁学”基本能答上来。不过反馈是:对于提问抓重点的能力有所欠缺,对于技术的归纳整理也不够。我当时还有点不服气,认为自己写了那么多文章,也算是有不少思考,怎能算是总结不够呢?顶多是有技术盲点。技术犹如海洋,谁能没有盲点?
不过现在反观,确实距离自己应该有的程度不够。对技术原理机制和生产问题排查的总结不够,不够清晰细致;对设计实践的经验总结也不够,不够系统扎实。这个事情还要持续深入地去做。
此外,面得越多,越发现自己的表述能力确实有所欠缺。啰嗦、容易就一点展开说个没完、脱离背景直接说方案、跳跃、回旋往复,然后面试官很可能没耐心了。应该遵循“先总后分”、“基本思路-实现-优化”的一些基本逻辑来作答会更好一些。表述能力真的很重要,不可只顾着敲代码。还有每次面教育企业就不免紧张,生怕错过这个机会。
这是第二家直接告诉我年龄与经验不匹配的企业,加深了我对年龄偏大的忧虑,以致于开始有点不自信了。
那么我又是怎么重拾信心的呢?有一句老话:“留得青山在,不怕没柴烧”。就算我年龄比较大,如果我的技术能力打磨得足够硬朗,就不信找不到一家能够认可我的企业。大不了我去做开源项目好了。具备好的技术能力,并不一定就局限在企业的范围内去发挥作用,也没必要局限于那些被年龄偏见所蒙蔽的人的认知里。外界的认可固然重要,内在的可贵性却远胜于外在。
### 亿童文教-架构师
也是采用的 3 人同时面试。主要问的是项目经历,技术方面问得倒不是深入。个人觉得答得还行。面试官也问了架构设计相关的问题,我答得一般。此时,我仍然没有意识到自己在以面“高级工程师”的规格来面试“架构师”岗位。
面试官比较温和HR 也在积极联系和沟通,感觉还不错。只是,我没有主动去问反馈意见,也就没有下文了。
### 新东方-高工
面试新东方,主要是因为切中我做教育的期望,虽然职位需求是做信息管理系统,距离我理想中的业务还有一定距离。经过沟通了解,他们更需要的是对运维方面更熟悉的工程师,不过我正好对运维方面不太熟悉,平时关注不多,因此不太符合他们的真实招聘要求。面试官也是很温和的人,老家在宜昌,是我本科上大学的地方,面试体验不错。
以后要花些时间学习一些运维相关的东西。作为一名优秀的工程师和合格的架构师是要广泛学习和熟悉系统所采用的各种组件、中间件、运维部署等的。要有综观能力不过我醒悟的可能有点迟。Better later than never.
### ZOOM-高工
ZOOM 的一位面试官或许是我见过的所有面试官中最差劲的。共有两位面试官,一位显得很有耐心,另一位则挺着胖胖的肚子,还打着哈欠,一副不怎么关心面试和候选人的样子。我心想,你要不想面,为啥还要来面呢?你以为候选人就低你一等么?换个位置我可以暴打你。不过我还是很有礼貌的,当做什么事也没发生。公司在挑人,候选人也在挑选公司。
想想ZOOM 还是疫情期间我们公司用过的远程通信会议软件。印象还不错,有这样的工程师和面试官藏于其中,我也是服了。难倒他是传说中的大大神?据我所知,国外对国内的互联网软件技术设施基本呈碾压态势,中国大部分企业所用的框架、中间件、基础设施等基本是拿国外的来用或者做定制化,真正有自研的很少,有什么好自满的呢?
### 阿优文化-高工
阿优文化有四轮技术面。其中第一个技术面给我印象比较深刻。看上去,面试官对操作系统的原理机制特别擅长和熟悉。很多问题我都没答上来。本以为挂了,不过又给了扳回一局的机会。第二位面试问的项目经历和技术问题是我很熟悉的。第三位面试官问的比较广泛,有答的上来的,有答不上来的。不过面试官很耐心。第四位是技术总监,也问得很广泛细致。
整体来说,面试氛围还是很宽松的。不过,阿优当时的招聘需求并不强烈,估计是希望后续有机会时再联系我。可惜我那时准备回武汉了。主要是考虑父母年事已高,希望能多陪陪父母。
想想,我想问题做决策还是过于简单的,不会做很复杂的计算和权衡。
### 小米-专家/架构
应聘小米,主要是因为职位与之前在有赞做的很相似,都是做交易中台相关。浏览小米官网之后,觉得他们做的事情很棒,可是与我想做教育文化事业的初衷不太贴合。
加入小米的意愿不太强烈,面试也就失去了大半动力。我这个性子还是要改一改。
### 视觉中国-高工
围绕技术、项目和经历来问。总体来说,技术深度并不是太难,项目方面也涉及到了。人力面前辈很温和,我以为会针对自己的经历进行一番“轰炸”,结果是为前辈讲了讲有赞的产品服务和生意模式,然后略略带了下自己的一些经历。
### 科大讯飞-架构师
一二面,感觉面试官对安排的面试不太感兴趣。架构师,至少是一个对技术和设计能力非常高要求的职位。一面的技术和架构都问了些,二面总围绕我的背景和非技术相关的东西问,似乎对我的外在更关注,而对我自身的技术和设计能力不感兴趣。交流偏浅。
能力固然有高下之分,但尊重人才的基本礼节却是不变的。尊重人才,是指聚焦人才的能力和才学,而不是一些与才学不甚相关的东西。
### 青藤云-高工
青藤云的技术面试风格是温和的。感受到坦率交流的味道,被认可的感觉。感受到 HR 求才若渴的心情。和我之前认为的“应当用其实力去赢得对方的尊重和赏识”不谋而合。
### 腾讯会议-高工
和腾讯面试官是用腾讯会议软件面试腾讯会议的职位。哈哈。由于网络不太稳定,面试过程充满了磕磕碰碰,一句话没说完整就听不清楚了。可想情况如何。但是我们都很有很有很有耐心,最终一起完成了一面。面试是双方智慧与力量的较量,更是双方一起去完成一件事情、发现彼此的合作。这样想来,传统的“单方考验筛选式”的面试观念需要革新。
由于我已经拿到 offer , 且腾讯会议的事情并不太贴合自己的初衷,因此,我与腾讯方面沟通,停止了二面。
### 最终选择
当拿到多个 offer 时,如何选择呢?我个人主要看重:
1. 志趣与驱动力;
2. 薪资待遇;
3. 公司发展前景和个人发展空间;
4. 工作氛围;
5. 小而有战斗力的企业。
在视觉中国与青藤云之间如何选择?作个对比:
- 薪资待遇:两者的薪资待遇不相上下,也都是认可我的;视觉中国给出的是 Leader 的职位,而青藤云给出的是核心业务的承诺;
- 工作氛围:青藤云应该更偏工程师文化氛围,而视觉中国更偏业务化;
- 挑战性:青藤云的技术挑战更强,而视觉中国的业务挑战性更强;
- 志趣与驱动力:视觉中国更符合我想做文化的事情,而青藤云安全并不贴合我想做教育文化事业的初衷,而且比较偏技术和底层(我更希望做一些人文性的事情)。但青藤云做的是关于安全的事情,安全是一件很有价值很有意义的事情。而且,以后安全也可以服务于教育行业。有点曲线救国的味道。尤其是创始人张福的理想主义信念“让安全之光照亮互联网的每个角落”及自己的身体力行,让人更有一些触动。最终,我觉得做安全比做图片版权保护稍胜出一小筹。
此外,我觉得做教育,更适合自己的是编程教育,或者是工程师教育。我还想成为一名系统设计师。还需要积累更多生产实践经验。可以多与初中级工程师打交道,在企业内部做培训指导。或者工作之余录制视频,上传到 B 站,服务广大吃瓜群众。将来,我或许还会写一本关于编程设计的书,汇聚毕生所学。
因此,经过一天慎重的考虑,我决定,加入青藤云安全。当然,做这个选择的同时,也意味着我选择了一个更大的挑战:在安全方面我基本一穷二白,需要学习很多很多的知识和经验,对于我这个大龄程序员来说,是一项不小的挑战。
## 小结
很多事情都有解决的方法,即使“头疼的”大龄程序员找工作也不例外。确立明确清晰的目标、制定科学合理的决策、持续的努力、掌握基本面、恰当的出击,终能斩获胜利的果实。但要强调一下:功夫在平时。平时要是不累积好,面试的时候就要花更多时间去学习,会受挫、磕磕碰碰、过得也不太舒坦。还是平摊到平时比较好。此外,平时视野也要保持开阔,切忌在面试的时候才“幡然醒悟”。
一个重要经验是,要善于从失败中学习。正是在杭州四个月空档期的持续学习、思考、积累和提炼,以及面试失败的反思、不断调整对策、完善准备、改善原有的短板,采取更为合理的方式,才在回武汉的短短两个周内拿到比较满意的 offer 。
此外,值得提及的是,对于技术人员,写博客是一件很有价值的事情。面试通过沟通去了解对方,有其局限性所在。面试未能筛选出符合的人才其实是有比较大概率的:
1. 面试的时间很短,即使是很有经验的面试官,也会看走眼(根本局限性);
2. 面试官问到的正好是自己不会的(运气问题);
3. 面试官情绪不好,没兴趣(运气问题);
4. 面试官自身的水平。
因此,具备真才实学而被 PASS 掉,并不值得伤心。写博客的意义在于,有更多展示自己思考和平时工作的维度。
尊重人才的企业,一定是希望从多方面去认识候选人(在优点和缺点之间选择确认是否符合期望),包括博客;不尊重人才的企业,则会倾向于用偷懒的方法,对候选人真实的本领不在意,用一些外在的标准去快速过滤,固然高效,最终对人才的识别能力并不会有多大进步。
经过这一段面试的历炼,我觉得现在相比离职时的自己,又有了不少进步的。不说脱胎换骨,至少也是蜕了一层皮吧。差距,差距还是有的。起码面试那些知名大厂企业的技术专家和架构师还有差距。这与我平时工作的挑战性、认知视野的局限性及总结不足有关。下一次,我希望积蓄足够实力做到更好,和内心热爱的有价值有意义的事情再近一些些。
面试,其实也是一段工作经历。

View File

@ -0,0 +1,5 @@
# Java 技术文章精选集
在这里我会精选一些和 Java 相关的优质技术文章,每一篇都值得你阅读 3 遍以上!