var slideIndex = 1; showSlides(slideIndex); function plusSlides(n) { showSlides(slideIndex += n); } function currentSlide(n) { showSlides(slideIndex = n); } function showSlides(n) { var i; var slides = document.getElementsByClassName("mySlides"); var dots = document.getElementsByClassName("dot"); if (n > slides.length) {slideIndex = 1} if (n < 1) {slideIndex = slides.length} for (i = 0; i < slides.length; i++) { slides[i].style.display = "none"; } for (i = 0; i < dots.length; i++) { dots[i].className = dots[i].className.replace(" active", ""); } slides[slideIndex-1].style.display = "block"; dots[slideIndex-1].className += " active"; }

面试应该做的事

● 问已经发生的事情
比如面试移动开发者,面试官应该认真看下其做过的 App,具体的工作是什么,
准备一些相关的问题,这里就可以看出来之前工作中的积累是什么,有多深。

● 问题解决思路
针对项目经验和一些学习的经验上面,应该问拿到问题以后解决思路是什么,在
什么场景下为什么这么做,这里根据面试者的方案,分析的方法论,就可以大致了解
面试者是否聪明,知识面是不是够广,遇到问题时会不会举一反三。
具体可以举个简单的例子,很多同学说自己做过架构,然后都会讲自己做了一个
解耦和分层的框架,其实这类框架 iOS 很多,外部 github 上就有各种方案。在阿里
内部手淘早先做的 bundle 拆分时沉淀的容器规则,天猫开源出去的 beeHive,闲鱼
内部的 Xframework,抑或是服务端的 spring mvc,其实都实现了 IoC,但实现和
思路上都有一些差异,到底为什么这么做,其实是有区别的,这里面就可以看出知识
广度,总结和思辩能力,在关键路径上的技术判断。
又比如说,我们总在强调性能稳定性怎么做,业界也有很多方案,到底哪个方案
更好呢?答案没有绝对的对错,取决于某个时间点和场景下哪个问题是最核心的突破
点,而你的选择标准和落地的技术方案是不是合理(考虑成本,收益,以及后续的风
险是什么)。一般来讲,我们更倾向于用系统化的思维看待一个问题,也就是说,相
比根据人的经验去识别性能瓶颈,我们更希望能通过自动化,智能化,数据化的方式
去解决问题。

● 少问多听
一般刚开始做面试官的同学很喜欢以问为主,但因为大家的知识体系不太一样,
成长环境也不同,直接这么问起来很难就找到面试者的优点,所以尽量让应试者自己
陈述,然后以学习和交流的心态针对陈述中存疑的地方再进行发问,会更容易让应试
者放松,也更容易让应试者更全面的表达自己。另外,问的差不多的时候,结尾的
时候可以补充一句:您觉得刚才的面试中还有哪些我没问到的,您想再补充一下的内
容?末了,再问下:我的问题问完了,您有什么想要问我的吗?

===
STAR 原则
● 处境 (situation)
在什么样的环境下
● 任务 (task)
接到了什么样的任务
● 行动 (action)
然后具体怎么落地的
● 结果 (result)
拿到了什么结果
我们尽量问清楚对方在什么样的环境下接到这个任务,接到以后是做了什么事
情,最后的结果是什么样子的。乍一听,感觉,这不是套路嘛,是不是知道这个原则
的人,只要按照这四点编故事,就能通过面试了?当然不是,在叙述过程中,我们应
该分辨出 STAR 中的真假,那下面就举一些例子。

posted @ 2018-07-26 18:12  Solomon_xm  阅读(254)  评论(0编辑  收藏  举报