面了一些运维,发现3个共同点

简介: 面了一些运维,发现3个共同点

最近因为一些原因,需要招一个运维人员,所以就筛选了很多简历,也面了很多人,我发现大家都有一些相同的问题。

主要表现在以下几个方面:

  1. 简历重点不明确
  2. 会的多,但不精
  3. 个人规划不清晰

下面从这三个方面说说自己的看法。

简历重点不明确

简历是非常重要的,简历是非常重要的,简历是非常重要的。

简历是一个人的敲门砖,能不能获得面试的机会就看你的简历是否满足需求。

我和你素未谋面,我对你知之甚少,我要怎么了解你呢?只有你的简历。

但是,不知道是做IT的通病,还是做运维的独享,我发现大部分人的简历都是流水席,比如

  • 负责某某虚拟化的维护,如ESXI、PVE等
  • 负责某某中间件的维护,如Redis、MySQL等
  • 负责某某自动化,如Ansible、Jenkins等

不知道大家看到这样的简历的时候,脑海里会出现什么情景。

就我来说,我并不知道应聘者做了什么,收获了什么。

这一个个熟悉的技术,我无法基于应聘者的视角将它们有效地串联起来。

作为应聘者,首先应该直接了当的告诉面试官我会什么,也就是我的优势是什么,这可以是一个轮廓(最好切合所应聘的公司要求),比如:

  • 有5年的虚拟化维护经验,完成3家公司10个平台500个应用的虚拟化,主导某某虚拟化平台的设计与实施等
  • 有4年的开源经验,参与某某系统的开源,主要负责什么,产品的现阶段如何等
  • 有2年的管理经验,管理了多少人,管理期间团队的成长是什么,比如获得公司某某奖励等

一般在简历的首页把自己的优势展示出来,不仅能吸引面试官的注意,也让面试官对你产生比较好的印象。

然后就写每个公司的工作经历,这个阶段不要再记流水线了,要写具体做了什么,为团队带来了什么,为公司带来了什么,也就是真正的价值输出,比如:

  • 比如负责某某平台的架构选型、设计,使用了哪些具体的技术,搭建了什么平台,带来了多少收益。
  • 比如负责某某团队管理工作,管理了多少人,创造了多少团队价值,在企业中的作用。

有目标,有过程,有收获。

不仅能看出你的专业能力,也能很好地体现逻辑做事的能力。

另外再挑选几个具备挑战并且收益明显的项目做详细的描述,让面试官对你的细节做深度的了解。

对此,我总结为如下(根据一个大佬朋友的简历):

从下往上循序渐进,为自己争取面试的机会。

会的多,但不精

不知道大家是不是有相同的感受,感觉自己会很多东西,但是在面试的时候却无法完整的将其说明白。

随着面试者的不断提问,也会让自己不断地自我怀疑。这是我接触过的技术吗?确定这是我以前用的技术?

随着我自己不断地参加面试,我这种感受非常强烈。

只专注于知识的广度,而不在意知识的深度。

这会让人出现幻觉:我什么都会,我下一份工作肯定能拿更高的Offer,能得到更好的平台。

但是,在真正面试的时候,当面试官对你的技术不断加深提问的时候,你会迟疑、会懵逼、会紧张。

这不仅会影响自己的整体面试思路,也会影响面试官对你的评价。

那应该如何做呢?

在大公司里,运维这个角色一般会很细化,比如专注数据库的DBA,专注网络的网工,专注K8s的YAML工程师等,在这种细分领域很明显的公司里,专业路线比较明显,也很容易找准方向。

但是,在大部分的中小企业中,运维团队不大,有时候甚至就一个人,这就要求这个人会的多。再加上这类企业大部分都专注于业务,对某个技术的使用不在于有多深、多精,而在于能用即可。这就会导致运维人员不知道或者无法深度的研究某个技术,怎么办呢?

我的理解是结合自身和行业的情况,择优处理:

  • 回顾自己的技术栈,将最优的1-2个技术学透
  • 结合自身的发展规划,将需要用到的技术学明白
  • 根据目前行业的现状,将最火的技术学到家

感觉自己说了一堆废话.....

个人规划不清晰

接上了第二个观点了......

最近面试的人里面,有一部分是属于工作10年以上的人。

面试官对这些人其实是有一定的期待的,毕竟在这个行业摸爬滚打10余载,肯定会有自己的理解,也有自己独到的能力。

但是,通过面试下来,发现有清晰的规划,有独特的能力的人少之又少,大部分人都仅仅是在被动地工作。

被动的工作会产生一个很可怕的问题,那就是独立思考能力下降。

当一个人不经常刻意训练自己独立思考的能力,会让大脑这部分能力逐渐边缘化,让你一直处于“夺一哈,跳一哈”的阶段,不仅不利于个人提升,也不利于职业发展。

归根到底,就是不知道自己要什么。

当一个人知道自己要什么的时候,就会想方设法的向这个方面前进,你的目标越明确,规划也就越清晰。

不过,大部分人都是在漫长的摸索中才找到自己的方向。但是,这有什么问题呢?找到了方向就行。

最后

上面都是个人的观点,如有不良反应,请点赞关注。

就我而言,我也是上面3点中的一份子。

有的同学可能会说:那你为啥在这里大放厥词?

这就是我和别人不同的地方,我喜欢总结,也喜欢根据这些总结来尝试改变,也许结果会不尽人意,但是我很享受这个过程。

同时,我也希望和我有相同处境或者感受的人能从中得到一点启发,比如好好优化优化简历,让自己获得更多的面试机会。比如好好钻研一下个别技术,让自己在这方面吊打面试官。

不论是哪一种,都要让自己保持向上生长的趋势。

时代会淘汰一部分人,不要包括你。

相关文章
|
4月前
|
Kubernetes 监控 测试技术
运维.云技术学习.基于应用服务网格的灰度发布(上:理论基础篇)
运维.云技术学习.基于应用服务网格的灰度发布(上:理论基础篇)
80 0
|
5月前
业务系统架构实践问题之实现平台集中复用和业务自主灵动的方式问题如何解决
业务系统架构实践问题之实现平台集中复用和业务自主灵动的方式问题如何解决
|
存储 SQL 关系型数据库
微服务篇:通过查询实施数据解放
基于查询的数据解放涉及查询数据存储并将所选择的结果发布到相关的事件流中。一个使用合适的 API、SQL 或类 SQL 语言的客户端会被用于向数据存储请求特定的数据集。必须能够批量查询数据集以提供事件的历史记录,然后定期更新,以确保数据的更改被发布到输出事件流中。
|
缓存 运维 固态存储
浅聊微服务化的时机问题(业务/技术、组织)
微服务架构发展到现在,其技术栈已经非常成熟,而且门槛越来越低,大家的接受度越来越高,掌握微服务开发,已经成了新生代工程师们的标配技能。但同时我们也要看到,很多公司在实施微服务时,仍然会出现各式各样的问题...
1145 0
浅聊微服务化的时机问题(业务/技术、组织)
|
供应链 监控 数据可视化
泛微BPM从点、线、面三层出发优化流程管理,提高组织运营效率
泛微BPM以“点、线、面”结合的方式,进一步优化流程管理体系,推动组织制度落地,规范业务管理过程,提升组织管控力…
|
数据采集 云安全 监控
云时代重新定义主机安全:自动化安全闭环是核心
随着越来越多的企业和机构正在逐步上云,主机安全是企业上云首先需要考虑的问题。在当前安全事件频发,且企业还没有具备专业安全运营能力的现状下,只具备检测或防御等单一功能的传统主机安全产品已不再适应这样的场景和需求,产品具备检测、防御为一体的安全闭环能力将成为刚需。
2260 0