程序员趣闻

开发者和经理分享他们听到的或知道的、一些技术面试问题的可笑的答案。

大多数公司雇佣软件开发人员的标准操作流程是让应聘者接受某种技术面试。目的是为了通过一些涉及到语言语法、编程概念和一般问题解决的问答来了解应聘者的技术水平。你可以想象出来,有时候由于误解或纯粹地不符合岗位要求,面试官会得到让人惊奇的,或非常有趣的技术问题的答案。

Ouora,来自于技术面试过程的双方最近分享了一些他们在技术面试中收到的或被给的愚蠢的答案。我摘取我收藏的一些,仅供娱乐。当然,我不知道有多少是真的,但是它们总让我笑出来。

在Google,我问一个家伙,为每个字母产生一个映射,它需要在字符串里出现多少次。 我问他数组应该多大。(我的目的是测试他是否考虑了大小写,所有的ASCII字符等) 我:你的数组多长? 应聘者:长度会是24. 我:……为什么? 面试者:英语字母表有24个字母,因此我们需要24个。 我:好吧。真的……很接近了。

面试应聘Google SRE (Site Reliability Engineer)经理职位的应聘者。话题是misc【注1】,Unix系统的技术。 我:如何杀掉一个僵尸进程(zombie)? 应聘者:用电锯?

说了一堆编程语言之后,面试官:“你知道C吗?”...

编程法则和现状:我们明白自认为明白的东西吗?

当面对复杂数据时,编程格言是如何经得起考验的? 软件工程领域的知名专家[Capers Jones](https://en.wikipedia.org/wiki/Capers_Jones),已经建立了涵盖20,000个项目的范围广泛的项目记录数据库,大部分都是大型的。有了这些数据支持,他经常写文章讨论,哪些活动和方法在实践中发挥着作用,以及如果可能,它们实际上提供多少提升幅度,它们的成本有多少。在这篇客座编辑里,他非正式地评价了一些编程和业务上的流行“法则”在面对软件开发现状时,是如何发挥作用的。

Boehm第二法则

原型显著减少了需求和设计错误,特别是用户错误。

Barry Boehm提出的这个法则是有数据支持的。需要说明的是,原型大概占到规划的系统规模的10%。对于1,000个功能点的应用程序,原型大概会有100个功能点,容易构建。对于100,000个功能点的大型应用程序,原型本身会是一个具备10,000个功能点的大型系统。这得出一个结论,如果可能的话,大型系统最好采用增量式开发的方式。

Brooks的法则

给一个延期的软件项目增加人手会让项目更延期。

Fred Brooks的法则在计算机领域是非常知名的。在一定程度上它有证据支持。应用程序越大,无论怎样,挽救进度延期都要越困难。对于少于五人团队规模的小项目,增加一个有经验的人不会拉长进度,但是增加一个新手就会拉长。对于超过100人团队规模的大型应用程序,这些项目几乎总是由于糟糕的质量控制和变化控制而延期。增加人手会因为培训和复杂的沟通渠道而趋于减缓进度。

Conway的法则

任何一款软件都会体现生产它的组织结构。

数据趋于支持该法则。需要说明的是,每个软件的组件规模都要考虑匹配被安排这部分工作的团队大小。由于很多团队包含八个人,这就意味着再大的系统或许也要被分解成能够安排给八个人一个部门的组件,这对于应用程序的总体架构可能不是最优的。

阅读文档,更便捷

做为一名开发者,我的大把时间花在阅读文档上。甚至大部分时间花在找到上面提到的文档。过去一直这样,直到Dash走进我的生活。

Dash是一个管理自包含文档包的应用程序,称作docsets。你会找到几乎每种语言、每个类库、框架和内容管理系统,你甚至能够导入其他东东以扩大它的类库。通过启用、不启用docsets,你能够刚好根据你的要求来调整Dash。

更好的功能是,它本地化存储,因此你总是可以访问,无论你在飞机上办公,还是在网速慢、经常掉线的网络上。

强大的搜索引擎允许你瞬间精确找到所需资料,开始输入,你就会得到来自于所有启用的docsets上的结果。你甚至能够通过在查询里增加前缀比如html:, css:, 或sass: 把搜索限制到某个特定的感兴趣的范围。

Dash docsets 搜索

在侧边栏列表底部,有指向Google和StackOverflow查询结果的帮助链接,对于极少数搜索不到文档的情况下,这是有帮助的。

Dash的朋友

Dash本身已经证明了它对于我的工作流是一款极有帮助的附属,但是当和