一家做产品分析的公司，billing团队只有3个人，却在招"不需要明确需求也能干活"的工程师。这个反常识的招聘标准，让6个月前入职的员工在HN（黑客新闻，Hacker News）上写了一段很长的回复解释为什么。
核心矛盾在于：他们要找的不是执行者，是能在模糊地带自己找活干的人。
「等票机器」为什么活不过试用期
HN用户「marandaneto」是PostHog billing团队的成员，他提到一个细节：有些工程师技术过关，但没通过试用期，原因是"等着别人告诉该做什么，而不是自己理解现状、提出解决方案"。
这个判断标准直接写在招聘帖的反面清单里——「This role is not for you if: You need clearly defined requirements before you start building.」
有人追问：这是要工程师自己判断模糊需求，还是要他们自己写需求再和非技术人员确认？
「marandaneto」的回答是：两者都要。Billing团队目前3个人，各自负责的方向几乎没有重叠，没有管理层级，"有很多事要做"。这意味着你需要自己判断什么时候该写RFC（Request for Comments，技术提案），什么时候可以快点交付，什么时候必须做得更扎实。
更关键的是：你得主动去找非技术人员聊。
非技术人员"相当技术"，是个什么体验
「marandaneto」补了一句：billing场景下经常需要和非技术人员沟通，但"这里的非技术人员也相当技术，所以对话通常很轻松"。
这句话透露了两个信息。第一，PostHog的组织结构很扁，工程师需要直接对接业务方；第二，这家公司对"技术"的定义很宽，不是只有写代码才算。
技术栈方面，团队主要用Python（Django）、Rust、ClickHouse、PostgreSQL、React、TypeScript。薪资按地点、职级、经验有公开计算器，远程岗位覆盖GMT+2到GMT-8时区。
「marandaneto」自己入职6个月，总结这里的生存法则：自主工作，偶尔交换想法。如果你认为某件事有趣或重要，大概率能争取到资源去做。
高信任度的代价：招错人的成本翻倍
这种模式的另一面是筛选极严。传统公司用"明确需求→排期→执行"的流程降低风险，PostHog选择把风险前置到招聘环节——宁可招慢点，也要确保进来的人能自我驱动。
「marandaneto」提到一个细节：团队现在"几乎没有管理岗位"。3个人的billing团队，没有专职经理，意味着每个人都要同时处理技术决策、优先级判断和跨部门沟通。
这对工程师的要求变了。不是技术栈多深，而是能不能在信息不完整时推进事情。不是代码写得多快，而是能不能判断什么时候该停下来对齐、什么时候该先做出来再看。
招聘帖里那个"not for you"的表述，本质上是一道自我筛选机制。能问出"你们到底要我自己判断还是写需求"的人，已经比直接投简历的人更对味。
「marandaneto」最后说：如果这种工作方式让你兴奋，这里是个好地方。如果想到"没有明确需求"就焦虑，那确实不是为你准备的。
PostHog的官网被同一个帖子里的人夸"建这网站的人肯定玩得很开心"。一个把招聘做成产品体验的公司，招人的标准本身也成了产品的一部分——不是卖梦想，是把真实的摩擦摊开来，让对的人自己识别自己。
你上一次遇到"需求模糊但必须推进"的场景，是怎么处理的？是停下来要 clarity，还是先做一版出来撞墙？
热门跟贴