我真的遇到了这种公司...

[uuweZhou]

###背景就是我投简历过去,然后收到了回复,如下:

###我复制一个文本在下面:

首先非常抱歉没能及时回复您的邮件，我们有一些紧急的事情耽误了。为了更全面考察候选人的能力，我们设计了一套贴近实际项目的题目，如果可以的话，请您完成之后把结果按照要求回复给我；如果您不认同这种方式或者有其它原因的话，也请您告知一下我们。题目如下：

附件中是一个带本地 git 仓库的项目，虽然是一个 demo，但是在此我们理解为实际的 Rest Api 服务。在开发协作的过程中遇到了如下的问题需要对这个服务进行多次升级：

1. 开发对接过程中，前后端发现需要对接口传递的时间格式进行统一，讨论的结果是在这个项目中，不管是接口的输入还是输出凡是涉及到日期时间的地方，都采用 ISO 8601 compliant （例如 2010-01-01T12:00:00Z ）的格式进行传递。于是你考虑用一种比较优雅的并且方便后期所有服务端开发同学的方式去实现，甚至都不去改动现有的接口实现（ demo 中的/now）
2. 产品需要增加一个新的需求，提供一个无需登录的建议意见提交接口，需要用户提交的数据包括：姓名、电话、类型（意见或者建议）、内容，并且从数据统计来看，需要统计访问接口的来源，可能是不同的页面地址（可以跨域）通过接口提交的，也需要通过接口的 Cookie 追踪以及用户的真实 IP 来进行数据分析；从安全性角度来讲，为了避免恶意数据提交，产品提出我们假设相同 IP 或者相同 Cookie 都视为同一个用户，同一个用户一分钟之内只能提交一次（实际情况可能是可疑情况要求验证码，但是这个 demo 中不太好实现）。因此，除了用户输入的字段，你还要记录下调用接口的页面地址、用户的 Cookie、用户的 IP 地址、通过 IP 地址获取到的省和市。同时，运维同学表示，部署的实际环境中可能有多层的反向代理或者网关，这些反向代理都会按照标准反向代理的方式去传递 HTTP 头信息。为了实现这个需求，你需要引入数据库表设计并进行数据库版本管理、在项目中配置和使用数据库连接并且设计好接口最终可以提供给前端调用。
3. 项目进行过程中，前端同学觉得这样不行，后端需要提供一个接口文档。后端同学进行了调研并且讨论，觉得手动写文档并且每次变动都去更新太麻烦了，需要一个自动生成的方案，并且最终决定用 swagger-ui。你需要引入 swagger-ui，完成现有接口的文档，并且把文档的书写和使用方式反馈给整个团队。
4. 项目中并没有写任何的日志，运维同学反应，其实上线之后都会有日志收集系统，虽然线上不能直接 debug，但是出问题的时候可以通过日志查询来定位到问题。后端小伙伴们进行了一次讨论，觉得很有必要做这个事情，于是需要你给出一份书写日志的注意事项，并且按照这个规则给当前项目完善日志输出。
5. 为了提高质量，减少返工次数，团队决定必须有基本的测试，包括接口测试和业务逻辑测试，于是你开始在项目中增加单元测试的框架，实现现有代码的基本测试用例，并且告诉团队其他人在后续开发中怎样使用这个测试框架，往后的开发流程会做哪些优化。

题目存在不合理的地方请谅解，请按照你觉得最好的方式完成上述的迭代工作，最终需要的是一份基于 demo 的、已经提交过 commits （不需要 push ）的 git 代码库压缩包，若干你觉得有必要的文档，以及其他你认为有必要反馈给我们的信息。我们收到了不少优秀的简历，但是因为远程团队的特殊性，我们会根据整个过程中的细节进行探讨和评分，因此尽可能考虑全面，最终选择最合适我们团队的候选人。

多谢！

[weakish]

@murmur 我的理解是手写 swagger-ui, 由 swagger-ui 生成文档。看你的理解好像是根据 javadoc 甚至 java 代码自动生成 swagger-ui 的代码，如果是这样的话难度和其他题目不匹配。

面试题如果表意不清，你可以去问（转换成实际场景，就是明确需求分析），如果你觉得题目出的不合理，也可以提意见（转换成实际场景，就是负责架构的人或者小组讨论做的选择你觉得不合理，你觉得需要讨论）。

[weakish]

@murmur 那也是「贴近」，不是一样。真拿实际项目级别的 demo 出来面试人怎么可能（真要这样除非先给面试的人发一个月工资，否则面试的人根本承担不起做题的成本）。

[murmur]

@weakish

后端同学进行了调研并且讨论，觉得手动写文档并且每次变动都去更新太麻烦了，需要一个自动生成的方案

这不就是先开发后补文档么？手写 swagger-ui 就一个 xaml 纯打字的有什么地方可以做考点。。

[l00t]

@murmur 这个题是很贴近实际项目啊。从需求来源（产品，前端，运维，后端内部），到设计、开发、文档、测试，这些流程都贴近真实。但贴近又不是说完全和实际项目一致。有些场景是需要制造出来的嘛，不然你让它在哪一步特意写出日志的方案设计？真实开发中，完全没有日志输出几乎不可能，但倘若前期没有明确要求，那么各有各的不规则日志倒是很有可能。最后上线前按运维要求统一日志输出规范也算是很常见的吧？

[murmur]

@l00t 所以你认为这套题招的要么是架构师要么是团队负责人？

[isb]

@wdlth 这个公司居然还活着……没记错的话以前是做淘宝直通车的……

[k9982874]

虽然感觉怪怪的，但是他提的要求倒也没啥过分，没涉及到业务逻辑实现。

JAVA 做可能会挺花时间，如果 node.js 做 2 个小时可以搞定。

1、引入 moment 库，在 /now 接口做 format 转换。
2、跨域问题在 service 或 nginx 端配置 cors，nginx 反代时加 x-forwarded-for 头 service 读，拿到真实 IP 防刷就好弄了。
3、装 swagger for express 套件搞定
4、WinstonLogger、Log4JS 随便选一个，装上完事
5、装 mocha 完事

还不是太过分。

看介绍是远程工作，如果待遇能给到 3W+我是会给他弄一下。

[k9982874]

补充：第一点要求不改变接口实现，那就别用 moment 了，设置一下环境变量的时间格式。

[Felldeadbird]

这不是骗代码的面试。看了一下，5 点要求都很简单。

[1ychee]

我们公司之前招前端，也是出了一道基于实际需求而大幅简化的 DEMO 考题。

按照产品经理的意思，如果应聘者看到考题，觉得无从下手，那么也算是为双方省下了无谓的沟通；
如果应聘者的技能点正好是我们所需的，那么考题对他来说毫无难度，预计 2~3 个小时即可完成。

当时大概有 60 个左右的前端投简历，因为这道考题，直接吓跑了 50 个... （当然，最后很幸运的是我们还是找到了合适的人选，而且非常出色~）当时的考题在这里，大家也可以来看看：

现在外面那么套路，教求职者如何通过话术打动公司 HR。所以，对于公司来说，面试的时候，只靠语言沟通是很难让双方深入了解彼此的... 直接上手能让双方迅速知道彼此是否适合。如果你觉得无从下手的话，那么直接不开发就可以了，甚至都不需要回复邮件。

[weakish]

@murmur 没看到 demo 不好说。我怀疑是没有完善的 javadoc 的，否则前端可以直接参考 javadoc 开发。如果通过 Java 代码生成 xaml 那难度和其他题目都不一样。

后端暴露的接口是不是太多了？有些接口可能不必要写进 xaml 里（ xaml 是前后端之间的协议）。
具体的取舍需要综合考虑需求、兼容性（现有前端代码对后端接口的使用）、可维护性（应对未来需求的变更）。

这和下一题「书写日志的注意事项，... 按照这个规则」都是侧重设计上的取舍。

[66beta]

@1ychee 这图是贵公司产品做的，好感动、好羡慕！

[murmur]

@weakish 我后来想了一下，看了一下 70 楼的图，幡然醒悟，这面试题写太啰嗦了

为了实现这个需求，你需要引入数据库表设计并进行数据库版本管理、在项目中配置和使用数据库连接并且设计好接口最终可以提供给前端调用。

想了半天才明白这句话什么意思，原来是要把数据库的 powerdesginer 或者建表 sql 一起放到给的 git 里提交。。

[murmur]

@1ychee 碰巧这几个组件都做过，除了那个炫酷的开放试题，时间分配上、说明的准确度上毫无挑剔

[1ychee]

@murmur #74 谢谢~

我们也是想节约应聘者的时间，所以有一个最低要求，其他的话，当然是能做的越多越好咯~

@66beta #72 是不是被感动了？要不，来我们网站上来几发正版软件吧！ https://DIGITALYCHEE.taobao.com/

[weakish]

@murmur 70 楼的题是另一种风格，酷炫效果约束太少，实际项目中如果需求是「实现一个酷炫的效果」，那就是坑爹，因为你不知道对方心目中的「酷炫」到底是指什么。其他题则都框死了，只要考虑怎么实现就可以。

而这种「啰嗦」题目是另一种含混的风格。比如 70 楼第一题「按 Software_id 0-9a-Z 汉字首字母排序」，换成含混的风格就是「为了方便用户快速定位软件，需要按软件名称排个序」，至于具体是 0-9a-Z 还是 0-9A-z, 汉字是否和英文混排，要不要同时实现倒序的交互，那都留给实现的人去考虑。

然后这两种出题风格其实背后是两种不同风格的协作方式。
（当然也不排除一家公司实际工作用一种风格，但用另一种风格出题。）

第一种是按照定死的设计实现，有人负责设计，有人负责实现，这样界限很分明。

第二种是只有一个模糊的方向，实现的人需要自己做一些具体的决策，这样负责设计的人可以把注意力集中在大的设计方面，同时负责设计的人在一些细节领域的经验和信息可能不如具体的实现者，所以具体的实现者可能是最适合做局部的、细节的决策的人。

然后是牵涉到团队其他成员的工作，第一种风格，涉及到多人的选择和涉及到单人的是一样的，无非就是「一人决策，一人照做」变成「一人决策，多人照做」而已。

而第二种则需要团队共识。比如题目中提到「进行了调研 ... 最终决定用 swagger-ui 」，如果是第一种风格，那这些话实现者不用关心，我只要知道要引入什么就可以了，其他不关我的事。而第二种风格则是点明了决定用 swagger-ui 是团队的共识，不会出现前端想推这个，后端觉得没必要的情况，换句话说就是大家愿写，「把文档的书写和使用方式反馈给整个团队」，这就是解决大家会写的问题（当然了，你不反馈，别人摸索一下也会写，但你反馈一下，根据项目的具体情况出一个流程，其他人上手更快，节约大家的时间）。

这个只是一个粗糙的分类，第一种负责决策的人也是要考虑团队的意见的，否则推起来太难。而第二种，团队统一不了意见，或者虽然统一了意见，但负责设计的人看到了大家看不到的更好的路，而且很有自信，那么负责设计的人也会利用自己过往的成就、大家的信任而形成的权威来强推。

[lxml]

虽然我觉得这种题目区分点其实很好的，但实际情况是大家都很忙，为了完成这一个题目需要耽误起码一到两天的时间，为什么不选择不出这种题的公司去面试呢？

[wpzero]

这个公司的面试没毛病，考察能力而已。

[wpzero]

还想提醒下楼主，这种公司更靠谱，比面试都没深入谈某方面技术，就过了那种。

[Mingchuan]

感兴趣的可以发邮件给我~https://www.v2ex.com/t/385660#reply0