1. 我从来不问google可获得的答案的问题， 只是问问面试者「在过去的工作中，遇到的Ta认为最有成就感的一件事情是什么」和「如果出现了一个google不到的问题，你会怎么解决」这样的问题。

2. 我从来不问操作系统等和Python无关的话题，首先是我不怎么问和工作太无关的话题，有些东西用不到很多就被会遗忘，挑起来这种问题其实挺无聊；其次我是非计算机专业毕业，问的东西说不定我自己都没有把握，那就不出来献丑了。我只关注面试者的学习能力和解决问题的方式，说白了，是不是就是看他是不是「聪明的人」。

3. 不问面试者的短处。我在自己被面试的时候有过这种精力，面试者问他擅长的内容，我不一定搞的定，如果反过来面试Ta，我也会灭掉Ta。所以我会尽力寻找面试者的优势和优点，尤其是对方已经明确承认。其实很多经验和能力，只是需要一个机会和环境，所以我不想放过任何一个合适的人。

4. 面试者不会Python也没有关系。面试者的主动性和学习能力觉得更重要，如果他在其他领域能证明做的不错或者能让我感觉到这个一个未来有潜质成为优秀工程师的人，不会Python没有关系。 嗯目前看来，我没有看错过。

5. 我从来不问Python语法这种看书和google就能学会的问题，我只想了解Ta是否愿意去学。举个例子，我会让面试者「讲讲日常开发中都用到了那些Python内置的模块」，原因在我的专栏「Python之美 - 知乎专栏」的 Python不能不知的模块 - Python之美 - 知乎专栏中有写，基本上说完我就能评估出他的能力和风格，继而就是再问一些问题去验证我的评估是不是准确。

6. 最后，我一般都会和面试者细聊一个Ta认为在过去的工作或者自己开源的项目中最熟悉的一个，从项目设计、踩过的坑儿、开发周期以及如何安排、如何确定需求、如何和其他人协作等方面，最后评估下Ta是否能很容易的融入到我们现在的团队，大家是否可以接受Ta，对工作不负责的、没有用心工作的、没有团队意识的、沟通能力有缺陷的就放弃掉，对性格上容易发生冲突的、不适合团队合作的我就得考虑下，未来也会如实反馈给HR。

推荐几本书

《python参考手册》，绝对让你更上一层楼

《图解密码技术》，密码入门不二之选

《mysql技术内幕》（第五版），有点厚当手册读读，要有耐心，《高性能mysql》也强烈建议读读

《effective tcp/ip programming》

如果是搞web的对操作系统这块和密码技术会偏弱，但如果是系统工程师或是游戏服务端这块会明显偏强。吃午饭的时候我就一直在想这个问题，我觉得重点不是Python而是后端工程师，因为Python只是系统的一部分，linux基础操作要熟吧，sql要懂吧，消息队列要知道吧，git要熟悉吧……木桶理论，每一环都不能落下，精通其中一两环就更好了。基础功扎实，新东西学得快，代码写得溜，命令敲得顺，bug解的好，妈妈再也不用担心我天天加班了~~~

一.语言

1.推荐一本看过最好的python书籍？ 拉开话题好扯淡

2.谈谈python的装饰器，迭代器，yield？

3.标准库线程安全的队列是哪一个？不安全的是哪一个？logging是线程安全的吗？

4.python适合的场景有哪些？当遇到计算密集型任务怎么办？

5.python高并发解决方案？我希望听到twisted->tornado->gevent，能扯到golang,erlang更好

二.操作系统

可以直接认为是linux，毕竟搞后端的多数是和linux打交道。

1.tcp/udp的区别？tcp粘包是怎么回事，如何处理？udp有粘包吗？

2.time_wait是什么情况？出现过多的close_wait可能是什么原因？

3.epoll,select的区别？边缘触发，水平触发区别？

三.存储

存储可能包含rdbms，nosql以及缓存等，我以mysql,redis举例

mysql相关

1.谈谈mysql字符集和排序规则？

2.varchar与char的区别是什么？大小限制？utf8字符集下varchar最多能存多少个字符

3.primary key和unique的区别？

4.外键有什么用，是否该用外键？外键一定需要索引吗？

5.myisam与innodb的区别？innodb的两阶段锁定协议是什么情况？

6.索引有什么用，大致原理是什么？设计索引有什么注意点？

redis相关

1.什么场景用redis，为什么mysql不适合？

2.谈谈redis的事务？用事务模拟原子+1操作？原子操作还有其它解决方案吗？

3.redis内存满了会怎么样？

四.安全

web安全相关

1.sql注入是怎么产生的，如何防止？

2.xss如何预防？htmlescape后能否避免xss?

3.csrf是什么？django是如何防范的？

密码技术

1.什么是分组加密？加密模式有哪些？ecb和cbc模式有什么区别？为什么需要iv向量？

2.简单说说https的过程？

3.对称加密与非对称加密区别？

4.如何生成共享秘钥？ 如何防范中间人攻击？

react 的概述

React 的设计哲学：

以“简单直观”、“符合习惯”的方式去编程，让代码更容易被理解，从而易于维护和不断演化。

React 的最大价值？

1.高性能虚拟 DOM 【★★】
2.声明式的、直观的编程方式（别样的组件化、JSX也不是核心）【★】
3.封装过的事件机制
4.服务器端 Reader（忽略，不是核心，锦上添花）
5.完善的错误提示信息

React 的适用场景：

适用于数据不断变化的大型应用程序，eg.聊天、评论等
会面临问题：如何将服务器端 or 用户输入的数据高效地反应到复杂的用户界面上

React 原理

新的前端 UI 的构建方式：两层编程模型：数据模型、UI界面。数据模型驱动UI界面（从概念角度上看是直观的，而实际开发中困难重重）

React 的初衷之一就是：既然整体刷新一定能解决层叠更新的问题，那我们为什么不索性就每次都这么做呢？让框架自身去解决哪些局部 UI 需要更新的问题-React做到了，实现的途径就是通过虚拟 DOM。

UI界面是一颗 DOM 树。我们再在全局定义一个唯一的数据模型。每次数据模型有任何变化，都将整个数据模型应用到 UI DOM 树上（由 React 来负责更新需要更新的界面部分）。

虚拟 DOM

将变化的数据实时反应到UI上，就要对 DOM 进行操作。复杂和频繁的 DOM 操作，通常是性能瓶颈产生的原因。

虚拟DOM，是在浏览器端用 JS 实现了一套 DOM API。基于 React 的所有 DOM 构造都是通过虚拟 DOM 进行的。每当数据变化时，React 会重 新构建整个 DOM 树，并将当前的树和上一次的 DOM 树进行对比，得到 DOM 结构的区别。然后仅仅将需要变化的部分进行实际的浏览器 DOM 更新。且，React 能够批处理虚拟 DOM 的刷新，在一个事件循环内的两次数据变化会被合并。

虽然，每次都要构造完整的虚拟 DOM 树，但因为它是内存数据，性能极高 【那会消耗多少内存呢？】对实际 DOM 的操作，仅仅是 Diff 部分，故能提高性能。（至于 React 如何做到将原来 O(n^3) 复杂度的 Diff 算法降低到 O（n），感兴趣的你可以再深入学习下）

你永远只需要关心数据整体，两次数据之间的 UI 如何变化，则完全交给框架去做。开发逻辑没那么复杂了，开发难度降低，产生的bug几率也就更少。

简化的组件模型

所谓组件，就是状态机器。对组件的管理 就是对状态的管理。这么，React 很少要暴露组件方法和外部交互，只要设置状态即可，只需要考虑在某个状态下UI是怎样的。

React 将用户界面看做简单的状态机器。当组件处于某个状态时，那就输出这个状态对应的界面，以保证界面的一致性。在 React 中，你只需要简单的更新某个组件的状态即可，然后基于新状态输出整个页面。由 React 负责以最高效的方式去比较两个界面并更新 DOM 树。

组件是 React 中构建用户界面的基本单位。与外界的交互除了 state（状态）之外，还有 props（属性）。事实上，state 更多由组件内部自己维护，props 则由外部初始化该组件时传递进来（一般是组件需要管理的数据）。React 认为，props 应该是只读的（一旦赋值过去就不要变化了）。

虚拟化DOM，不仅简化了UI逻辑，也内含了组件化开发思想。组件，即封装起来的具有独立功能的UI部件。将UI上每一个功能相对独立的模块定义成组件，然后将小的组件通过组合 or 嵌套构成大的组件，最终完成整体UI的构建。

MVC：开发者将三者定义成不同的类，实现了表现、数据、控制的分离（从技术角度拆分UI实现松耦合）
React：新的思路，开发者从功能的角度出发，将UI拆成不同的组件。每个组件都独立封装。即按照界面模块自然划分的方式来组织和编写你的代码。

每个组件的UI和逻辑都定义在它们内部，高度自治。和外部完全通过API来交互，通过组合来实现复杂功能。

React 认为，一个组件应该具备以下特征：

• 可组合 Composeable：接口

• 可重用 Reusable：独立

• 可维护 Maintainable：各个组件仅包含自身的逻辑，更容易被理解和维护

• 可测试 Testable

谈一谈 flask

从http 请求开始到响应

前置技能 wsgi

WSGI，全称 Web Server Gateway Interface，或者 Python Web Server Gateway Interface ，是为 Python 语言定义的 Web 服务器和 Web 应用程序或框架之间的一种简单而通用的接口。自从 WSGI 被开发出来以后，许多其它语言中也出现了类似接口。

WSGI 的官方定义是，the Python Web Server Gateway Interface。从名字就可以看出来，这东西是一个Gateway，也就是网关。网关的作用就是在协议之间进行转换。

WSGI 是作为 Web 服务器与 Web 应用程序或应用框架之间的一种低级别的接口，以提升可移植 Web 应用开发的共同点。WSGI 是基于现存的 CGI 标准而设计的。

很多框架都自带了 WSGI server ，比如 Flask，webpy，Django、CherryPy等等。当然性能都不好，自带的 web server 更多的是测试用途，发布时则使用生产环境的 WSGI server或者是联合 nginx 做 uwsgi 。

在网上搜过WSGI的人应该会看到一个图，左边是Server，右边是APP，中间有一个连接纽带是WSGI。

不过，我看了源码以后的理解和这个有些不同，我个人觉得，实际上不应该单独写一个APP，因为，这个WSGI的使用方法实际上也是包含在APP里面的，最右端的app实际上应该指的是逻辑功能，包括URL和view function的对应关系。

WSGI其实是作为一个接口，来接受Server传递过来的信息, 然后通过这个接口调用后台app里的view function进行响应。

起到一个接口的功能，前面对接服务器，后面对接app的具体功能

def application(environ, start_response):               # 一个符合wsgi协议的应用程序写法应该接受2个参数
    start_response('200 OK', [('Content-Type', 'text/html')])  # environ为http的相关信息，如请求头等 start_response则是响应信息
    return [b'<h1>Hello, web!</h1>']        # return出来是响应内容

但是，作为app本身，你就算启动了程序，你也没办法给application传递参数？

所以，实际上，调用application和传递2个参数的动作，是服务器来进行的，比如Gunicorn.

而这个叫做application的东西，在Flask框架内部的名字，叫做wsgi_app，请看下面章节的源码。

from flask import Flask  

app = Flask(__name__)         #生成app实例  

@app.route('/')  
def index():  
        return 'Hello World'  

这样，一个flask app就生成了

但是这里有一个概念必须要搞清楚，就是当你的gunicorn收到http请求，去调用app的时候，他实际上是用了Flask 的 call方法，这点非常重要！！！

因为call方法怎么写，决定了你整个流程从哪里开始。

flask类的call方法

class Flask(_PackageBoundObject):        #Flask类  

#中间省略一些代码  

    def __call__(self, environ, start_response):    #Flask实例的__call__方法  
        """Shortcut for :attr:`wsgi_app`."""  
        return self.wsgi_app(environ, start_response)  #注意他的return，他返回的时候，实际上是调用了wsgi_app这个功能      

如此一来，我们便知道，当http请求从server发送过来的时候，他会启动call功能，最终实际是调用了wsgi_app功能并传入environ和start_response

class Flask(_PackageBoundObject):  

#中间省略一些代码  
                                #请注意函数的说明，说得非常准确，这个wsgi_app是一个真正的WSGI应用  
    def wsgi_app(self, environ, start_response):    #他扮演的是一个中间角色  
        """The actual WSGI application.  This is not implemented in 
        `__call__` so that middlewares can be applied without losing a 
        reference to the class.  So instead of doing this:: 

            app = MyMiddleware(app) 

        It's a better idea to do this instead:: 

            app.wsgi_app = MyMiddleware(app.wsgi_app) 

        Then you still have the original application object around and 
        can continue to call methods on it. 

        :param environ: a WSGI environment 
        :param start_response: a callable accepting a status code, 
                               a list of headers and an optional 
                               exception context to start the response 
        """  
        ctx = self.request_context(environ)  
        ctx.push()  
        error = None  
        try:  
            try:  
                response = self.full_dispatch_request()    #full_dispatch_request起到了预处理和错误处理以及分发请求的作用  
            except Exception as e:  
                error = e  
                response = self.make_response(self.handle_exception(e))  #如果有错误发生，则生成错误响应  
            return response(environ, start_response)       #如果没有错误发生，则正常响应请求，返回响应内容  
        finally:  
            if self.should_ignore_error(error):  
                error = None  
            ctx.auto_pop(error)

WSGI_APP 的内部流程

1. 生成request请求对象和请求上下文环境

2. 请求进入预处理，错误处理及请求转发到响应的过程

   class Flask(_PackageBoundObject):  
   
   #此处省略一些代码  
   
   def full_dispatch_request(self):  
       """Dispatches the request and on top of that performs request 
       pre and postprocessing as well as HTTP exception catching and 
       error handling. 
   
       .. versionadded:: 0.7 
       """  
       self.try_trigger_before_first_request_functions()  #进行发生真实请求前的处理  
       try:  
           request_started.send(self)                     #socket部分的操作  
           rv = self.preprocess_request()                 #进行请求的预处理  
           if rv is None:  
               rv = self.dispatch_request()  
       except Exception as e:  
           rv = self.handle_user_exception(e)  
       response = self.make_response(rv)  
       response = self.process_response(response)  
       request_finished.send(self, response=response)  
       return response  
   

1. 请求分发

class Flask(_PackageBoundObject):  

#省略一些代码  

    def dispatch_request(self):   #看函数定义，matches the URL and returns the value of the view or error.  
        """Does the request dispatching.  Matches the URL and returns the 
        return value of the view or error handler.  This does not have to 
        be a response object.  In order to convert the return value to a 
        proper response object, call :func:`make_response`. 

        .. versionchanged:: 0.7 
           This no longer does the exception handling, this code was 
           moved to the new :meth:`full_dispatch_request`. 
        """  
        req = _request_ctx_stack.top.request  
        if req.routing_exception is not None:  
            self.raise_routing_exception(req)  
        rule = req.url_rule  
        # if we provide automatic options for this URL and the  
        # request came with the OPTIONS method, reply automatically  
        if getattr(rule, 'provide_automatic_options', False) \  
           and req.method == 'OPTIONS':  
            return self.make_default_options_response()  
        # otherwise dispatch to the handler for that endpoint  
        return self.view_functions[rule.endpoint](**req.view_args)   #最终进入view_functions，取出url对应的视图函数的返回值

req = _request_ctx_stack.top.request 可以暂时理解为，将请求对象赋值给req

这里先简单讲下，每个url进来以后，他都会对应一个view_function

另外说下view_functions 是一个字典形式，他的key和value的关系是endpoint ——> view function

所以每个有效的URL进来，都能找到他对应的视图函数view function，取得返回值并赋值给 rv

这时候，通过make_response函数，将刚才取得的 rv 生成响应，重新赋值response

再通过process_response功能主要是处理一个after_request的功能，比如你在请求后，要把数据库连接关闭等动作，和上面提到的before_request对应和类似。

之后再进行request_finished.send的处理，也是和socket处理有关，暂时不详细深入。

之后返回新的response对象

这里特别需要注意的是，make_response函数是一个非常重要的函数，他的作用是返回一个response_class的实例对象，也就是可以接受environ和start_reponse两个参数的对象

1. 返回wsgi_app 内部

当response从刚刚的full_dispatch_request功能返回之后，函数会对这个response加上environ, start_response的参数并返回给Gunicorn

至此，一个HTTP从请求到响应的流程就完毕了.

六款比较不错的特殊文本格式处理库

1.tablib

2.openpyxl 算是xlwt xlrd的替代品

3.unoconv

4.pypdf2

5.mistune

6.csvkit 命令行工具

三百台服务器 如何进行管理

1.设定跳板机 使用统一的账户登陆 便于安全与登陆的考量

2.使用salt、ansible、puppet 进行系统的统一调度与配置统一的管理

3.建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录

rabbitMQ 也就是消息队列中间件，消息中间件是在消息的传息过程中保存消息的容器

• 使用像pyflakes 这样的静态代码分析工具
• 选定一个特定的代码风格
• 开发工具保存高响应速度
• 找到合适的编辑器
• 感到舒服和更有效率的工具值得花钱