匿名：你喜欢上级怎样的管理风格？
残剑：个人比较喜欢的上级一般是这样：对事不对人，在领导面前能够勇于替下属承担责任，而不是推卸责任；能够知道自己不足，会将自己不专业的事情交给下属去安排，而自己主要把控进度；知人，了解手下每一个员工所具有的能力，尽量做到合理的分配任务；不吹牛，真实的将一些事情告知团队里的成员。
初创公司的人员一般都比较少，有些问题不必逐级式的询问，直接了当的咨询负责人，对于问题的处理都有效率。而对于工作任务的安排，我比较认同逐级式的分配，采用逐级负责的管理方式（员工只对上级负责，而不对上级的上级负责，上级对员工和自己的上级负责），否则的话底层员工根本不知道该去做什么。
匿名：你希望加入一个怎样的团队？
残剑：团队里的每个成员都有自己熟悉的领域，但都不满足于此，有很强的求知欲，积极去了解自己未知的领域。当学习到某项东西的时候，乐意拿出来同其他人分享，和大家一起探讨改进的方法。当彼此有了更多的了解（做技术的人更容易从技术上去了解一个人，慢慢地变成欣赏），交流也会变得更加顺畅，团队的氛围也会变得其乐融融。
匿名：对于什么样的工作安排，你认为是不合理的？
残剑：在自己不了解某项领域工作的时候，按照自己的想法去安排工作是不合理的。在这种情况下，往往会把事情看得很简单，而且不明白公司拥有的技术能力，从而错误的评估开发时间。
匿名：怎么看待高强度、高压力的工作？
残剑：高强度、高压力对于初创公司的员工还是很有必要的，这些东西对于他们来说是兴奋剂，会给他们创造更多的挑战和机遇。如果一个人已经惧怕这种工作，还是趁早离开团队比较好，而且他们的离开也不会给公司带来什么巨大的损失。
匿名：如何看待加班？
残剑：加班不是每天必需的，视情况而定。当某一项事务紧急的时候，大部分人员都会自觉的去加班，因为这些毕竟是自己的职责所在。硬性加班的话，公司往往控制不了员工所做的事情，当人们一旦有排斥心理的时候，只会对着干。而且加班需要一种氛围，氛围不对的话，即便人在公司，做的最多的还是干其它的事情。
匿名：当上级没有及时对你的问题作出反应时，你会如何处理？
残剑：如果是重要问题的话，我一般会以邮件的方式发出，然后知会上级及上级的上级（有朋友或许会认为这是用上级的上级压上级，其实不是，这只是告知相关人员事态的严重程度），这种情况下一般都能够得到回复。一般问题的话，我会在bug问题单的后面添加备注说明（这样可以做到有据可查），同时也知会相关的人员让他们跟踪这个问题，一段时间内没有得到回复的话，会以私人交流或群组交流的方式再次通知一声。
匿名：开发人员应如何处理一个bug？
残剑：很多时候，其它的一些问题（客户端、服务器方面）我会被设置成“跟踪者”，邮件收到通知的时候我偶尔也会链接过去看看，发现除了问题描述没有其它任何描述性的东西（遇到的难点，引发问题的根源，解决问题的方法）。这种做法我是很不认同的，给我的感觉是“一个问题稀里糊涂地被解决了”。对于后来者，如果遇到相同的问题可能需要重新去重复一遍解决问题的步骤，这样耗费的是不必要花费的时间。
匿名：如何面对新的技术及软件架构重建？
残剑：我不太喜欢公司的产品或者软件去追求新的技术，因为新的东西层出不穷，是很难追到头的，而且新的东西并不一定稳定。很多东西还不如在现有的基础上改进，这样产品或软件可能变得更稳定，更受客户喜欢。
我也不太喜欢老是提软件架构的重建。既然产品已经开发出来，而且又经历了那么长的时间，开发者肯定是用心在改进架构，很多设计必然有它存在的理由。在产品没有遇到瓶颈的时候，何必去浪费那个时间和精力，为什么不把有限的东西花到更有价值的事情上呢。更多需要的是市场去验证这个产品，而不是想着重建架构，如果市场不认同这个产品，软件重新架构7、8次又有什么用呢？重建软件架构的代价是巨大，希望当局者深思。
匿名：对于初创公司，你觉得应该招聘什么样的员工？
残剑：公司很多时候会担心招进的新人员会离职，往往会招聘一些能力一般的员工。其实无论能力怎么样，只要不认同观念或者不满意某些东西的时候，都会选择离开。能力一般的人他会待的久一些（为离开需要准备长点的时间），但这种久对于初创公司来说根本没有好处，不会带来什么有价值的东西。所以我更倾向于能力高的优秀员工，如果他认同了公司的产品、理念，就会选择留下来，他们的持久性更长。
尤其当一个核心人员要离开的时候，一个水平一般的员工并不能很快的接收那些模块，这对于初创公司来说损失是巨大的。而招聘一个优秀员工的话，可能很快能够上手现有的东西，做得也有可能更好。
匿名：如何培养一个新人？
残剑：从初创公司的角度考虑，希望一个新员工能够立马体现他的价值，为公司开发新项目或者是处理老项目的遗留问题。但我非常反对招进一个新人就立马让他去做某个项目，有如下理由：1、对现有的系统不够了解，可能会给系统引进一些不必要的bug；2、对新人的具体能力、意向还不够了解。
唯一的例外是招到那种在公司所做领域有丰富经验的人，且他有留下来为公司服务的意向，否则某天发现有更好的机会，拍拍屁股走人了，接手的人又要从头开始，即费时间又费金钱。
个人比较认同的做法是——1、介绍整个系统的架构，让新员工在整体上有个初步的认识；2、细化系统的模块，使用一些简单的示例让他们入手，每个模块逐一学习；3、将每个模块整合在一起，系统性的学习。按照这种步骤做下来的话，新员工会对整个系统架构比较的了解。
匿名：对于产品，你有什么样的看法？
残剑：初创公司在做一个产品的时候，肯定是理论上认为在这方面有市场，而实际情况是不一定。所以我认为应该做出一个基本的产品（可能它本身还存在很多的bug），然后拿到市场上试验（给可能的目标用户试用），从客户的反馈上我们完全可以看出一个产品是否受欢迎（如果很多人说好，那大部分情况应该是在敷衍；如果提供了很多的反馈问题，那应该是他们比较喜欢用这款产品，希望它有所改进）。如果得不到市场的认可，就应该立马抛弃它，然后开始新产品的研发、试验。