A Hiring Manager’s Perspective on Tinkering & AI

招聘经理视角：关于“折腾”与人工智能

I’m a hiring manager on the product team at Coder, a growth-stage tech company founded in 2017. Everyone on the product team uses LLMs daily. It’s been fun to watch: docs folks fixing SEO issues on the website, engineers writing documentation, PMs building live prototypes, marketers shipping website changes directly. Nobody mandated any of this. 我是 Coder 产品团队的一名招聘经理，这是一家成立于 2017 年的成长型科技公司。产品团队的每个人每天都在使用大语言模型（LLM）。观察这一过程非常有趣：文档人员修复网站的 SEO 问题，工程师编写文档，产品经理（PM）构建实时原型，市场人员直接发布网站变更。这一切并非由任何人强制要求。

There are plenty of negatives too: layoffs, junior roles drying up, students worried about their careers, and a flood of low-quality generated content everywhere you look. I’m not going to solve those in this post. Instead, I’ll share how AI actually affects hiring at one company that uses these tools heavily. If you’re a candidate, I hope this helps you see how at least one company is thinking about it. I can assure you that we aren’t alone. 当然，负面影响也很多：裁员、初级岗位减少、学生对职业前景感到担忧，以及随处可见的低质量生成式内容。我不会在这篇文章中解决这些问题。相反，我将分享人工智能如何实际影响一家深度使用这些工具的公司的招聘。如果你是一名求职者，我希望这能让你了解至少一家公司是如何看待这一点的。我可以保证，我们并非个例。

Context on how we work

关于我们的工作背景

Every company values different things, so here’s the environment my perspective comes from. If your values (or your company’s) are different, your conclusions probably should be too. We hire tinkerers. When I joined Coder, the first thing I did was stand up the product and poke at it. When I wrote my first blog post, I ended up also fixing the website’s build process because it annoyed me. This attitude is company-wide. Nearly every department has built internal tools nobody asked for. We’ve also hired over 4 people directly from our user community, people who were already tinkering with the product before we ever paid them to. As we scale, we’ve had to get clearer about ownership, but I still want people who look outside their job description. 每家公司的价值观各不相同，因此我先说明我的观点所处的环境。如果你的（或你公司的）价值观不同，你的结论也应该有所不同。我们招聘的是“折腾者”（tinkerers）。当我加入 Coder 时，我做的第一件事就是搭建产品并进行测试。当我写第一篇博客文章时，我顺手修复了网站的构建流程，因为那个流程让我感到烦躁。这种态度在全公司都很普遍。几乎每个部门都构建了没人要求他们做的内部工具。我们还直接从用户社区招聘了 4 名以上员工，他们在我们付钱给他们之前，就已经在折腾我们的产品了。随着公司规模扩大，我们必须更明确职责归属，但我依然希望员工能跳出职位描述去思考。

There’s always more work than people. On the tactical side: improving our product’s UX, writing a new feature or integration, improving documentation clarity, fixing a tiny bug. On the strategic side: better communication between departments, faster decisions. We’ve seen a lot of hiring and firing. We’re still a young company, but we’ve already been through plenty: we scaled too early once and paid for it with layoffs, and we’ve done hiring freezes while finding product/market fit. Right now we’re hiring fast: 21 people in the last month, at a company of ~180. None of those layoffs or freezes had anything to do with AI. They came down to larger business reasons, the same boring ones that ended jobs long before LLMs existed. 工作永远比人多。在战术层面：改善产品用户体验（UX）、编写新功能或集成、提高文档清晰度、修复微小 Bug。在战略层面：加强部门间沟通、加快决策速度。我们经历过多次招聘和裁员。我们依然是一家年轻的公司，但已经历过许多：我们曾因过早扩张而付出裁员的代价，也曾在寻找产品市场契合度（PMF）时冻结过招聘。目前我们正在快速扩张：在约 180 人的公司规模下，上个月新招了 21 人。这些裁员或冻结与人工智能毫无关系。它们归结于更大的商业原因，即那些在大语言模型出现之前就导致岗位消失的、老生常谈的原因。

What’s actually changed

真正改变了什么

The number of open roles hasn’t gone down. Expectations per role have gone up, but not in the way people assume. Myself and many of my peers are not concerned about squeezing more output out of everyone. It’s about diversifying output in favor of impact: a docs person can contribute fixes directly, a PM can prototype their own ideas. This isn’t about filling skill gaps. It’s that going the extra mile got a lot cheaper, so we expect people to do it. We’re less excited about “builders” in the raw sense, since building is cheaper than it’s ever been. We’re more excited about candidates who can demonstrate taste, understanding, and impact. 空缺职位的数量并没有减少。每个职位的期望值提高了，但并不是人们想象的那样。我和许多同行并不关心如何从每个人身上榨取更多产出。重点在于产出的多元化以实现更大影响力：文档人员可以直接贡献修复方案，产品经理可以自己制作原型。这并非为了填补技能缺口，而是因为“多走一步”的成本变得非常低，所以我们期望员工能这样做。我们对纯粹意义上的“构建者”不再那么兴奋，因为构建的成本已降至历史最低。我们更看重那些能展现出品味、理解力和影响力的候选人。

A good litmus test for me is whether someone is only using AI to generate new programs from scratch (likely to get scrapped/unmaintained), or to build on somebody else’s ideas and understand a perspective or part of the company they haven’t before. And then whether they actually get these shipped, improved, and retained. Getting 90% of the way there really doesn’t matter. 对我来说，一个很好的试金石是：某人是只用 AI 从零开始生成新程序（很可能最终被废弃或无人维护），还是利用 AI 在他人的想法基础上进行构建，并理解以前未曾接触过的视角或公司业务。更重要的是，他们是否真的将这些成果发布、改进并留存下来。只完成 90% 的工作其实毫无意义。

In practice: We filter for taste. I want to understand if the candidate has a perspective, an experience, or even a distaste for something, and whether they feel comfortable expressing and applying it. We still hire juniors (more than ever, actually). We just spun up a summer internship program, and we’re hiring more junior roles than we ever have. Communication skills are more important than ever. If someone sends you sloppy AI-generated work, or you disagree with an idea, you need to be willing to say so. And when you don’t understand something, loop in a colleague to collaborate, without dumping work on them to review or shipping while hiding your gaps. 在实践中：我们筛选的是“品味”。我想了解候选人是否有自己的观点、经验，甚至是对某事物的厌恶感，以及他们是否乐于表达并应用这些观点。我们依然在招聘初级员工（实际上比以往任何时候都多）。我们刚刚启动了暑期实习项目，招聘的初级岗位数量创下历史新高。沟通技巧比以往任何时候都重要。如果有人发给你粗制滥造的 AI 生成内容，或者你不同意某个想法，你需要愿意表达出来。当你遇到不懂的问题时，要拉上同事协作，而不是把工作扔给他们去审核，或者在掩盖自身不足的情况下盲目发布。

My environment is not for everyone

我的环境并不适合所有人

Coder values tinkerers, fast-paced ownership, and people going the extra mile. We expect a lot out of people, and those expectations aren’t always documented in some playbook. Not everyone wants to work in an environment like that, and that’s OK. I’m also only in one specific department of Coder (product management and developer relations), and other teams and roles will be different. AI will certainly automate tasks that are central to some jobs. I’m not saying everyone will be fine, that all employees will become curious, or that those who prefer to get a task, execute, and repeat will (or should) succeed in a knowledge worker economy. Coder 重视“折腾者”、快节奏的责任感以及愿意多走一步的人。我们对员工期望很高，而这些期望并不总是记录在手册中。并非每个人都想在这样的环境中工作，这没关系。此外，我仅代表 Coder 的特定部门（产品管理和开发者关系），其他团队和角色会有所不同。人工智能肯定会自动化某些工作的核心任务。我并不是说每个人都会安然无恙，也不是说所有员工都会变得充满好奇心，或者那些喜欢“接收任务、执行、重复”的人在知识经济中会（或应该）取得成功。

I’m also not saying we have all the answers or that Coder is AGI-proof; I just don’t think those conversations are useful when it comes to hiring or getting a job. What I am observing is a significant positive impact on how we work together and how we build better products, and I’m optimistic about the companies we can build with it. If you’re looking to get into another industry or work environment, I’d push you to research what that company values and how they write about AI (I’m sure they are). If you’re a hiring manager, it can be helpful to write about your experiences like I did today. If nothing else, it’ll help candidates figure out where they’re a good fit and what types of work environments excite them as AI changes how we work. 我也不认为我们掌握了所有答案，或者 Coder 能抵御通用人工智能（AGI）的冲击；我只是觉得在招聘或求职时，讨论这些话题意义不大。我观察到的是，AI 对我们的协作方式和产品构建产生了显著的积极影响，我对利用 AI 构建的公司充满信心。如果你想进入其他行业或工作环境，我建议你去研究该公司的价值观以及他们如何看待 AI（我相信他们一定在思考）。如果你是一名招聘经理，像我今天这样写下你的经验会很有帮助。至少，这能帮助候选人判断他们是否适合该环境，以及在 AI 改变工作方式的背景下，什么样的环境能让他们感到兴奋。

If you’re a candidate

如果你是一名求职者

More than any specific advice, I’d encourage you to think about how hiring managers are thinking (this blog post reflects how I think), rather than treating posts like this as a checklist. That said, a few things transfer anywhere. Joining the community of a product you want to work on (ours or anyone’s) is a great way to learn it and see what people are actually working on. Form real opinions about the things you use and build, and get comfortable sharing those opinions, including when you disagree with someone or how you can make something better. 比起任何具体的建议，我更鼓励你去思考招聘经理的思维方式（这篇文章反映了我的思考），而不是把这类文章当作清单来核对。话虽如此，有些原则是通用的。加入你想要从事的产品社区（无论是我们的还是其他公司的）是学习产品并了解人们实际工作内容的绝佳方式。对你使用和构建的东西形成真正的见解，并习惯于分享这些见解，包括当你不同意某人观点时，或者当你能提出改进方案时。