最近，公司开始大幅扩张，各个团队都在招人，而且都是招那种比较高级的人才。我也不例外。
说实在的，在 2024 年 8 月这个时节，市场上被释放出来没有找到归宿的研发工程师还是很多的，既然有这么的候选人，就不免贪心，想找到一些真正好的候选人。这反倒成了我的困境，因为这样就势必招人的速度非常慢。
而另一个困境是，我所研发的系统，专业性非常强，虽然说，通用的研发技能，可以胜任我部门的工作，但是如果游刃有余地完成工作，那是不可能的，必须把领域知识给补起来，才可能。这就造成了，虽然我的人入职了，也不能快速形成强大的战斗力，还需要很长的时间去适应和积累。
于是，我想到了另一条路。
前文说过，我在招聘产品经理。
其实，我是一个研发 Leader，按照我现在管理的团队规模来说，还没到能配置产品经理的程度。但是为什么会有一个产品经理的岗位划归我管？这就是我本文想谈的问题，产品经理为什么失败。
最近，我在招聘一位产品经理。陆续，我已经面试了四位候选人。能明显感觉到，一些产品经理比较好，另一些不太好。但是，好在哪里，又不好在哪里呢？似乎缺乏一个清晰简易的模型来刻画。
于是，我今天就打算探究一下，到底怎么才能通过面试去测试一个产品经理的好坏，怎么去比较不同的人之间的高下之分。
在重构一个历史遗留系统的时候，我发现权限角色和用户授权系统，实现得稀烂。权限角色系统，是所有后台管理系统都绕不开的一个重要模块，但是，因为用户需求的灵活性要求，系统管理的高效性要求，实际业务的复杂性要求，鲜少看见一个高度成熟，开箱即用的权限角色系统。不是需要大量的二次开发，就是配置复杂无比。
而又因为权限角色系统抽象的复杂性，学习曲线陡峭，导致开发者无法简单上手，所以，虽然有了很强大的 RBAC 模型，以及很多实现的范本，但是，常见的情况仍然是各种后台管理系统的权限角色体系，甚至包括操作界面，都实现得差强人意。
记录一些怎么也记不住写法的 Markdown 语法。
此前，已经介绍了《如何从 0 开始，创建一个 Electron 的 App》，每个人就有了一个梦开始的地方。如果想实现一个功能丰富的 App，了解一点基础知识，是非常必要的。比如，Electron 的进程模型。
此前，已经写文章介绍了如何从 0 开始创建 Vue 项目，今天我们来说说，怎么在 Vue 项目中引入 Element Plus。
昨天，撰写了一篇文章，介绍如何 0 基础入门 Vue，算是讲清楚了学习 Vue 的路线图，今天，继续来介绍一些具体的东西。
最近 5 个月，我都在忙着构建我的第一开源项目 HexoPress，这个项目是使用 Electron + Vue 3 + TypeScript 等技术实现的，一方面，我真的很需要一款合自己心意的博客编辑器，另一方面，我也是真心想学习 Electron 和 Vue 3 的技术，当然还有 TypeScript。
现在，项目终于有了雏形，所以，这里我给出 0 基础学习 Vue 的第一个建议，找一个真实的项目做，在实现项目的过程中学习，这可能是学习某种技术的最佳方法。
