@evilStart 目前没有 ai 工程师团队，直接包括在部分 “软件工程师” 的工作中。
有部分我们自己给予 paper 实现的算法，也有一些是用现有工程实践基础上按照特定场景训练的模型并集成。
第三方的模型 /解决方案也是有用到的，毕竟 AI 成果做到工业级可用的时候每个具体场景通常都要分别投入精力。

v2ex.com/t/793746 阁下是否愿意来看看？不过我们目前没有生产的 golang 服务

hello，https://www.v2ex.com/t/793746 不知道阁下是否感兴趣。

不是完全你上面提到的内容，但是按我理解也可以很大程度活用你的积累。
如果你对媒体处理（视频、图片）、图像算法、排版算法等事情感兴趣欢迎来了解下

@Sain 应该是 “能在没有帮助的情况下，独立解决中等复杂度问题、自主发现问题”。 🤦‍♂️我脑抽了

https://www.v2ex.com/t/793746 不知阁下是否感兴趣

@test3207 安排了，工作日会有人联系你

没遇到过的问题可能会试探性问，但也是从粗略确认候选人技术广度来的（特别候选人简历上名词排列特别多的情况）。 先看基础和深度然后在考虑广度

@test3207 不考，组团队不容易，无脑八股文浪费大家时间。

就像文中说的最关键的是通用能力。在这基础上高级会有一些熟悉的领域，通过顺延简历描述和随机抛出一些可能遇到的相关问题考察这里的深度和平常的思考。

🤦‍♂️ 啊

@youmoo 还在招，已经加你微信

@arminSheng 好的，我们同事会这几天联系你的

目前只剩下 senior HC 了，偏前后端都可

@CallMeSoul 哈哈，谢谢建议。那部分是我们的 toC 产品

@popil1987 相比之下是的，但在前后端引擎需要高度复用以及团队规模不希望阔太大的情况下，多一个语言带来的问题可比招个人学 nestjs 多多了

@jilliss 你好，我们更多需要的是后端研发岗位。 目前绝大多数运维需求其实我们现在自己能通过自动化来消化，还没有到需要增加运维人手的规模

@snoy JD 上的是参考薪资，根据人情况待遇有调整。如果写无上限看着就不靠谱，只说面议候选人也觉得没底。

re @luffy


关于 [1.1] ：很精确，确实是偏向扁平化。回报层级多运行效率低而且对执行者通常很不友好，但和某些明星公司的全扁平化管理还是有区别。

关于 [1.2] ：实际角度说，确实有可能出现。我们没有做严格权限限制，更多是约定必须要做 code review 。实际执行过程中只有个别项目个别时期会出现这种情况，出现问题我们会去追这个人通过其他松散管理方式优化项目质量。

关于 [1.3] ：可以，除了 code review 本身没有权限限制、气氛上大家还是比较愿意对自己感兴趣的 PR/issue 提交自己的想法之外，reviewer 通常是模块 owner 或者对这个比较熟悉的人。junior 同样可以做模块 owner 。PR assignee 有可能只能 review 技术实现和代码本身，策略对需求的匹配度是通过 mention 的方式来告知。

关于 [1.4] ：不会。只是对于上下文不通通畅或者时间压力导致这个质疑的解决甚至只是回复推迟的情况时会发生的，但我们会通过 issue 记录，并会尽量周期清理。目前最低限度一个月都会请扫一次

关于 [2] ：关系到一些敏感信息，这方面我不能完全透明地仍到公网。可以说的是我们的收入去年有了很大突破。坦白说，这个项目能有很多 senior 运行四年，如果该死早就该死了。长期怎么样从我嘴里说出来其实没什么用。
如果你觉得我没有回答你的问题可以继续追问。

关于 [3] ：我不否认现在的维护成本问题，现在架构和历史进程和业务形态有很大关系。其实这个项目可以拆成三个独立项目，这是因为一些复杂的需要我们做成了 mono repo，所以看起来一个项目用的技术栈非常多。未来应该会慢慢调整，什么时间怎么改就看发展情况和社区情况啦。
因为技术栈复杂导致非预期加班，确实有出现。现在除了和上面说的 mono repo 有关之外也和本身业务 /技术需求挑战有关系。这和我们这四年没有放开扩大开发规模也有关系，现在既然我们在扩招我认为也一定程度可以反映我们的态度

@nbzhaosq 哈哈哈哈，你的代码和文档时不时会看到

@levin1001 老板今来玩玩？哈哈哈哈