所以楼主想要低成本招人，主要是看重了价格优势。这样可以买的很便宜。凡是不能继续干的人都属于“没梦想”的人，一直靠“有梦想”的人，可以拉低成本。对于咱大众来说，没什么搞头。

创意、原型、商业计划书。其实公开也没什么大不了的，毕竟都算不上竞争壁垒。哪怕是很好的创意点子，真的好的话，别人难道还不会抄么？相信有这个实力的人不在少数 (除非市场太小众，那样其实也赚不来多少钱)。而所谓的壁垒就是别人就算知道也抄不来的，比如精细化运营、B 端关系、价格优势这种。做工具类软件，单单好用是无法构成壁垒的。

找你老板的竞争对手谈谈呗，看怎么合作。

不要裸辞吧。先按照你想找的工作带薪准备呗。至少把清晰可行的学习计划整理出来之后，再辞职也会好一点。

我之前加入的创业公司融了 1500w，做了 2 年的技术合伙。怎么说，有一定收获，不过后来来了大厂仍然有收获。你甚至可以大厂学充足了，再找个创业公司（建议你有能力分析行业、分析公司、分析创始团队能力，再去找）

大厂。你不去大厂永远不能清晰的了解行业。带着问题去大厂，成长更快。至于老板说的那些都是骗你的，如果你不够强(以时间来看，你有 99.99%的概率达不到我认可的“强”)，在小厂才是浪费时间。

重点的条件是，主持人是否知道彩票中奖，同时保证接下来公开的彩票都是不中奖的彩票，这两个条件。

三门问题的条件非常严格。上面的问题有一下几个条件需要进一步满足：
- 所有的彩票必然有一个中奖
- 主持人知道所有的彩票是否中奖
- 主持人在选择的人选中不中奖彩票的时候，把其他所有不中奖的彩票都公开。
所以，如果是我，如果换彩票没有成本的话，肯定要换。因为不确定上面的条件是否发生，如果发生了，那么你的中奖概率就会提升。如果换彩票有成本的话，那么要折合一下上面三个条件都发生的概率 p1*p2*p3，p1*p2*p3*(n-1)/n 和 1/n 做对比，哪个大选择哪个。

向楼主方向努力，希望能加微信，多学习取经。我目前处于解决房贷中，预计还有 2 年；如果考虑苟着生存 5 年，那么还需要多干 1-2 年。然后我就 35 中年危机了。

深入思考：35 岁后的程序员，他所掌握的技术是否有价值？如何区分和 25 岁程序员之间的差异？
1. 技术流体系：增加知识壁垒。如果在广度+深度上，持续投入，那么这个差距年轻人只能通过投入时间才能追平。而这块的知识投入上，要选择时效性久的：资源分配调度(运筹学+图论体系：操作系统、内存管理、线程管理)，经久不衰的编程语言(语言特性的深入理解、链接和加载运行机制、编译原理)，分布式和并行技术(一致性、高并发、高可用)、交互相关技术(UI 系统设计、图形引擎、物理引擎、多媒体底层技术)。避免积累的内容有：框架、社区没形成的新语言、不通用的业务逻辑、低难度类似 CRUD 的经验。这个办法的优势是：对于一线工作来说，应该还是有办法找到坑的；只需要学习不需要分心其他的。劣势是：市场空间较小对于想要回二线的人来说，价值很低。
2. 技术+运营流体系：形成个人产品。持续参与开源项目，自己组织开源项目，做创业项目，经营个人博客，经营自媒体，自己经营技术培训。类似这类的，都需要长期运营吃经验，并没有明显的规律可以让年轻人迅速掌握。优势是：这些如果形成收入，那么在一线还是二线都是可以生存的；劣势是：比纯技术流体系考虑的多，难度较大，很多人运作不出商业价值来。
3. 运营流体系：关注和其他多部门协同，调度多部门资源；多理解其他部门的业务逻辑；可以从战略层面规划技术；有管理能力。这个路线就是在公司晋升的路线了。优势：跟技术流难度一样，算比较简单的；劣势：需要运气机遇、如果公司挂了自己也难独善其身，返回二线只能考虑创业。
综上，
- 如果留 1 线：选择比较多。如果进了大厂可以运营流，如果在小公司可以技术流。即使进了大厂，仍然会遇到比如裁员等等的，所以要进经济效益好的大公司。经济效益不行的时候要及时切换。进入大型国企央企，虽然看起来可以，但如果这些企业进行市场化提升效率，那么仍然面临同样的问题。所以进入国企央企也要考虑企业生存能力。
- 如果回 2 线：选择路线 技术+运营流，打造个人口碑、个人产品。难度较高，如果经营不出商业价值也没用。好处是，这方面的积累在留 1 线和进大厂仍然有一定的作用。如果有经济效益，可以考虑吸纳大龄返乡程序员。
一定要避免的是：沉迷搬砖，沉迷 CRUD，在中小公司放弃向大公司挺进，进大公司后松懈放弃技术和管理能力的提升。

说几点我的看法：
1. 所谓的用户痛点什么的，其实是你框架锚定的市场空间。问自己的问题：你的框架解决什么问题？你的框架给什么样的人用？这些人群有多少？
2. 推广自然要根据你锚定的市场，找到对应的人群来推广。问自己的问题：如何找到这些用户？他们通常在哪里活动？以及如何把其他用户挖掘到你的框架下？
3. 框架本身是很重要的。问自己的问题：一个新用户最希望看到的是什么？是什么让他决定尝试使用你的框架？是什么进一步决定他使用你的框架生产？
4. 留存用户。问自己的问题：是什么导致了用户放弃你的框架选择其他框架？
很多问题不光是你自己回答，也需要寻访用户得到答案。就我个人来看：第 1 点不清晰，说明介绍文档介绍的不够清晰；第 2 点，目前你至少如果有少量用户的话可以和他们多交流；第 3 点，文档上不够：缺乏视觉性效果、缺乏性能评测效果、缺乏可交互的在线 demo 、缺乏有力的其他用户使用经验的整理和汇总；第 4 点，你可以多问问用了一阵子最后不用的人原因是什么。所有这些做的都足够好，就会有人自动参与到项目里开，否则大部分人都不会产生兴趣。

可能是网警钓鱼贴

框架抽象层面上，可以结合源码谈谈对设计模式的理解。其实就那么点东西，什么 MVC，MVP，MVVM，什么依赖注入，什么 event-driven，什么基础设计模式：单例、state/strategy 、adapter 、proxy 、decorator，什么继承和聚合的区别，还有什么面向对象的 SOLID 原则什么的。语言层面，一般会围绕对象内存模型、线程管理、内存管理、运行时堆栈、错误和异常处理，这些来问，偶尔结合实现个设计模式。。

level 高点的面试，还会问一些对业务的理解，对管理的理解

我觉得还可以。没亮点主要是看不到会什么难的东西，感觉都不难。项目可以简化为 3 个，着重笔墨写难的地方。比如某些你做过的，更加原理层次的，比如 token 这块光各种加密解密，以及优劣，对比 cookie/session，防止 csrf 等等，都可以展开讲一堆，因此也可以写的更深入一点，加一些原理性知识，让面试官可以扣着问的；再比如 mysql 的优化这块，锁、索引、涉及性能的关键字、innodb 引擎底层原理，业务层如何分表、为什么加 cache 、数据一致性的保证、加队列、做负载，展开可以讲一大堆。普通的 CRUD，还有读取之后调工具包的工作，我觉得都可以不用写。另外就是面试前刷刷题，难免碰到让你写算法题目的面试，也别因为这么简单的事情丢了机会。

线上 bug 那块不能用调试器，我说的有点绝对了。如果有数据记录，可以数据重放；或者配合一些快照工具，可以从崩溃前调取程序快照，也许还是可以用断点的。但总之线上 bug 用调试器断点定位，还是太困难了。成本高。

我也喜欢用调试器。不过周围大家都是 log 调试。调试器依赖编译开关，尤其是一个服务有大量上下游依赖的时候，项目的配置都有点搞不明白，自己改一下增加 debug 版本还是有点困难的。log 就非常容易了，另外仔细观察 log 也可以很快定位到问题，定位不到说明需要增加 log，这种也是好的，尤其是排查线上的 bug 根本不可能用断点，log 记录的是否充分就很关键了。
整体，我首选 log 调试，其次选择调试器。

另外 reference count，内存还比较碎片化。自己做内存池其实已经开始接近做 GC 了。

poll 没用过，既然要实现异步还加锁，不知道什么操作； IO 相关的 buffer 互相独立我觉得更好。另外更好的异步方式，我觉得是用系统自带的异步接口，按照 event-driven 的模式来构建，同时也做个线程池对把部分不支持异步的操作异步化。

RAII，可能实现起来最需要慎重考虑的是异常安全+线程安全 /防止死锁，不知道这块你们 CTO 考虑的如何。但很多人模板水平确实太差，不会用模板实现 mixin/traits，写的工具用起来很麻烦。

如果就用 reference count 管理内存，直接用标准库的智能指针确实更好，没必要自己实现还实现错了。不过我个人觉得更应该用 GC 。很多人并不会用智能指针，也会带来灾难。尤其是区分不清楚 weak, shared, unique 的使用场景。

单例这块我同意楼主说法，static 初始化可以保证线程安全，但也要注意编译器版本探测和对应的开关是否打开；另一个一劳永逸的办法是手动在多线程创建前初始化全局单件。动态创建的，很难保证线程安全。加锁 double-check，也会在指令乱序下失效。

我估计你们 CTO 就是纯粹靠年限混了个 title 。实际 C++水平，也就在高级和资深区间？

代码不重要，只要产品能盈利，这个我是赞同的。所以更不应该用 C++，直接 nodejs 不香么。或者 go，如果喜欢类型系统的话。