Java企业级面试题总结-3
*需求分析
你如何对需求原型进行理解和拆分
产品策划、产品功能调研、绘制流程图和原型图、搜集产品部门内部意见、UI设计、研发评审、测试评审、研发阶段、测试阶段、上线
说说你对功能性需求的理解
用户需求
是从某一类用户的视角看他使用这个软件的需求。比如，作为用户你用淘宝，找东西，拍货，付款，你有怎样的需求。作为卖家，你用淘宝怎么收款，发货，管理订单。这就是一个个的 use case 或者 user story。 所以写 user story ， 开头第一句就是 As a xxx. 这都是从个人视角去看需求的。
业务需求
你整理完不同视角的需求，就要一个更高层面，更全局话的角度看需求。就要把这些需求串联起来。特别是把全局的流程梳理出来。从个人角度，是看不到全局的流程的。但是要想把业务梳理清楚，特别是数据流。就需要这种全局视角下的梳理。我们才清楚 use case/user story 是在什么场景下。 特别是有时候，不同的用户的需求可能存在冲突。通过这种全局性的业务需求梳理，可以去发现潜在冲突，并平衡需求。
功能需求
就是把具体的用户需求，变成软件的功能要求。比如客户要把交通事故照片通过 APP 发给保险公司。这是用户需求。 那么功能需求就是在这个模块下，要具有提交报险事故照片功能，上传现场照片。如果再具体下去，就是界面交互图。现在互联网公司一提产品管理，需求设计，基本就是 UX。需求过于碎片化。
说说你对非功能性需求的理解
非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。包括安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性。
你针对产品提出哪些交互和改进意见
过度追求精准
死板遵循设计法则
过度假设用户行为
你如何理解用户痛点
我们平常在做产品的时候，我们用户提出一个需求，他们想要一个直播功能，在用户提出这个需求的时候我们分析的是用户为什么想要直播这个功能，我们分析的正是用户的痛点。那么什么是痛点，痛点就是我们用户急切想要做的事。
比如我们产品做的是一个电商平台，我们通过几次渠道运营或者营销推广以后，吸引进来的用户大多都会搜索母婴相关的产品，但因为平台没有母婴相关的产品，吸引进来的用户大多都因此流失，其实我们吸引进来的大多用户都希望在本平台能买到母婴产品，但我们平台却没有相关的产品，这就是我们用户的痛点，所以我们赶快要上新跟母婴相关的产品。
再比如我们做的是健身方面的产品，在我们的产品里面有活动、动作库、健身计划、健身操、健身饮食五个模块，但我们70%以上的用户每当打开APP的时候都会点开动作库模块，但我们的动作库模块却放在了不太方便用户操作的地方，发现这个情况以后，我们分析到我们用户使用我们APP的痛点其实就是想学习健身动作，那我们就要将动作库这个模块当做为我们产品的重点来打造，对里面的内容也需要做更优质的优化。
设计能力
说说你在项目中使用过的 UML 图
你如何考虑组件化
组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，主要目的就是 减少耦合。
一个独立的组件可以是一个软件包、WEB 服务、WEB 资源或者是封装了一些函数的模块。这样，独立出来的组件可以单独维护和升级而不会影响到其他的组件。
你如何考虑服务化
集中式与分布式
要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。
集中式
集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。
集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。
分布式
分布式就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
拿电商网站来说，我们一般把一个电商网站横向拆分成商品模块、订单模块、购物车模块、消息模块、支付模块等。然后我们把不同的模块部署到不同的机器上，各个模块之间通过远程服务调用(RPC)等方式进行通信。以一个分布式的系统对外提供服务。
服务化
提到分布式，一个不得不提的词就是服务化，服务化架构使搭建分布式系统成为了可能。
传统的软件开发面临着很多的问题，比如： 代码重复率高、代码庞大难以维护、无法快速迭代、测试成本高、可伸缩性差、可靠性差、模块间高度依赖。为了解决上面这些问题，我们一般采用拆分、解耦、分层、独立等方式来解决。有了服务化架构，我们就可以在很大程度上解决这些问题。
服务化是一种粗粒度、松耦合的以服务为中心的架构，服务之间通过定义明确的协议和接口进行通信。
这里说到的“服务”，本质上来说，就是指“RPC”。单纯的RPC功能实现，其实很简单，无非就是client发起调用，中间某个组件（甚至就是client本身）拦截调用信息，序列化后将信息传输到server端，server端收到调用请求后反序列化，根据请求详细发起实际调用后返回响应传输回给client端。这样的RPC很常见，比如常见的存储过程调用就是一例。但是在一个复杂的业务环境，如何管理和协同这些大量的RPC才是最麻烦的事情。所以，一般提到的“服务化”更多指的是对RPC的管理。服务化一般关注服务注册，服务协调，服务可用性，服务通讯协议和内容交换等。
说说概要设计
概要设计是一个设计师根据用户交互过程和用户需求来形成交互框架和视觉框架的过程，其结果往往以反映交互控件布置、界面元素分组以及界面整体板式的页面框架图的形式来呈现。这是一个在用户研究和设计之间架起桥梁，使用户研究和设计无缝结合，将对用户目标与需求转换成具体界面设计解决方案的重要阶段。
概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型，与计算机无关。
*业务工程
你系统中的前后端分离是如何做的
纯粹的前端，js框架；
后端代码java或php等；
数据库相对独立mysql、nosql等；
独立缓存服务等
说说你的开发流程
一、开发流程图
为使流程更清晰，本图省略了各环节的评审，如有更好的表现形式，欢迎提出建议。
二、过程产物及要求
本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。
项目启动阶段
产物名称成果描述负责人
调研文档了解项目背景，了解项目干系人目标方向产品经理
团队组建确认团队人员及配置产品总监
业务梳理明确项目的目标、角色、各端口及模块产品经理
需求阶段
产品原型产品的线框图产品经理
需求概要基于线框图，作技术评估，达成业务理解的一致性研发工程师
项目里程碑确认项目重大时间节点研发项目 经理
项目开发计划梳理各阶段、各端口的开发计划研发项目经理
项目任务分解表将计划分配到团队研发项目经理
设计阶段
界面效果图及标注基于线框图，作效果图，须适量考虑交互内容UI设计师
UI设计规范在UI界面基础上，输出主要界面的设计规范UI设计师
需求规格基于效果图，明确业务实现细节，消除对最终成果理解的不一致研发工程师
概要设计功能实现的可视化，有助于理清思路，减少技术盲区和低级缺陷，实现并行开发，提高效率研发工程师
通讯协议通信协议是指双方实体完成通信或服务所必须遵循的规则和约定研发工程师
表结构设计确认要建的数据库表及其表结构研发工程师
开发阶段
产品代码代码
测试阶段
测试用例明确测试方案，包括测试模块、步骤、预期测试工程师
测试结果报告输出测试结果测试工程师
用户手册系统操作手册测试工程师
常规文档
项目周报每周开发内容及下周开发计划研发项目经理
测试周报每周测试内容及下周测试计划测试工程师
评审会议纪要评审的过程文档整体团队
三、过程说明
项目启动
产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。
公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。
明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》；从项目启动起，研发项目经理每周提供《项目研发周报》；测试阶段，测试工程师每周提供《项目测试周报》。
产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。
产品经理完成《业务梳理》。首先，明确每个项目的目标；其次，梳理项目涉及的角色；再来，每个角色要进行的事项；最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。
需求阶段
进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。
产品经理面向整个团队，进行需求的讲解。
研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。
研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。
设计阶段
UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。
研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。
研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。
开发阶段
研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。
编码过程一般还需进行服务端和移动端的联调等。
完成编码后需要进行功能评审。
测试阶段
测试工程师按阶段设计《测试实例》，未通过的流程测试提交至Jira，分配给相应的开发人员调整。
研发工程师根据测试结果修改代码，完成后提交测试，测试通过后完成。
测试工程师编写《测试结果报告》，包括功能测试结果、压力测试结果等。
测试工程师编写系统各端口的《操作手册》、维护手册等。
系统上线
与客户或者上级达成一致后，系统进行试运行，稳定后上线。
最后，以上内容仅限于我所在公司，不代表绝对专业意见，不知道其他行业的IT小伙伴和我们是否一样呢，欢迎与我交流
你和团队是如何沟通的
主动协商、善于表扬
你如何进行代码评审
选用合适的工具。我用过 Phabricator、Gerrit、Gitlab 来 review 代码。这里推荐使用 Phabricator，就不过多介绍了，可以看 这里 的讨论。
每次只 Review 少量代码。新人经常犯的一个错误，花了两周甚至更多的时间写代码，然后又花了一些时间做测试，等他们自己觉得“大功告成”才敢自信地提交 review，殊不知，这个时候提交的 review 几乎没有什么意义。一方面，对于提交 review 的工程师来说，辛辛苦苦开发测试了两三周，就等 review 完成后 release 了，这时候如果收到各种需要修改代码的意见，心里难免会有抵触情绪，尤其是 review 的结果是架构需要改动，代码需要大面积重写，内心一定是崩溃的。另一方面，代码审查者如果面对数千甚至上万行代码，需要理清项目架构都需要花费大量时间，强行 review 这种代码，争论、修改、测试代码，很可能 一周甚至更长时间都完成不了 review，结果就是双方都痛苦不堪。在实践过程中，我们认为，频繁 review 代码并且每次只 review 少量代码非常重要，我自己认为 reivew 不超过 500 行代码比较好。
明确职责。 Review 过程中经常遇到的一个问题是 review 响应不及时。比如 assgin 给了工程师，工程师没有及时 Review，或者提交 review 的工程师没有及时响应修改意见。造成这种现象的原因大致有这么几种：工程师没有及时处理 review 的习惯；review 工程师需要项目的领域知识等。解决方法也很简单，Review 是项目开发的一部分，进度由开发工程师来负责，这样，Code Review 如果不顺利，应该由提交代码的工程师负责推动，如果需要讲解代码，提交代码的工程师应该主动走到 reviewer 工位上，说说背景知识和代码逻辑。也就是说，如果沟通受阻，工程师应该更积极的面对 reviewer ，毕竟大家是在花自己的时间来帮助他。
整理 checklist。如果你回顾犯过的编程错误就会发现，在某个阶段自己容易犯类似的错误。其实上，团队里的工程师也有这种情况。刚入门的工程师会出现 API 误用；刚加入团队的工程师对编码规范需要一段时间来适应；有些工程师在代码命名上总会犯同样的错误；也有一些工程师搞不清楚并发编程；还有工程师甚至常常写面条式的代码而不自知。如果每位工程师有自己的 checklist 来记录这些问题，定期回顾自己是不是还在犯类似的错误，他们的水平就会很快提高，至少不容易重复已经犯过的错误。同样，团队也需要积累 Code Review 的 checklist，刚开始，这个 list 可能非常初级，会有一些常见的 bad small，甚至代码规范的内容。不过没关系，相信随着团队成员能力的提升，这个 list 慢慢会集中在设计方面，比如编写代码的工程师有没有考虑到代码可维护性、扩展性和性能等等。
完善CI/CD设施。很多团队不愿意做 Code Review，其实和不愿意做单元测试、集成测试原因一样，这些团队的CI/CD 工具不成熟，每增加一个不直接产出“功能代码”的步骤就会增加工作负担。其实根本原因是工程效率工具的缺失。
培养工程师的能力。还有一个比较常见问题是，有些新人面对被 review 代码往往提不出问题。这个时候就需要工程师提升自己的能力。如果平时有积累，面对等待 review 的代码，即使不能面面俱到，也能提供不少有价值的意见，比如整理学习 Restful API 知识，在评审 Http 接口代码时就会是专家；掌握了 Spring 框架，Guava 等工具类，也能在很多时候提出很好的建议。慢慢地积累更多经验后，这些工程师就能提出更多业务、设计方面的意见。
说说你对技术与业务的理解
技术最终都是服务于业务
说说你在项目中经常遇到的 Exception
ublic ArithmeticException(String s)构造具有指定详细消息的 ArithmeticException
public class AnnotationTypeMismatchExceptionextends RuntimeException若某个注释的类型在对该注释进行编译（或序列化）后发生了更改，而程序试图访问该注释的元素时，抛出此异常。
public class CannotRedoExceptionextends RuntimeException当 UndoableEdit 被通知 redo() 但无法执行时抛出。
public class CannotUndoExceptionextends RuntimeException当 UndoableEdit 被通知 undo() 但无法执行时抛出。
public class EventExceptionextends RuntimeException事件操作可以像在其方法描述中指定的那样抛出 EventException。
说说你在项目中遇到感觉最难Bug，怎么解决的
说说你在项目中遇到印象最深困难，怎么解决的
查资料，问同事
你觉得你们项目还有哪些不足的地方
你是否遇到过 CPU 100%，如何排查与解决
定位高负载进程 pid
首先登录到服务器使用top命令确认服务器的具体情况，根据具体情况再进行分析判断。
通过观察load average，以及负载评判标准（8核），可以确认服务器存在负载较高的情况；
观察各个进程资源使用情况，可以看出进程id为682的进程，有着较高的CPU占比
2.2 定位具体的异常业务
这里咱们可以使用 pwdx 命令根据 pid 找到业务进程路径，进而定位到负责人和项目：
可得出结论：该进程对应的就是数据平台的web服务。
2.3 定位异常线程及具体代码行
传统的方案一般是4步：
top oder by with P：1040 // 首先按进程负载排序找到 maxLoad(pid)
top -Hp 进程PID：1073 // 找到相关负载 线程PID
printf “0x%x\n”线程PID： 0x431 // 将线程PID转换为 16进制，为后面查找 jstack 日志做准备
jstack 进程PID | vim +/十六进制线程PID - // 例如：jstack 1040|vim +/0x431 -
但是对于线上问题定位来说，分秒必争，上面的 4 步还是太繁琐耗时了，之前介绍过淘宝的oldratlee 同学就将上面的流程封装为了一个工具：show-busy-java-threads.sh，可以很方便的定位线上的这类问题：
可得出结论：是系统中一个时间工具类方法的执行cpu占比较高，定位到具体方法后，查看代码逻辑是否存在性能问题。
※ 如果线上问题比较紧急，可以省略 2.1、2.2 直接执行 2.3，这里从多角度剖析只是为了给大家呈现一个完整的分析思路。
3、根因分析
经过前面的分析与排查，最终定位到一个时间工具类的问题，造成了服务器负载以及cpu使用率的过高。
异常方法逻辑：是把时间戳转成对应的具体的日期时间格式；
上层调用：计算当天凌晨至当前时间所有秒数，转化成对应的格式放入到set中返回结果；
逻辑层：对应的是数据平台实时报表的查询逻辑，实时报表会按照固定的时间间隔来，并且在一次查询中有多次（n次）方法调用。
那么可以得到结论，如果现在时间是当天上午10点，一次查询的计算次数就是 106060n次=36,000n次计算，而且随着时间增长，越接近午夜单次查询次数会线性增加。由于实时查询、实时报警等模块大量的查询请求都需要多次调用该方法，导致了大量CPU资源的占用与浪费。
4、解决方案
定位到问题之后，首先考虑是要减少计算次数，优化异常方法。排查后发现，在逻辑层使用时，并没有使用该方法返回的set集合中的内容，而是简单的用set的size数值。确认逻辑后，通过新方法简化计算（当前秒数-当天凌晨的秒数），替换调用的方法，解决计算过多的问题。上线后观察服务器负载和cpu使用率，对比异常时间段下降了30倍，恢复至正常状态，至此该问题得已解决。
你是否遇到过内存 OOM，如何排查与解决
首先，要搞清OOM的分类：
OMM主要三类： permgen OOM , heap OOM, stack overflow
permgen OOM: 这个主要是由于加载的类太多，或者反射的类太多， 还有 调用 String.intend（jdk7之前）也会造成这个问题。所以出现了这个问题，就检查这三个方面；
heap OOM： 基本是按照 1楼的方式就可以解决了，主要是因为一些无用对象没有及时释放造成的，检查代码加上 heap dump 去分析吧
stack overflow： 这个主要是由于调用层数，或者递归深度太大造成的，看异常信息，基本上就能定位得出来了
把内存大户找出来。
- 可通过命令定期抓取heap dump 或者 启动参数OOM时 自动抓取heap dump
- 通过对比多个heap dump，以及heap dump的内容，找出内存大户
- 分析占用的内存对象，是否是因为错误导致的内存未及时释放，或者 数据过多导致的内存溢出
- 根据原因，fix bug 或者 修改方案
堆/Heap
JVM管理的内存叫堆；在32Bit操作系统上有4G的限制，一般来说Windows下为2G，而Linux 下为3G；64Bit的就没有这个限制。
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。
JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以由 -XX:MinHeapFreeRatio=指定。
默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以由 -XX:MaxHeapFreeRatio=指定。
服务器一般设置-Xms、-Xmx相等以避免在每次GC后调整堆的大小，所以上面的两个参数没啥用。
分代/堆模型
分代是Java垃圾收集的一大亮点，根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，可以扬长避短。可参考如下的模型图：
GC的类型
当每个代满了之后都会自动促发collection，各收集器触发的条件不一样，当然也可以通过一些参数进行强制设定。主要分为两种类型：
Minor Collection：GC用较高的频率对young进行扫描和回收，采用复制算法。
Major Collection：同时对Young和Old进行内存收集，也叫Full GC；因为成本关系对Old的检查回收频率要比Young低很多，采用标记清除/标记整理算法。可以通过调用代码System.gc()引发major collection，使用-XX:+DisableExplicitGC禁止它，或设为CMS并发 -XX:+ExplicitGCInvokesConcurrent。
更为具体的阐述如下：
由于年轻代进进出出的人多而频繁，所以年轻代的GC也就频繁一点，但涉及范围也就年轻代这点弹丸之地内的对象，其特点就是少量，多次，但快速，称之为 Minor Collection。当年轻代的内存使用达到一定的阀值时，Minor Collection就被触发，Eden及某一Survior space（from space）之内存活的的对象被移到另一个空的Survior space（to space）中，然后from space和to space角色对调。当一个对象在两个survivor space之间移动过一定次数（达到预设的阀值）时，它就足够old了，够资格呆在年老代了。当然，如果survivor space比较小不足以容下所有live objects时，部分live objects也会直接晋升到年老代。
Survior spaces可以看作是Eden和年老代之间的缓冲，通过该缓冲可以检验一个对象生命周期是否足够的长，因为某些对象虽然逃过了一次Minor Collection，并不能说明其生命周期足够长，说不定在下一次Minor Collection之前就挂了。这样一定程度上确保了进入年老代的对象是货真价实的，减少了年老代空间使用的增长速度，也就降低年老代GC的频率。
当年老代或者永久代的内存使用达到一定阀值时，一次基于所有代的GC就触发了，其特定是涉及范围广（量大），耗费的时间相对较长（较慢），但是频率比较低（次数少），称之为Major Collection(Full Collection)。通常，首先使用针对年轻代的GC算法进行年轻代的GC，然后使用针对年老代的GC算法对年老代和永久代进行GC。
调优总结
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
并发垃圾收集信息
持久代并发收集次数
传统GC信息
花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间，一般会提高应用的效率
吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
说说你对敏捷开发的实践
敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。
Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。
我们可以简单的对比一下Scrum和XP：
- 在开发的过程中，你可以采用Scrum方式也可以采用XP方式；
- Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。
敏捷开发宣言
《敏捷宣言》
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者
敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。
敏捷开发十二原则
在敏捷开发中，我们遵循以下准则：
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
说说你对开发运维的实践
介绍下工作中的一个对自己最有价值的项目，以及在这个过程中的角色
本项目是基于Tomcat服务器开发,使用Eclipse开发工具,系统分采用Mysql数 据库服务器，利用Solr全文检索，实现关键字搜索功能，利用ajax将数据传 递到页面、调用第三方支付接口实现下单，购买功能。
主要职责：
负责数据库构建、搜索功能模块、后期项目测试。
说说你最熟悉的一个项目
出售课程网站-旅拍微课商城
*软实力
说说你的亮点
说说你最近在看什么书
淘宝这十年
说说你觉得最有意义的技术书籍
说说个人发展方向方面的思考
说说你认为的服务端开发工程师应该具备哪些能力
开发技术，行业知识，思维能力
说说你认为的架构师是什么样的，架构师主要做什么
一般来说，应用架构师负责构建一个以解决特定问题为目标的软件应用的内部结合结构，一般以满足各种功能性需求以及维护性需求为设计考虑目标；系统架构师则提供运营支撑软件应用的信息系统的结构设计，一般以满足各种非功能性需求或运营性需求为设计目标（如安全性、可伸缩性、可互操作性等等）；企业架构师，就不光只顾IT系统的架构了，他应以企业的持续经营目标为考虑要素来构建企业所需要的内在结构设计；基础设施架构师以及其他架构师职责也大体如此。
当然，现实中的架构师往往会身兼数职，而不仅仅是构思架构本身。比如，大部分软件架构师也会组织软件团队、进行一些相关研究，甚至担负一些行政管理的工作，就不再延伸赘述。
说说你所理解的技术专家
*人力面
你为什么离开之前的公司
首先非常感谢之前的公司，氛围很好，但是缺乏上升空间，与个人职业规划不吻合，
你为什么要进我们公司
首先自身具备一定技术，相信自己能胜任这份工作
其次贵公司发展前景很好，听说氛围也不错，个人很感兴趣
说说职业规划
作为一个新人，刚进入公司，我会熟悉公司的企业文化，很好地融入到整个团队之中，完成好领导布置给我的任务，踏踏实实从基础做起，强化我的编程技术。
你如何看待加班问题
“我觉得如果是工作时间效率不高，或者出错造成的加班，理所应当。但我也会尽可能提高自己的效率，避免这种现象发生。如果公司有临时状况，需要我加班，我也会义不容辞，我现在还没有家庭负担，加班对我来说，不是太大问题。”
谈一谈你的一次失败经历
你觉得你最大的优点是什么
你觉得你最大的缺点是什么
你在工作之余做什么事情
看新闻，运动
你为什么认为你适合这个职位
你觉得自己那方面能力最急需提高
你来我们公司最希望得到什么
1，想让自己的能力得到公司的认可，让我更好的定位自己。
2，公司的企业文化和理念，与我的理想很契合
3、我也想通过自身能力的提高，在工作这个平台上，让公司获益
你希望从这份工作中获得什么
报酬，经验积累
你对现在应聘的职位有什么了解
您还有什么想问的
你怎么看待自己的职业生涯
谈谈你的家庭情况
你有什么业余爱好
运动
你计划在公司工作多久
看情况，不出意外不走
你如何看待目前程序员频繁跳槽这件事？
要是在公司有好的领导好的团队好的报酬就不会跳槽了吧
你曾经工作中，你认为最困难的是什么？你又如何解决的？花了多少时间？