你好，我是白海飞。今天是面试答疑时间。
专栏更新接近尾声，而我发现大家的回复中，直接问的问题越来越少，总结和思考越来越多，而且读过之后，让人受益匪浅。留言中问的很多问题很有针对性，我反复斟酌，筛选了一些在这里我们一起探讨下。
“为什么面试要考逻辑题呢？”
这涉及编程技能和逻辑分析能力的关系。考逻辑题，最根本的目的是想看你聪不聪明。聪明的头脑，可以更快更准地理解、表达、分析和解决问题。
计算机编程，是一门技术活，那些把编程说成“搬砖”的人，很可能还没有为复杂的问题写出过高效的代码。一个好的程序员，应该有清晰的逻辑分析能力。
我在面试时，除了考查应聘者的计算机基础（操作系统、编程语言、算法、网络等），还会检查他的逻辑能力：包括表达、思考。这有两种考查方法：一是看回答时的反应和思路，二是直接考查逻辑、算法或者智力题。
我在面试过程中其实不太在意对方回答的结果是否正确，而主要看他如何理解这个问题，采取了哪些有意义的尝试，在碰壁之后如何自我修正，逐渐接近合理的答案。这个过程，能反应出应聘者是否能锲而不舍地从多方面看问题，思考过程是否有条理、成体系，是否在用计算机思维思考问题。
说到计算机思维，我们来说一下如何培养计算机逻辑分析能力。还记得离散数学这门课吧？我认为，这门课奠定了计算机思维的基础。无论是计算机原理、编程算法，以及复杂业务逻辑实现，都离不开离散数学里讲的逻辑。我的感受是，它让我能够按计算机的思路去思考生活中的问题。
经常看到有的程序员长时间停留在只能编简单的类或写简单的SQL的水平，碰到复杂算法和架构就头痛，甚至调程序都困难，追根究底，是计算机思维这块存在欠缺。如果你转行学计算机，而且想打好逻辑训练基础的话，可以学学离散数学。
“我不擅长讲东西，工作内容讲得一般，生活小故事也讲不清。所以更喜欢听别人讲，然后自己去梳理逻辑。这个怎么调节呢？”
这是上个问题的延伸，也涉及逻辑分析能力。
有时候，听一个东西，我们以为自己理解了，其实只是当时大脑按照讲解者的提示，走通了，新知识并不一定和已知的知识体建立了连接，这样过后儿自己回想，可能就又糊涂了。而且，你如果要讲出来的话，得把新知识按某条逻辑组织起来，捏着某个点提起来，这其实很考验对知识的“连接”程度。所以才听懂容易，讲明白难。
想提高的话，还是得多练。比如，故事复述，给别人讲题，口述笔记……一开始讲不流利，没关系，先写出来，把节奏放慢，一边写一边思考前后怎么衔接。不妨先从百字的小段落做起，贵在坚持，三个月后再来看看效果。
“请问，高级和资深如何在简历中体现？”
所谓“高级”“资深”，在简历中，体现在工作范围和难度方面。想一想在你的职位级别上，你解决过哪些领域的问题，并且有哪些是复杂的、有深度的、有难度的、有意义的工作。比如，你是一位工程师或者技术骨干，你有没有做过设计、问题分析、改造缺陷等工作内容。再比如，你只是在兢兢业业地完成分配的任务，还是会关注跨领域、跨团队、跨专业的工作？这些问题的复杂性、挑战性在哪里？另外，“贯通篇”中提到的几种能力，做好了，就可谓是高级和资深了。
有位用户说，“一份儿优秀的简历最重要的是背后这个人是优秀的”。这句话的含义是说，简历得由能力和经验支撑。所以，工作中我们不断挖掘自己的潜力，扩展工作范围，去尽量探索和完成一些挑战性的的工作，才能让自己技术有宽度，业务有规模，解决的问题有复杂性，带队有规模有成长……这些都能体现出“高级”和“资深”。
注意，“高级”和“资深”不能只看工作年头，也不能只看某一个种能力。
“我有不少兴趣爱好，但都是处于消遣娱乐的层次，怎么进入生产稳定的层次呢？”
其实，爱好，本来就是以消遣娱乐为目的的，不一定非要进入产出层，所以没有产出层的爱好，一点问题没有。因为这仅仅是个爱好呀，谁给我们压力说某个爱好做不好，就怎么怎么样？
但是有的人，即使在没有任何压力的情况下，也会自愿追求一种更高层面的消遣娱乐：心理成就感，甚至自我实现，而不是单纯停留在感官娱乐上。比如滑雪，已经不满足于滑行的快感，而是追求Get各种技能，或者得到更多的赞美，或者教会其他人，交更多的朋友。这样一来，他自己“玩出花样”，努力做到更好，自然而然地就进入了产出层。
可以看到，“主观、自愿”这点很重要。是什么因素在推动着“自愿”行动呢？首先要有对这个爱好的热情，或者目标感和认同感；然后是自律，能在困难和辛苦面前，持续努力；再就是追求成就感，也就是精神上的收获，进而让你的身心处于一种“心流”状态，而这种状态可以促使你自己更加努力，不断冲向下一个目标。所以，是热情、自律、成就感这些内驱力，让你把对爱好的追求上升到“心流”的层次，水到渠成地收获更多产出。
“对于996的工作来说，时间都被新需求的开发或者Bug占用了，这样的场景下，即使找到了可提高的点，对于实现来说，恐怕没有时间挤出来做出改变……面对这些情况应该如何去做为好？”
解决好这个问题，我个人以为主要看团队的做法，个人能改变的空间比较小。
代码里可提高的点，我们称为“技术债”。对于技术债，敏捷开发里的做法，是和业务需求放到一起排优先级，然后放到迭代里做。一个迭代中给技术债的占比设置一个合适的值，这样，达到做新需求和改造旧代码的平衡。
当然，这有个前提，就是需要产品经理认可解决技术债的重要性。如果项目业务压力过大，产品经理往往更关注在功能产出上，而忽略了产品的“内功”。长期下去，代码越来越难维护，Bug越来越容易出现，开发效率会严重降低。这时候再关注技术债，就要动大手术了。
我们很多项目都是这样一步步变得“不可救药”的。为了持续满足客户需要，大家996地面向Bug编程：本来可以半小时搞定的编码工作，可能需要一整天，还要解决几个毫无头绪的新Bug。这样的加班，对自己的技术积累确实没多少价值。
所以，如果有加班，应该是为了“减少加班”而加班。首先通过梳理客户需求，按照价值优先级去实现，而不是眉毛胡子一把抓，不要什么都做。不要在计划中用加班去实现需求，奖励大家去解决技术债，去优化代码。如果大家用加班的时间去解决技术债，不要打击大家的激情。随着代码质量的渐渐提高，Bug越来越少，需求会实现得越来越快。当然，这中间有很多问题要考虑，很考验业务团队的耐心，以及开发团队的决心。
今天的答疑就到这里。你可能发现，今天这篇答疑的内容，都和我们专栏自始至终强调的“能力”相关。所谓，面试不只是临时抱佛脚的事，让别人认可你的能力，不能仅靠“说”的功夫，重要的前提是能“做”。
“做”是根本，把你做出的工作成果、解决问题的过程、选取方案的原则，甚至失败的尝试，能系统地总结，有条理地讲出来，改变大家的认知和做法，获得面试官的认可，是对大家学习这个专栏的期望。阅读专栏至今，你觉得自己有没有哪里做得更好了呢？或者意识上有了些改变？
最后，如果今天的文章让你有所收获，欢迎在文章下方留言，也欢迎把它分享给你的朋友，一起探讨提高。
评论