许多人想转行,但却不知道如何准备面试时,应该怎么做?作者分享了自己从开发转产品的面试过程,希望能给你一些帮助,在这个求职季找到一些方向。
(资料图片)
离职的时候,公司领导问我接下来是否是继续从事 iOS 行业,我略带羞涩地回答“接下来估计会找产品经理项目经理这样的职位,去从事工作中包含更多与人沟通内容的职业”。领导点点头,还给了我一些不错的建议。
近两年,在业界周知的是移动端 iOS、Android 的开发每况愈下,这不单单是因为跨平台的开发越来越出色,更主要的原因是在于移动端的开发相对简单,不需要程序员动很多的脑子,只要搭建漂亮的界面,而所需的控件大部分都已经被官方写好了。
在与老同事依依惜别之后,我终于来到了上海,投简历的时候依然是“iOS 开发工程师”,原因很简单,虽然我以前做过产品经理的活,但我主要还是个 iOS 开发,而直接去投产品经理的岗位估计会无人问津。
但事实是,我在51、智联、猎聘上投了几家招聘 iOS 的公司,几天过去——无人问津。
离职之前,我设想的是:第二家公司要么去大厂,可以学习到先进的技术和团队管理经验;要么去小的公司,可以担任更多的职责,从而磨炼自己的能力。我个人更倾向于后者。 从长远来看,一直当个程序员写代码不是长久之计,哪怕三年五载之后自己变成行业的大神,可那个时候的iOS行业估计不会比现在好。
几天过去,我的简历除了被几个提供海外东南亚国家工作的猎头看上,其他公司的人事基本上都是看过之后就直接放进人才库。我因此非常焦虑,想着自己就要在上海当一个无业游民,整日无所事事了。无所事事令我焦虑,焦虑令我无法静下心来学点东西,无所学便无所进步,接着有一种人生开始变得灰暗了的感觉。
后来我改变了策略,调整了简历内容,主要是让HR可以看到简历上的关键字与他们的招聘对应,接着一口气投了50家公司,没想到这下效果立竿见影,当天就收到面试邀请,隔天又收到两家面试邀请。
我逐一去查了邀请面试的公司,都是初创公司和外包公司,看过他们的产品也差强人意,于是简单地温习了一下面试题后便面试去了。
2019年4月4日,星期五。
今天有两场面试。接下来是清明3天小长假,公司都放假了,自然也就不会有面试了。前一家面试公司的聘用电话已经打来了,我暂时压下了,说想考虑一段时间,主要也是想对比各个公司的情况。 今天第一场面试非常顺利,第二场是临时安排的,在赶去的路上简单 Google 了下这家公司,也是家外包公司,做金融产品的,这样的公司在上海估计一抓一大把,因此心里想跟前面的公司区别不大。
可实际的情况是——区别很大!!!
面试我的是一个看起来完全不太像程序员的程序小哥,浓密的头发,娃娃脸,个子不算高,看起来很干练的样子,眼神犀利却无凶气。
首先是自我介绍,我说了一下大学以来的经历,对我来说很轻松。
然后问我以前做的产品中用到了哪些技术,这个倒有点令我不知从何开始了,因为我觉得自己写过的代码都挺简单的,要是说一些控件和第三方是不是显得很 low?于是我说了推送的集成,其中运用了通知和消息两种方式(我的回答:通知可以在前台与后台都收到,但是得走苹果的APNS,处理起来相对麻烦;而消息只能在前台收到,是通过 App 内的长链接实现的,集成简单;而在我的产品中把两者都实现了,且可以根据场景互相切换)。但我万万没想到接下来开始了我非常尴尬的“表演”,而此时的我还不知道坐在我面前的是一个8年开发经验的大神。
当我把回答中的消息说完时,小哥马上问道:那么消息是怎么实现的呢?
这时我吃了一惊,一般 iOS 面试说到推送不都是讲苹果APNS那套流程吗?而消息是不走APNS的,可我只知道它是应用内长链接啊。为了避免完全答不上来,我谨慎地问了下:你指的是消息实现原理吗?小哥点点头:嗯,就是消息具体是怎么实现的。这时我确定自己回答不了该问题了,便坦诚地说自己只是经常使用消息,但是对其的实现方式没有深入的了解过。
小哥说好的,补充说:消息需要长链接,长链接是怎么实现的呢,使用的是socket、TCP还是TDP,问的就是这个了。接着再问我:谈谈你对多线程的了解。我回答多线程有3种实现方式NSThread、OperationQueue、GCD,个人平时开发主要用GCD,这个比较底层,功能也更强大。于是小哥问我GCD有哪些具体方法和我实际的应用,这个我回答得不错。然后小哥再分别问了NSThread和OperationQueue,我说只是知道这些,但是实际没有应用过,也就无法回答了。
小哥点点头,了解了,谈谈你对Runloop的理解吧。
由于刚刚的回答不好,我开始有点紧张,竟然把Runloop听成了Runtime,于是开始说起了Runtime,小哥喊停,提醒我是Runloop,然后我就懵逼了,准备面试的时候我重点复习了Runtime,而Runloop给忘了,自己支支吾吾了几句,我再次说道抱歉,表示自己可能开发中用过Runloop,但是一点印象都没有了。
小哥说好的,很有耐心,也没露出丝毫鄙视的神情。接着让我说说Runtime,我先说了Runtime的消息机制,小哥让我解释Runtime的消息转发的两个参数并详细说说其中的SEL,SEL我只知道它对应的是方法;然后我说了Runtime的应用,说到给分类实现添加属性的时候,小哥问我具体如何实现,这里我只有印象,但具体实现和其方法没记。
小哥还问了KVO,想必大家都觉得KVO嘛,一种不同类之间的通讯方式,观察对象的属性,适合一对多的情况下使用。但小哥完全不落俗套,问的是如何实现一个KVO。我又懵逼了,他考得全都是很底层的问题啊!或者说,他的这些问题,我根本就没准备到位!
当我又打算再一次说抱歉的时候,小哥却鼓励我继续回答,让我再想想,其实我想到了重写 set 方法,我当时没想通的是:虽然在 set 方法里可以知道属性被修改了,但该用什么方式如何告诉外界呢?总不能用 delegate 或notification 吧?接着小哥还跟我稍微讨论了一下这个问题:重写 set 方法的思路是对的,接着使用回调就可以告诉外界了。
技术的面试大概进行了25分钟,我答得不好,但小哥始终敬而无失,也让我在内心感谢和敬佩他的职业素养。
面试后半部分就聊得比较轻松了,这时我才知道小哥已经做程序员8年了——真是“其貌不扬”,他各种语言都会写,平时主要写的是 iOS,如果按照 iOS 编年史去算的话,小哥在2011年(当时的系统是 iOS 4,iPhone 4才上市一年)就已经开始从事 iOS 开发,可以算得上国内 iOS 开发的大佬了吧。而他是前飞信团队的。
当我放松下来之后,脑子转得也快多了。这么一个活大佬坐在我面前,为何不跟他聊聊对我职业生涯有利的话题呢?我问小哥:你从事 iOS 开发这么久,现在对 iOS 的看法是怎样的呢?小哥很实在的回答我说:其实我目前也不怎么看好 iOS,但是不能只会 iOS,像React Native、Flutter都要了解的……
从这家面试公司走出来的时候,我感觉兴奋极了。这就是我想要的面试,真的暴露我自己不足的面试,可以和厉害的人直接对话,还能为自己指明方向。
我脑海中开始浮现我在这家公司上班努力的样子:公司福利到位,周末双休,没有牺牲身体健康的加班,有牛逼的技术团队,不出1年我的专业功力必然大涨,三年五载后,我也会成为这位小哥一样对自己专业非常自信的程序员。不论是公司待遇,还是对我的 iOS 技术提升,这家公司就是我找 iOS 开发的理想单位。
然而,当我见识了自己心中理想的单位,并设想自己进入其中工作和未来几年前景时,我心中豁然开朗:
这很好,但这并不是我想要的。
于是,我接受了一家规模较小的公司提供的产品经理的职位。
补充:今天我接到了小哥公司的录用电话,人事说如果谈得拢就可以安排上岗时间了。真没想到啊!我内心非常感谢小哥的面试,也非常感谢贵公司对我的认可。
——2019.04.09
现在回想当时毅然决然的做出转行决定,大概包括了4个原因:
做过程序员之后会明白一个道理:技术永远只是手段,不是目的。那些看起来很酷的软件并不是程序员创造出来的,而是“产品经理”想出来的,再由程序员写出来。我写过前端的iOS、小程序、H5,后端的Java,还自己搭建网站服务器,最后发现这些东西自己玩玩可以,但是没有价值。在互联网红利时代,许多技术出身的大佬创造了财富神话,成就他们的不是技术,而是他们具备的产品思维。研发的天花板是CTO,产品经理的天花板是CEO。
我想要做创造性的工作,我想要有决策权,我热衷于用互联网系统帮他人解决问题。我在写代码的时候经常会想一个问题:我写的这些代码到底值不值公司发我的工资?后来知道公司将我写的软件拿出去卖了好多钱,确实是值得的。只是为什么做这个软件?为谁做?调动多少资源来做?开发这个软件的范围、规划、风险评估我都不涉及,我主要是写出一行行高质量的代码——这似乎没有产生太多价值——程序员的岗位无法满足我的求知探索欲。
因为做iPhone软件开发,我拜读了《乔布斯传》,了解了这位传奇产品经理的一生。
作为研发的时候,因为觉得原系统界面太丑,便和UI一起设计产品交互;因为爱跟人打交道,能从各个业务部门收集到他们对公司现有产品的客观评价;因为想了解公司系统是怎么收集数据的,技术总监就派我去客户现场观察用户如何使用我们的产品;因为没有标准需求文档老是与业务沟通摩擦,我试着从0到1写需求文档……
还有这次找工作时,上文技术小哥的醍醐灌顶。
仿佛都在告诉我:你应该去做产品经理。
大学毕业时从事 iOS 开发主要是为了不错的收入,并没有想过自己喜不喜欢,也没有能力去判断自己喜不喜欢,那时候的我阅历太浅了,对人生也没有清晰的规划。步入社会后,发现好多事情在大学的时候就应该搞清楚的。我很感谢研发的这段经历,否则可能也不会了解产品经理。既然现在有一个更好的选择,我很庆幸在职业生涯第3年就可以转岗。
本文由 @吴德馨 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。