因为手机安装 app 和上缴手机号是大部分产品的天字第一号 kpi 。

调试看语言，有很多 linux 的 IDE 都支持 debug 模式。
git 同样也有 IDE 插件支持，或者 smartgit gitg 之类的都可以。

linux 下的开发主要收益是 shell 对不同软件操作的集成成本极低，只要一个操作可以在 shell 里面写出来，就可以将其与其它操作组合起来写成一个批处理脚本做自动化。
比如提交时代码拉取最新分支并同步到本地，然后提交。

在 windows 下很多 IDE 的集成做得比 linux 好，但是大多是同一个软件内的集成，而 linux 的优势就是不同软件基本都暴露了命令行的操作支持，可以很方便的做跨软件的集成。

说明在短时间内考核一个候选人的能力最有效的方式就是问这些问题了。

面试官的目的并不是发掘出候选人的所有潜能，而是在有效时间内筛选出能胜任岗位需求且有意愿入职的候选人。
筛选效果的评判标准是通过率和入职合格率在可接受范围内。
所以筛选的手段只是尽可能划出一个通用的及格线，至于入职之后用什么技能，和面试题目根本没有太大的关系。
候选人基数大，岗位少，筛选难度高。
候选人基数小，岗位多，筛选难度低。

赶上招聘岗位对应的面试官比例不足，还会开拓出异步方案，先做一轮笔试题，笔试题的难度也类似。

换个角度去考虑问题，如何节省成本
规范是为了节省成本的，什么时候技术债成本高到要用规范来减少成本，就什么时候把规范推广开。
减少开发人员调试的反馈周期，能大幅减少开发周期降低成本，那么这些规范里面有什么是可以降低开发反馈周期的，可以优先做，如果加上规范反而让本地调试成本更高，周期更高了，要重新评估是不是有简化方案，还是不适合在这个时候添加对应的规范。
重构也是为了节省成本，当技术债务过高，达到了 重构 + 新功能 > 在原有架构上写新功能的时候，就是一个很好的重构时间节点。

@john990
a5.net

纯卖营收看领域，大致就是 1 楼说的 *3~5

更准确的报价可以上 A5 看价格
不止营收的钱，用户流量也要算到估值里

整套网站的价值套利分好几层
1. 导流到的 app，对应业务或者其它转换的 app 均可，app 又可以卖一波
2. 导流到相关领域的网站
3. 流量套完可以考虑再到 a5 卖给下家

go 现有的机制决定了，如果要做到 spring 的语法糖表达能力，只能靠编译生成解决，java 想要的工程约束，在 go 的体系里面全都很难做，要从造 IDE 和增加代码生成开始做。
当选择了增加语法糖压缩代码信息量这条路，就意味着这个框架有了自己的语法，框架的使用者必须顺着设计者的思路去看文档，才能弄清楚代码会怎么执行。实际上就和业务框架要不要使用 ORM 一样，是只学一套标准的 sql 表达式，还是去另外学一套生成 sql 的表达式。实际开发过程做遇到问题，哪种更好调试。

我很少看到 java 栈的开发喜欢上 go，因为相比 java 而言 go 太简陋了，语法表达能力太弱了，此外还有 java 栈内一切皆对象的理念，在 go 这种缺少对象、继承，仅有组合机制的语言而言，描述业务的思路都变得不一样了。

在我看来，两种语言的差异是
java 栈的开发都可以造一套自己习惯的语法糖范式，熟悉之后可以加快开发效率，维护的人需要了解新的语法糖，上手和维护成本高了。
但是 go 里面造语法糖不方便，所以大部分人都可以基于基本语法抽象业务，开发效率不高，但代码直白，上手和维护成本低一些。

这个面试报告能不能卖给求职者投递的公司，或者求职者要投递的公司是不是认可这个面试结论。

jobDeer 的运营成本太高了
重点是挖掘在职人员的评级频次，基于求职阶段的人再拉升撮合面试的频率，基数太少了。

大部分人可以在职面试，评估能力等级，两三年后，积累下来的面试 /评级记录，已经是一笔很大的财富了。
这一部分面试评估一定要向候选人收费，否则无法补贴面试官的支出。

@kop1989
所以市场缺少解决这几个问题的方案
鉴别候选人的能力
帮助候选人提升技能的体系

这两在大厂是毫无问题的，因为它们都是成建制的导师+技能等级评估体系
类似候选人说自己从阿里出来前，评级是 P7， 那大部分企业都会信任这个评级结论，这将大幅减少招聘的成本。

市场上缺少一个类似的体系做这些大厂才做的事情，这其中最重要的评级面试官和教练，完全可以靠共享人力资源解决，深入挖掘各个大厂的教练和面试官的业余时间，让他们的技能通过这类的平台变现。

我很早之前就困惑，市场上为什么没有做共享面试官和付费在职职称评估的产品。
让公司可以直接看到公共的面试结果
也可以拉高在职员工的面试频次，或者对接教练做在职培训推荐

这样在职员工就可以每年面试一两次看看市场机会了。

模式无非是提供一些公司认可的面试官，这些面试官提供面试评估卖给普通公司，减少筛选简历和一面的人力成本。

另外就是教练体系，可以是培训任何领域技能的，顺着评估结果去推荐培训课程和考核。
国外很多大厂都有成套的等级评估和职称评估，类似思科，微软都有。
私下的教练倒是有一些，有些高级程序员自己开课，就是定期提供一些技能提升方向和考核，考核过的话，教练自己做为背书，给学员提供一个评级。

这些都是可以为从业人员和公司提供价值的业务，不知道为什么没有一家愿意做

这个问题我持续思考过好几年，至今没有完全定下来。
为此我想过以下事情：
评估自己想要的生活是什么
评估自己在定居的城市需要做什么工作，或者不工作
去体验一下对应城市的气候、餐饮、市场、生活节骤等与日常生活息息相关的细节

然后我做过这些事情：
去各个城市旅游，主要是吃东西和逛菜市场
加入各种本地社区了解城市的发展情况，就业机会

受限于工作时间，目前也只能覆盖省会+1 ～ 3 个次级城市的旅游
暂时的结论有几种

仍然继续工作而且要买房：广州、苏州、长沙
少工作或者不工作：珠海、昆明
纯养老：云南或者广东、福建沿海的某些城镇

中国太大，待考察的城市还有很多

这两个问题的共同诉求有两个
1. 数据有权限，终端的请求天然有身份，且不同身份对数据的权限不一样
2. 终端查询需要更强的自主性了，局限于服务端出固定结构的数据接口不能很好的解决问题

可以从这几个方向评估新的方案
1. 数据是否可以使用一套公共的权限方案，管理员可以看所有，个人只能看自己这类的
2. 是否要给所有的终端一套签发 token 的方案标识身份
3. 能否提供一套 DSL 查询方言给终端，让终端可以自主解决查询数据的几个问题，裁剪字段，联表等

仅靠 restful 之类的 API 设计方案解决不了终端日益膨胀的数据查询需求

@Macv1994
测试用例是根据业务写的，而不是根据功能边界写的。
生产环境的需要的业务都有测试用例覆盖，还有啥焦虑的，如果上线发现问题，说明存在测试用例没有覆盖的业务，补上就是了。

所以测试用例的写法更像用户手册，告诉别人这块的实现是解决什么业务的，会被怎么使用。

典型的缺少测试引入的问题
如果自己写了单元测试，划好改动范围并且测试用例覆盖了业务需求，就不会有这样的焦虑。

问的是业务问题，是公司的文档机制不完善吗，为什么业务问题不看文档要问人。如果是自己负责的业务，应该补全文档。
问的是技术问题，是提问人的技术视野问题吗，还是工作习惯问题，技术问题为什么没有尝试自己解决，应该推荐相关的书籍给提问者自学补上相关的知识盲区。
问的是调试报错，是开发框架查错机制不完善吗，为什么报的错误无法直接定位到相关的位置，尝试引入更好的查错机制+培训调试技能解决问题。

个人不要想着树回馈社区、推动社技术进步那么大的旗帜。

开源就简简单单做好这件事就够了，遇到一个问题，解决这个问题，让其他人能以更低的迁移成本使用你的解决方案。

做开源第三点尤为重要，它包括了，使用成本更低的 api，引导性很好的使用文档，合理的测试用例。及时响应 issue
做好了这些，star 通常会与解决问题的规模成正比增长。

不考虑解法，这三道题考察的是应届生水平。
初筛的标准可以猜测是：
1. 具备基本的 java 语法基础
2. 具备基本的 sql 查询和联表基础

可以说是很简单的题目了，考察到的知识点有这几个
1. java 的循环，双重循环，知道找规律，星号和空格的等差数列规则，知道从循环剥离计算规则和打印的处理封装估计会加分。
2. 知道查询的写法，知道 order by，知道 limit，知道子查询，知道如何优化子查询会加分
3. 知道联表的写法，知道 group by，知道子查询，知道如何优化联表会加分

大致就这些，这算是很务实的笔试题了，考察的都是基本知识点。