iOS面试题整理iOS-进阶题目IOS面试专题

小米、百度、bigo 、滴滴 、快手等iOS 面试后的一次阶段性

2020-07-04  本文已影响0人  iOS开发面试题技术合集

面试过程

在疫情期间都是远程面试,下边先介绍一下疫情期间面试的一些公司的面试情况。同时拿到了其中几家的 offer。下边介绍的面试题只还原了其中印象比较深的部分,会存在不足的情况,并不代表面试的全部。

小米

一面

二面

三面

百度

百度只有一面,因为面得是百度的商业化部门,对于细节的要求非常严格。个人感觉自己的表现确实不是很好。

PS:当时面试官明确告诉我,这个面试题做不好,面试是直接结束的。

Bigo

感觉面试的这些公司,Bigo 对于基础的考察最全面。

一面

二面

三面

滴滴

一面

滴滴的一面分为两部分。

二面

三面

快手

快手的一面是跨部门面试,二面是本部门面,所以一二面面试题会有一些重复,只写了一次。

一面

二面

三面

其他

除了上边介绍的公司外,还面了平安,51 talk,58 同城,好未来,美篇。

因为绝大部分面试内容和上边的基本上只是重复,只对差异性的面试题进行了总结。

iOS 的一些面试准备

上边聊完了面试过程中遇到的面试题,下边聊聊自己在面试之前的一些准备工作。

其实这次跳槽对于个人而言是很早之前就有准备了的,所以疫情对于我的影响并不是很大。此外想突出强调的是 iOS 面试中的基础知识在于日常的积累和总结,单纯的靠面试前的短期准备个人感觉是不够的。

下边根据上边的面试题和之前个人的面试准备,对整个面试过程做了一次梳理。

1.算法

《剑指 offer》 半个多月的时间用 Swift 敲了一遍,然后用 OC 手写了一遍。

之前断断续续刷了 LeetCode 上 Medium 和 Easy 的题有 150+

对于国内的小伙伴,基本上客户端面试涉及到的算法知识是足够覆盖的了。当然快手的三面算法题还是被虐了...

如果你正在跳槽或者正准备跳槽不妨动动小手,添加一下咱们的交流群1012951431来获取一份详细的大厂面试资料为你的跳槽多添一份保障。

2.基础

其实个人认为 iOS 基础知识部分真的需要个人日常的一些积累,在面试准备阶段对整个积累的整体串联,然后再查缺补漏的过程,下边是我自己面试准备阶段的一些知识主线。

上边大致是我在面试之前和面试之后对于 iOS 基础知识的梳理出来的主线。感觉不够全面,但是面对市场上主流的 iOS 面试应该足够了,很多同学可能对于上边涉及的知识点会有一个问题就是面试造火箭的感觉,对于实际开发中真正能用到的东西十分有限,对于项目的实际开发,实际使用十分有限。

下边谈一下个人对于类似观点的理解。

首先面试是一次筛选的过程,而上边的知识点就是相对而言更有筛选的辨识度。而日常开发中所谓的扭螺丝的内容对于绝大部分开发者而言都没有很好的区分能力。面试官在面试过程中更希望看到的是候选人在日常中的积累和学习的能力。而基础知识的扎实是学习能力和学习意愿的一种体现。

此外,其实现在的客户端市场上,因为多年前培训机构的原因,不缺乏初级开发者,对于大厂而言,项目的复杂度和代码的维护成本都是很多项目很关注的点,当下市场上需要的基础知识扎实,然后可以根据基础知识来做各种项目优化相关的 developer。所以有一些对于基础的要求也无可厚非。

聊到项目优化,下边是在面试准备阶段对于项目优化结合过往项目经验和之前知识积累做的一些准备。

3.项目优化

4.架构

其实聊到架构,不知道从什么时候开始 iOS 圈子里的话题就集中在了 MVC,MVP,MVVM 和 Viper 这几种之间的比较。

由于笔者只是对于 MVC 和 MVVM 有相对多的使用,所以谈谈自己对于架构的理解。

个人认为这几种架构不存在绝对意义上的孰优孰略,每一种架构都有其产生的对应的背景。而且不认为说一个项目一定就全是 MVC 或者 MVVM。或者说脱离了 RAC 就不能使用 MVVM 的方式来做设计项目中的部分代码。

笔者个人认为,项目的架构选择的问题上需要考量业务背景,效率方面的因素。

比如传统的 MVC 架构,最大的槽点就在于很多人认为 view 和 model 层很轻,但是 controller 层代码冗余较多,于是产生了 MVVM 的架构,笔者个人对于 MVVM 是这个背景下产生的说法是否定的。

笔者个人认为, 传统的 MVC 架构如果 controller 的代码过多最大的原因在于 developer 本身的问题,其实完全可以根据业务将对应的逻辑进行拆分分别的放到一些对应的 manager 管理类中做处理。将一个页面拆分成更多小得 MVC 的方式来解决项目过多的在一处维护困难的问题。个人认为这样的方式一样可以提高代码的可维护性。此时看 manager 很像 MVVM 中的 VM 。

笔者的观点貌似就是在说 MVVM 的产生没有什么价值。其实并不是这样的。我们在聊一个架构模式的时候需要了解 MVVM 的优点。其实 MVVM 的架构设计较早的出现在前端领域。个人认为当一个页面的交互非常多,数据传递链比较深的时候,通过 MVVM 和 RAC 的结合的方式可以大大的降低代码的维护成本和提高代码的可读性,而且可以很好且方便的做状态管理。在这种场景下使用 MVVM 是我认为很好的场景。而对于一个偏静态的页面而言,我并认为 MVVM 和 MVC 存在孰优孰略。从维护成本的角度考量,反而 MVC 可能更优。

所以个人认为 MVC 和 MVVM 对于一个项目而言不是二选一的关系,而是可以结合场景选择来使用。

此外就是效率问题,对于很多项目而言,很多人说 MVVM 更好就一定要 MVVM + RAC 。我认为这有些偏激的成分存在,需要考虑团队整体技术储备和维护成本的整体考量。

如果组里只有一两个人会 MVVM + RAC ,而剩下的人对于类似的知识点根本不掌握,不是说其他人不应该学习和进阶。而是说应该在考量开发效率和成本,对应的选择性放弃,之后条件允许后在逐步做迁徙。个人比较反对架构的非黑即白。

此外,想表达一点个人观点在于大多人的关注点貌似都注意在了对于 MVVM 和 MVC 的比较之中,而忽略了设计模式和设计原则的重要性。

其实个人认为尤其是日常的业务开发,设计模式和设计原则的使用在模块或者业务中更为重要。

笔者觉得关于设计模式和设计原则的知识可以读读《Objective-C 编程之道》。

此外对于改善和提高代码能力可以看看《重构》《代码整洁之道》。

5.成长的思考

上边的总结的很多知识点,并不是我在准备面试的阶段才去看对应的知识的,而是在日常开发中积累的知识的一次梳理和总结。将日常琐碎不体系的积累的一次梳理和总结。

上边的知识的获取的途径都很方便,网上有很多前辈有非常好的总结。比如 runtime 的部分我就是看了源码+霜神的神经病院系列+ draveness 的很多文章来进行学习的。

笔者认为比较好的学习方式在于体系化整体的学习,而对于公众号或者简书文章的碎片化记忆。个人觉得当下碎片化学习的概念炒得火热,但是碎片化的学习的核心是可以用碎片的时间高效的学习知识体系中小的点,提高学习的效率,但归根结底,还是知识要成体系,还是要将碎片化的内容整体的串联起来才更高效,如果只是一个个碎片化的知识,没有整体性的视角,个人感觉随着时间线的推移,用不了多久在不使用的情况下就被遗忘了。

然后就是优秀的源码的学习,我在很早之前就读过 Aspect 的源码,代码量不大,但是设计质量非常高,后来 JSPatch 开源的时候去读相关的源码,虽然不知道 Bang 神的消息转发机制有没有参考过 Aspect,但是发现消息转发机制上的源码有很多的相似之处,因为之间的积累,JSPatch 源码的阅读相对而言很顺畅。后来自己在工作中写一些小的工具也有过类似的尝试。

此外个人认为技术的深度比技术的广度更为重要。对于 iOS 端个人认为进阶的方向有 Clang 和 LVVM 相关的知识,汇编,逆向等等。上述知识体系,也只有汇编有过比较多的接触。对于一些奇怪的问题的追溯,汇编真的很好用。当然其他知识也在学习,最近戴铭老师出了一本 《iOS 变成理顺核心知识点》,书的质量很高,就是深入学习的一个起点。

对于技术广度的问题,笔者的经验是挖掘自己的一些需求,然后根据自身的需求出发,比如 Swift 的学习之后,如果我们工作的项目还是 OC ,我们可以有一些优化的需求需要用到脚本的时候可以尝试用 Swift 来写脚本。或者尝试将一些简单一些的开源库用 Swift 重写。亦或者我日常对于理财和经济学的东西较为关注,我会用 Swift 写一些自己手机上使用的软件,比如真实利率的计算。曾经为了利用好碎片时间用 Swift 写过一个很简单地 JS 编辑器等等。

其实自己后来学习 Python 的过程也是和生活中的一些需求有直接的关系,还是认为兴趣是最好的老师,建立起兴趣,然后在玩的过程中学习,简单又高效。当然说起来容易,做起来对我同样很难...

结尾

当然上边的内容是自己对于过往经验的一个总结,有些部分难免有片面甚至错误的地方,还希望大家能够指正。

希望本文能为部分准备求职和在职的处在迷茫期的同学提供一种思路。成长永远不可能一蹴而就,都是在不断积累和学习中完成的厚积薄发。

之后希望和大家多多交流。

面试资料:

看完文章如果你正在跳槽或者正准备跳槽不妨动动小手,添加一下咱们的交流群1012951431来获取一份详细的大厂面试资料为你的跳槽多添一份保障。

上一篇下一篇

猜你喜欢

热点阅读