新开发者如何学习与寻找机会：Theo 的经验和建议

一位观众问，新开发者该如何学习：是慢慢钻研自己感兴趣的东西，还是采用其他方法？这是个很好的问题，也比过去更难回答。人们学习、求职和建立职业生涯的方式，自我入行以来已经发生变化。

以前的建议来自我亲身经历过类似的招聘环境，如今情况不同了。接下来是我的外部观察，而不是保证我走过的路对现在毕业的人仍然有效。如果今天重新开始，我自己也未必能成功。

有经验的开发者也负有责任。我们不能因为自己在不同的时代找到了入行途径，就把后面人的梯子抽走。那些有潜力成为优秀工程师的人，仍然需要学习和展示潜力的机会。

我想区分两个问题：如何学习，以及如何找到工作？两者有重叠，但并不相同。一个人可能已经进步很多，却仍然难以让雇主看到这些成长，尤其是在招聘判断充满噪声时。

我画了一个开发者能力分布示意图，认为人们常根据身边的人判断什么是平均水平。这可以提醒我们注意参照群体的偏差，但它不是经过验证的开发者能力测量。图中的百分位只是思维模型，不是对真实个体的排名。

为了说明问题，我假设每年新增 7 万个技术岗位和 10 万名计算机专业毕业生。我明确说明这些数字是编造的。它们只是展示岗位与候选人数可能不匹配，并不是任何国家、年份或当前就业市场的统计数据。

即便在这个假设中，也不能认为面试能够完美排列所有候选人的能力，并严格按能力顺序分配工作。面试官看到的证据有限，会犯错，也会互相产生分歧。招聘决定是在不确定条件下作出的估计。

我记得在 Amazon 时，面试流程要求面试官给候选人打 1 到 4 分。偶数分档避免大家轻易选中间值。我可能非常看好某人，而其他面试官不同意，反之亦然。评分机制迫使人作判断，但并不能让判断变得精确。

我用聊天中的一位观众举例，说明每个评价都应有不确定范围。根据我见过的作品，我觉得他很有才华，但我可能高估或低估了他。在图上自信地点出一个位置，并不等于测量了一个人的真实潜力。

公司的现有团队也可能影响它对“普通候选人”的参照。我的重点是，招聘不是一场干净利落的排名：公司需求、可获得的候选人和不完美的评估都会影响谁得到机会。

我在学会可靠交付软件之前就被 Twitch 录用了。我了解电脑和服务器，但面试官问我想用哪种语言时，我愣住了。我因为最近用过 C++ 而选了它，随后却在题目上遇到困难。

C++ 面试不顺利后，团队找来了一位侧重前端的面试官，而我在那一轮也表现不佳。但两位面试官仍然喜欢我，认为我可能适合团队。他们先给了我一份三个月合同，之后又续了一次，最终才让我成为全职员工。

团队当时承担了风险：他们急需对媒体领域有兴趣的人来推进项目，而我的技术背景和与团队的相处让他们愿意给我机会。我努力工作，希望保住这份工作。处境相同的其他候选人未必会得到这样的机会。

回头看，可获得工程师的短缺与我自身的特点一样重要。团队可以录用一个有潜力但经验不足的人、继续寻找，或让岗位空着。我的情况中，招聘的紧迫性和参与其中的人让第一个选项成为可能。

我实际上是在带薪工作中学习，我不想假装每个入行的人都能指望同样的条件。我的看法是，如今入门岗位的竞争更激烈，但不同地点、雇主和时间的实际经历会有所不同。

我用三个因素思考招聘：雇主的紧迫性、合作关系或亲和力，以及能力。第一个主要由雇主决定；双方共同影响合作关系；候选人可以发展和展示技能，而雇主仍有责任公平评估。

招聘紧迫时，公司可能愿意给技能尚未得到充分证明的人一个机会。当更多有经验的人竞争同一个岗位时，应届毕业生可能更难展示相当的能力。这并不意味着没有经验的人永远不会被录用，入行仍有多种途径。

AI 生成的作品让制作作品集更容易，也让作品集更难解读。这并不意味着每份作品集都没有意义：它让解释决策、讨论权衡、展示自己理解、维护和改进作品的能力更加重要。雇主应考察这些技能，而不是把外观当作证明。

最初的问题是如何学习，所以我们来关注个人可以影响的部分：提升能力和建立关系。我说的不是把人脉当成技巧，而是找到关心类似问题的人，学习如何与他们合作、交换想法。

我问观众，他们是否经常与自己认为能力更强的开发者相处。很多人说自己远程工作、住得离技术中心很远，或者附近根本不认识其他开发者。这可能让人感到孤独，也会影响日常能够获得多少反馈和启发。

我很幸运：高年级学生让我接触了 Linux，后来我的朋友也对编程产生兴趣。在人生的大部分时间里，我都能和身边的人讨论技术工作。这样的环境让学习成为日常，而不必每次都从零开始安排。

不是每个人都能搬到旧金山或找到本地社群。线上社区可以弥补部分差距：分享想法、提出问题、帮助其他成员，并观察他们如何推理。远程交流与面对面相处不同，但仍能带来有意义的同伴学习。

我见过社区成员把一个随口提到的想法做成基准测试，在聊天中提供有用信息，也有人通过共同兴趣建立的关系找到工作。这些都是个人故事，不是保证有效的求职策略。它们说明，让别人看到你的思考，可能帮助你遇到欣赏它的人。

开发者很难准确知道自己的水平。我用一张图说明不同经验水平可能如何影响交流，但图中没有证据支持“相差某个精确数值就会不舒服”的说法。应把它当成比喻，而不是心理学定律。

我讲到曾帮助一个人处理结构混乱的应用：重复的数据获取方式、复杂的前端流程和过时的后端模板。这里的教训不是新手应该什么都会，而是当项目复杂度不断累积时，反馈以及愿意重新审视假设的态度很重要。

有时身边的人对编程的兴趣深度或方向不同。想深入探索的学生，如果附近没人分享这种好奇心，可能会感到孤立。这并不意味着同学的价值更低，而是说他们可能需要为特定兴趣寻找另一个社群。

社区可以提供一个地方，让人提出在课堂或本地圈子里显得过于专业的问题。来自不同时区的观众，可能只是喜欢和关心同一主题的人待在一起。真正有用的是共同兴趣，而不是对某个创作者的忠诚。

你不必参与每一场讨论。阅读有内容的讨论、跟进一个链接、试用一个库，然后带着问题回来，都是参与方式。目标是让学习少一些孤立，多一些与真实工作的联系。

让你对一个社群感兴趣的品质，也可能让别人喜欢与你合作。因为关心而参与，提出好问题，回应他人的讨论，并在力所能及时提供帮助。这比反复在对话中丢作品集链接更有用。

如果有人需要一份资料，而你记得它在哪里，分享出来就是一个小小的贡献。留意他人的需要，参与时不强求关注。这些习惯会让别人认识到你乐于合作，也会给你学习机会。

提升技能需要某种方式来校准自我评价。早期成功很容易让人过度自信，遇到更难的问题也可能让人气馁。来自有能力的同行的反馈，以及与欣赏的作品作具体比较，可以帮助你同时看到进步和不足。

我用自己早期的 YouTube 视频举例。前几条表现很好，于是我以为之后每条都会成功。当一条关于 SolidJS 的视频最初观看量少得多时，我的信心受到了挑战。我经过很多次尝试才逐渐学会怎样做好视频。

早期成果可能带来误导性的掌握感；学得更多之后，也可能意识到自己还有很多不知道的东西。我在日常意义上用“达克效应”和“冒名顶替综合征”描述这些体验，并不是作诊断，也不是说每个人都会遵循固定的自信曲线。

与其凭一时感觉判断自身价值，不如向你尊重其作品的人请教具体反馈。比较特定技能，不要拿自己的全部身份与别人的职业生涯相比。社群能帮助你了解好作品是什么样，以及接下来值得练习什么。

线上同伴同样重要。本地技术中心可能更容易带来偶遇，但地理位置和生活成本让许多人无法选择它。寻找适合自己兴趣和处境的社群，不必认为某个城市是成长的唯一道路。

回到最初的问题：从自己喜欢的事情开始，并找到同样喜欢它的人。它可以是前端库、编码代理、底层内存管理、硬件，或你想构建的产品。兴趣能够支持提升所需的反复练习和好奇心。

用 AI 学习时，可以要求一个小提示、解决思路的解释，或询问当前方案为什么可能失败。如果工具立刻生成完整答案，你可能错过建立自己理解的过程。让它帮助你继续深入，而不是替代深入探索。

我也会问：我觉得有趣的东西是谁做的？我经常查看作者的主页和早期作品，了解一个项目为何存在。理解工具背后的人和决策，可以让你看到仅看代码时看不到的入行路径。

一条简短真诚的感谢消息可能对维护者很有意义。它不必附带请求或长篇推销。我曾告诉 Ryan Carniato 我喜欢他的文章，后来提供了有用的文案反馈，一段关系就从共同兴趣中发展出来。

不要期待联系的每个人都会回复，尤其是拥有大量受众的人。规模较小的维护者同样可能珍惜鼓励。重点是真诚认可帮助过你的工作，而不是把每条消息变成要求内推或免费审查。

为 T3 Chat 改进语法高亮时，我发现了 react-shiki，一个很接近我需求的小型库。当时它只有很少的 star。我联系作者 Basim，询问他是否打算继续维护，以及如果不维护，是否欢迎我 fork。

Basim 回复说自己计划继续维护。他当时从事 IT 工作，业余时间学习编程；这个库展示的能力让我觉得他值得更多机会。我没有空缺的工程岗位，但认识一位正在构建开源 Assistant UI 项目的人。

我把他介绍给那家公司，原本以为面试至少能提供练习和反馈。结果他很快就被录用了。这是一个条件特殊的个人故事，不能保证两颗 star 的仓库一定带来工作。关键在于，有用的作品和人与人之间的联系让他的能力被看见。

Basim 联系我时并没有要求一份工作；是我看到他的作品后想要帮忙。我鼓励大家联系创作者，是因为他们的工作值得感谢，而不是把交流当成期待回报的交易。关系可能带来机会，但并不意味着你有权占用他人的时间。

认可一位小型创作者，也可能鼓励他们继续构建。人们常常记得最早注意到自己作品的人。持续参与、保持好奇并乐于帮助，是成为社区一员的方式；久而久之，这也能补充你正在发展的技术能力。

观察你欣赏的人如何走到现在，寻找可以借鉴的共同点。不要永远只研究一个狭窄层面：前端开发者可以了解设计和 API 设计，后端开发者可以探索数据库以及前后端之间的接口。

深度和广度可以相互支持。先在你关心的领域建立扎实知识，再探索相邻领域，理解各部分如何配合。真诚的感谢和清晰的人际沟通也能帮助你建立联系，而不用把学习变成一场表演。

对有经验的开发者来说，遇到机会时请帮助那些在不同条件下起步的人。对初学者来说，不要失去希望：追随兴趣、练习、寻求反馈，并找到可以一起学习的人。过程可能比期待的更久，也没有哪条路能保证工作，但成长是可能的。