Android模块化面向接口编程,算法太TM重要了

没有稳定的工作,只有稳定的能力。

又到了万物复苏的季节,在程序猿这个行当里,作为 Android 开发出生的,在经历了八年的脱发生涯后,有了越来越多的想法和感触

趋势

随着各类移动跨平台的兴起,在 ReactNative 、Flutter 、Weex 等框架的加持下,Android 开发的能力已不再局限于 Android 领域,而各大厂商近些年也针对跨平台的不足进行逐步完善:

  • ReactNaitve 底层重构的新架构 Fabric,将管理器等往 C++ 迁移实现同步操作和性能优化;
  • Flutter 1.2 正式版发布,稳步推进稳定性的同时,考虑向着更多平台拓展。
  • UCloud 的 uni-app 、滴滴的 Chameleon 通过各自的标准,希望把APP、前端和小程序一并纳入后宫。

但这并不意味着原生开发的“没落”!无论哪种跨平台的加持,最终都离不开你的原生系统能力。大潮过去后更多是淘汰“裸泳”,而如今的市场愈发趋向大前端,竞争之下我觉得移动开发的边界可以更广
Android模块化面向接口编程,算法太TM重要了

我以为是HR一面,结果是技术,没想到啊,没想到!

  • 1、描述Activity的生命周期。

  • 2、描述一个Activity启动另外一个Activity的生命周期

  • 3、Activity标签可以配置什么

  • 4、IntentFilter里面的标签可以干嘛

  • 5、Service怎么启动

了解IntentService吗?

  • 6、几大控件有

  • 7、存储数据的方式有

  • 8、Intent可以干嘛

  • 9、Sharedpreference里面的apply和commit有什么区别

  • 10、ContentProvider用过吗?为什么要用这个

  • 11、ASyncTask用过吗?知道是怎么实现的吗?

  • 12、线程池知道吗?怎么创建?底层怎么实现?

  • 13、Set、List、Map区别,Map底层怎么实现的

  • 14、重写View怎么重写?

  • 15、快排实现

  • 16、实现两个链表表示的整数相加(空间复杂度要求很低)
    Android模块化面向接口编程,算法太TM重要了

看到还有很多程序员连面试流程都没有彻底弄清楚,今天,我们以阿里为例,来聊聊互联网大厂的面试流程和过程!

本篇主要还是聊聊社招的面试过程!阿里以及其他的互联网大厂的技术类社招面试,通常情况是 4 个轮次。第一、第二面是技术面,第三面是主管面试,第四面是 HR 面试。对于目标级别在 P6+ 的候选人,我们会增加至少一轮的跨团队 Review 面试,因为涉及招聘委员会(Hire Committee)的定级流程,所以要复杂一些。接下来的内容,主要针对通常情况下 P5~P6 的面试来介绍,大神请直接忽略。

01 技术面

1. 个人介绍和基础知识考查

这部分算是必备技能。我个人倒是倾向于弱化基础知识的考查,毕竟每个候选人的背景不同,应该更看重聪明程度、学习能力、沟通理解力等,基础知识只能证明他不是一个优秀的工程师,却无法证明他是一个优秀的工程师。
2. 项目经历考查

从这个阶段开始就格外重要了,因为面试官之前并不一定完整浏览候选人的简历,所以聆听候选人对项目的介绍是了解候选人的最主要途径。在这个过程中,面试官试图刨根问底,这跟各公司内部的技术评审很相似。几个关键点,希望你格外注意:

  1. 对项目背景的了解程度,讲不清楚需求从哪里来是非常可怕的,这说明你更多只是一个执行者,不是负责人,且缺少对于项目整体的思考。
  2. 对需求的合理性进行分析,一味听从 PM,不能把控需求的研发是很可怕的。
  3. 对技术方案设计的调研和选型,我们更希望看到你的方案是经过充分思考、调研、对比、论证的,通过这个过程,可以看到候选人的系统设计功底,是否对业界技术有足够了解,对开源技术的掌握情况,是否愿意应用开源技术。哪怕你的项目只是一个简单的业务系统,那么仍然应该有很多亮点可寻,否则这段项目经历可能会减分。
  4. 取得的成效。很多工程师只看重过程,不看重结果,这是不可取的。

3. 编程技术考查
在我的团队中,我要求每一轮技术面,都至少要有 1 道编程题目。一方面,我们非常看重侯选人的代码风格、优雅程度,还有对边界条件的考虑,这些都是好的程序员必须具备的素质。对于代码混乱、边界考虑不清的人,我们会认为他没有足够的编程素养和追求,在逻辑思维层面,也有所欠缺。**这样的候选人进入团队,短期可能造成 Bug 多、项目质量差等影响,长远来看,不利于合作开发、项目传承等。**另一方面,**我们非常看重数据结构、算法等的高效实现。能够快速设计出高效的程序,这体现了候选人日常的深厚积累,还有对编程的极致追求。**前不久就有一个典型案例,我们的运维同学发现一个后端模块上线后处理性能只有几十 QPS,很不理解为什么性能这么差。直到我们重新 review 代码后,才发现是个“经典”问题,即 for 循环里调用 sort(虽然是隔了几次函数调用),简单优化后,性能就可以提升 1~2 个数量级。优秀的工程师,一定会尽可能规避这类问题,几行代码的优化,就能提升用户体验、降低服务器成本、方便代码维护、减少兄弟们的工作量。
4. 逻辑题目或数学题目

这类题目的核心不在于它有多复杂,需要多少经验背景,而在于,只要逻辑清晰,认真思考,大多能得出结果,虽然不一定是最优解。我举几个例子:

  1. 一个六位数字,逆时针旋转 180 度后与之前完全相等的概率是多少?
  2. 边数是 3*4 的网格,从左下角的 A 点走到右上角的 B 点,一共有多少种不同的走法?

这类题目其实很简单,可以用编程的思路解决,比如递归(当然还有很多其他方式),也可以用概率论、组合数学的方式解决,甚至一个一个“数”也是能得到答案的。在思考问题的过程中,可以看出候选人的思维习惯,也可以看出候选人的逻辑能力。另外,这类题目其实有很多变化,如果候选人很轻松完成了回答,面试官就可以适当加大难度,比如 3*4 的网格有一个点不能经过,那么会是什么结果?这类题目看似简单,实则分辨率很高,可以充分挖掘候选人的潜力。除去上面的介绍外,候选人还应该对行业情况有所理解,包括竞品、开源项目等,这可以体现一个人的眼界和行业洞察能力,也可以看出一个人的学习态度,他是否在持续更新自己的知识储备。

02  主管面

相对于技术面而言,主管面试不会过多考查基础知识、数据结构及算法,但因为技术主管大多具备很强的技术背景,所以仍然会针对技术面过程中的一些遗漏点(可能是面试官没有考查到,也可能是候选人的回答不够完善),着重补充考查。除此之外,主管面的核心就是判断候选人除了技术能力外的其他维度,是否与团队相匹配。第一类维度,软素质能力。软素质的维度很丰富,每一次面试过程不会面面俱到地考查,但一些重要的维度一定会被照顾到。

1. 逻辑思维。
与技术面的逻辑题目类似,团队可以接受不足够聪明的人,但无法接受逻辑不清晰的人。在这个环节,可以提出一些进阶的题目,比如给候选人一个很复杂的问题,希望候选人可以尝试分析、分解,让看起来一团乱麻的问题变得清晰可实现。或者,让候选人阐述一个经历过最有挑战的问题,是如何定义问题并分析解决的。当然这类问题,一般初入职场的同学都很难回答完美;不过对于工作 2 年 + 的同学,我觉得问题的分析、分解、设定目标、规划、执行都是必备素质。这个能力很难在工作中迅速培养,它更多是通过候选人过去一二十年的学习和工作经历,一点一滴积累的,所以对于社招而言,希望候选人已经具备很好的逻辑思维能力。
2. 沟通能力。
不能有效且高效地沟通,对于团队项目是场灾难。在日常工作中,经常会看到几个同学针对一个问题争论得不可开胶,但其实他们往往没有理解对方所讲的主旨是什么,甚至对于一些名词和概念的理解都不一致,就更不要说同理心了,这种无效沟通是导致会议冗长的最主要因素。这类的面试考查,一般会依附于项目介绍或者设计题目等。

如果候选人已经具备不错的沟通能力,我们一般还会考查进阶能力:说服和影响。这是成为技术 / 项目负责人的必备能力。面试官可能会和候选人进行一个简短的虚拟沟通或辩论环节,希望候选人可以说服面试官接受某个观点或技术方案。当然,在这个过程中,面试官扮演的反派可能会用一些偏激的词汇和行为,这一方面是看候选人的沟通说服和影响他人的能力,另一方面也是压力测试,看看候选人在受到刁难时的反应,是否足够职业。创新能力。

在过去的项目中,请讲述一次发现传统方法的不足,尝试新的解决问题的方法,并获得成功的经历。这类题目非常开放,但遗憾的是,在我面试过的候选人中,近半数都是在思索一会儿后回答“没有什么”。

当然,一方面可能候选人很谦虚,另一方面,则很可能是候选人确实没有尝试做过什么创新。

互联网行业,创新是一切之源,如果真的“没有什么”,如何给 Offer 呢?

第二类维度,文化价值观。

工程师文化是务实、自驱、Follow Through(跟进到底,有始有终)。一个浮夸,不思进取,凡事不愿承担责任,不能将项目跟进到底的候选人,很难成为我们的伙伴。这类维度,其实没有太多经验可谈,每个公司都有它的文化基因,而候选人是否与之匹配,是基因和环境使然。我只说下从我个人角度,最为看重的内容,否则我会一票否决。乐观积极。不得不承认,每个人都有积极的一面和消极的一面,职业化的思维在于将积极的一面展现出来,尽量弱化消除消极一面的影响。

在日常工作中,每个人都不希望遇到一群愁眉苦脸、满腹牢骚的同事。善于合作。一位同学加入到我们的团队,他不仅需要具备优秀的个人能力,同时也需要能和其他人协同合作,起到 1+1>2 的效果。我们会考查候选人在过去的经历中,对待合作的态度,有没有接触过比较复杂、跨越多个角色或团队的合作,遇到过的协作困难是什么,遇到这类困难是如何解决的。有些候选人经常会无意识地表达出,在项目研发过程中,多人写代码,还要同步需求、设计、协商接口、联合调试,而且有 Bug 修复推动也很麻烦,如果我一个人开发早就解决了。这种思维虽然无可厚非,但希望每个人可以看得更远,大型项目是一个人完成不了的,在多人合作的背景下,如何提升合作的效率和质量才是重点,而不是过多地看到负面。追求极致。这一条很难。在我发过的这么多 Offer 中,具备这个素质的候选人也是凤毛麟角,但只要具备这个素质,我几乎一定会给 Offer。当然,追求极致不等于钻牛角尖。

03 总结

面试的学问很多,很多方面我都无法讲到(比如 HR 面,我能讲的实在不多,请表现出你最积极的一面就好)。一家之言,作为参考,总之,你具备了这些,肯定能从我的手中拿到满意的 Offer。

最后

在这里我和身边一些朋友特意整理了一份快速进阶为Android高级工程师的系统且全面的学习资料。涵盖了Android初级——Android高级架构师进阶必备的一些学习技能。

附上:我们之前因为秋招收集的二十套一二线互联网公司Android面试真题(含BAT、小米、华为、美团、滴滴)和我自己整理Android复习笔记(包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。)
Android模块化面向接口编程,算法太TM重要了
理Android复习笔记(包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。)
[外链图片转存中…(img-n55M9c9c-1623063193954)]
本文在开源项目:【腾讯文档 】中已收录,里面包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等,资源持续更新中…

上一篇:模块基础


下一篇:c语言中写入日期和时间