Python 大家感觉这份面试题合格不?
大家帮忙鉴定下这份面试题，说说自己的想法，欢迎有价值的意见和建议。
{ 问题内容已经屏蔽... }
更新一下. 先说说这面试还要答题一说。作为程序员，我自己都不喜欢答题，因为感觉能不能干活和答题两码事。但是它的存在必然有道理，而且像那些瞩目的大公司都是有这个环节，而且非如此一套。虽然不能够和那些大公司相比，但是既然它有了就没有办法。
而之所以放在这个地方和大家分享讨论，也非显摆自找没趣。最简单的想法就是想看看大家伙儿的看法.别出一套很二很 SB 的笔试题来浪费应聘者的时间啊。已经看到有 @lgn21st @huacnlee 他们的回复了。提到对于应聘者这个人的其他的一些东西，认知，谈吐，价值观等等这些其实都是关注的重点，而非死扣这套题，它不能够说明并解决问题。
@mathewxiang 我现在还是不知道怎么面试程序员。就我个人的看法，针对技术水平的考察，一般看几部分：
- 首先看是不是圈子里面的人。问问他的技术栈，工作方式，工具包。
- 然后看看是否能够完成东西，看看以往作品，网络痕迹，产出。
- 然后给一个简单的开发任务，看看实际做事情的能力，比如做个爬虫爬豆瓣相册什么的。
- 还有就是需要灵性的部分，问一个超级难的问题，看看思路。
没有怎么面试过别人，上面都是纸上谈兵。
前几天看到个这个 感觉挺好的…… http://ilian.i-n-i.org/python-interview-question-and-answers/
结合做过的项目以及遇到的问题会让面试的更有话说...而且聊得差不多也就知道了吧
项目经验少的问问技术题再确定一下 但是这么问让 pm 来面试都行啊.. 各种小题出成综合题应该更能考察综合能力，而且不会一个知识不会就问的很纠结... 问怎么定义什么特点这些的太没意思啦，要是远程面试估计都能听到对面在打字
我心中的一般 (不求文艺) 技术面是这样的: 聊聊作用域和 python 的闭包，有可能说到它的奇葩之处 list comprehension 可以和 iterator/generator 放一起问，答的好再问问协程啥的 装饰器可以和 property, classmethod staticmethod 这些一起问，答的好再问问 magic method 聊聊一些 api, 一些常用的库，平时怎么查文档 谈谈对 python 各种 web 框架的理解 闲聊一下测试和写注释
反正问对了地方，被面试会感觉很爽...
教育学习风格大致可以分为美式和苏式， 这里美式和苏式只是一个非学术化的标签，
苏联老毛子的教科书一般都列举一堆定理定义，然后考试，就犹如此面试题。
美国佬鬼子的习惯一般给一个基本栗子，研究这个栗子内涵或者外延。
没有好坏之分，只是风格不同。
苏式老毛子风格面试，肯定就是做张卷子，类似的。
面试真是一件相当困难的事情，我的意见和 @lgn21st 的提议差不多，多面点儿主观题
因为现在我们还很幼小，招聘的对象不是牛人和高人，但是我觉得我们的目标人群应该也有一些参照性，尤其在有创业基因的 ruby 社区，应该创业公司都会希望招聘一些能跟自己一样快速发展的人，我也来分享一下我的一些主观题小策略，
我一般会考量如下几个相对主观的地方：
考量对程序/技术的热忱
这个随便聊聊天就能够感受到，一个对程序/技术有热忱的人，不管在唠的对不对，总之他有点啥都会跟你唠的，一个没有技术热忱的人我觉得是没办法投入在 coding 第一线的。
考量作为一个 coder 的 sense
我一般会问接触过哪些开发语言或者框架，实际开发中有怎样的感受，什么地方让你高呼好爽，什么地方让你觉得烦死了。我认为作为一个经常 coding 的程序员来说，不管任何两个语言之间，都会有感受，比如java写setter, getter太讨厌了, ruby就很爽, 这样也能很快了解他对自己号称接触/熟悉的方面了解的深度。同时也考察到了表达能力。
有不少人说"我喜欢 ruby", 但是连"因为我觉得 ruby 写着舒服"都说不出来，跟别说我期待他说出"为什么我觉得 ruby 写着舒服", 我觉得熟悉/常用某种语言人是一定能说出自己对其喜恶的感受的，如果他内心真的很知道，但是死活说不出，那我也觉得也不够好。
考量自我学习
我会问一些解决方案是前沿技术的小问题，看看面试者是否知道相应的前沿技术和为什么可以解决的大致原理，并不要求他用过或者是能够实现。我认为能看出来他对我们所关心的技术的动态是否关心，是否是一个会自己去学习和工作无关的东西。
考量对规范的遵守
你会重构自己的代码么？怎么重构？举个例子，这部分应该没什么花头
最后 根据我面的为数不多的面试者和我个人得出的结果，这些东西跟上什么学校拿什么学历真是基本上没什么关系
楼主，这是我在不查任何资料的情况下，直接打开 ST2 答题的结果，希望对你有帮助。
我最近也在面试，虽然不是面试 Python 程序员。：）:
1. List 对应普通编程概念中的数组，在 Python 中，List 里面可以容纳不同类型的数据，且 List 的大小是可以动态分配的。Tuple 相当于不可变的 List，使用起来在性能上有优势。Dict 对应编程概念中的 Hash 或者叫字典，是 Key-Value 形式的一个容器，Key 不可重复。顺便说说，还有个类型叫 Set，可以理解为不存在重复值的 List。
使用场景：
需要存储相同类型的一系列数据时，使用 List。
当上一场景的数据集不需要发生变化时，使用 Set。
当数据可以通过某种方式的 标志 进行读取时，使用 Dict。比如一个 House，里面会有 Bed，Table 等等其他嵌套的属性，且可以通过标志进行定位。
2.
List Comprehension 是从 Haskell 里面借来的思想，它是一种语法糖。用它可以实现 filter 与 map 功能的简写。
代码示例：
[i for i in xrange(100) if i % 2 == 0] # 取出 100 以内的所有偶数。
直接使用 '+' 号，不考虑它与 str.join 之间的效率问题，因为解释器会优化。
4.
for line in open('filename.txt'): print line
5.
try: d[keyy] = 1 except KeyError, e: print e
6.
generator 会使用 yield 来产生数据，可以被 for 来逐个调用。如果不使用 for 来遍历 generator 的话，可以通过 iterator 的 next 一类的函数来手动控制消费数据的节奏。如果没记错，iterator 还可以向 generator 通过 send 来发送数据进行交互。
当 generator 不被继续消费时，它会『停止』并等待下一步的消费，这是 Python 中的协程特性。
他们的关系是：generator 提供一个可用的数据集，惰性的产生数据；iterator 负责消费。
7.
特殊方法？？元编程吗？或者是 '__' 包含的方法？？我随口说几个。
len 长度相关
getattr and getattribute 略
index 貌似是这么写。控制 [] 操作符的意义。
8.
最简单的方式是使用 docstring 的测试。如果用到相关测试库的话，记不得名字。但测试的主要思想还是明白的。
9.
docstring 可以被用来生成文档，而 comment 一般不负责这个功能。且 docstring 里面可以加测试用例和一些类似 @arg:int 这样的详细说明。
使用场景：
当概括性地描述一个 类 或者 函数 的时候，使用 docstring。
当针对小的功能或者代码段进行说明的时候，使用 comment。
10.
Python 中的正则又没有什么需要特殊注意的地方。略。
唯一需要注意的地方就是，当使用的正则多次出现时，最好用上 re.compile。
11.
decorator 通俗地讲是用来『包裹』函数的。它出现在函数或者类的定义之上，用来执行一些 pre_run 和 post_run 的功能，但它一般不用来改变函数的内部运行内容。
用法？？比如写了一个通用的『函数参数打印』 decorator 的话，就可以在需要的函数前加上这个 decorator。
代码示例：
@logArgs def myFunc(arg1, arg2): pass
12.
Python 以文件作为 namespace，不存在通常意义上的全局变量和函数。所使用的外部模块都需要通过 import 来导入。
variable scope 的话，就只说说闭包方面的内容吧。在一个函数中是可以『看见』外部变量的，但只限于 get 而无法 set，一般情况下，会借助 global 声明来完成某些变量的共享。当然，也有个叫做 local 的声明可以使用，这样的话，某个被 local 声明了的变量就会从当前函数自动向外查找。
13.
classmethod 会把自己作为 cls 参数传给所定义的函数（当然，也不一定要叫 cls 这个名字），而且定义出来的函数是一个类函数。用 staticmethod 与 classmethod 差不多，只是类不会把自己传给函数，一般使用 classmethod 就好了。
普通 method 也要分两种情况。不在类中定义 method 时，不会传入 self，在类中定义时，需要手动传入 self。
and 说更细也行，只是不懂面试官想考什么。
14.
略。
15.
举一个例子：Flask 通过 decorator 的方式来实现 route 我觉得很巧妙。
#21 楼 @lgn21st 我觉得 @hello_little_yy 貌似不是在鄙视楼主诶...他鄙视的是面试官吧...因为一开始他 bless 楼主啊..
对了，楼主，忘了说。我最近为了面前端职位，一直都是复习的 HTTP、CSS、JS 这类东西。Python 已经很久没有看了，虽然平常也会使用它。
这份面试题合不合格的话，要看你面的是什么公司的什么职位了。但如果面试者单纯面这些，而缺乏了一些主观性方面的题目的话，当然是不合格的一个面试题。
and 我觉得，有可能面试官也不是想你全部回答出来这些问题吧，可能他是想尽量多出点题目，然后挑你掌握的部分跟你聊，免得出了你刚好不懂的题目把你给错过了。
看了 LZ 的编辑，那么我单就技术问题说说吧。做了一年左右的"职业" Python web 开发，觉得 LZ 提出的问题所考察的知识还是很重要的。如果这些知识还要在用的时候临时去查，多少有点对不起简历上的"有 Python 使用经验".
一个例外是第 15 题，我个人目前还没有心情去扣流行的 web 开发框架底层的代码，因为现在的工作用的是个不怎么流行的...... 以及，流行的框架经由社区的打磨，一般也足够稳定，没出什么故障的话我反正很少去扣。话说回来，如果这方面的知识和 LZ 招的职位需求很契合 (比如需要为框架开发插件/自行 patch), 那么问问无妨。
以及，我觉得还可以补充一下模块系统 (虽然不难) 和 new style class 的方法解析顺序什么的。这些在我看来也属于必须掌握，随时脑内取用，最好不要临时去查的知识。虽说工作时总归是有条件去查文档，但解决稍微复杂一些的问题 -- 尤其是 debug 别人的代码 -- 时，如果这些知识不能像蝙蝠侠腰带上的工具一样熟悉，估计是会有些吃力的。
话又说回来，既然 LZ 对这种答题的形式也反感，完全可以换一种形式来考察这些知识点。比如这篇文章的作者采用的方法是：制造一个相对真实的简单问题，让面试者现场解决。问题本身要能覆盖若干面试官所关心的知识点 (可能覆盖不全，但可以再引导面试者重构，覆盖更多知识点的同时也考察重构能力), 也能观察得到面试者的工作方式。这样的形式估计就好很多。
这和有没有文化有关系？何为有文化？跑题了，不扯了。
感谢给我用心回复的给位.
好像大家没有提到一点，那就是面试者的 主观因素 .有时候感觉占更大的比例的是第一印象思维表达谈吐。
