冲浪的时候刷到了一个提问：35的程序员被辞了可以自己接外包啊？为什么都那么悲观呢？
提问的小伙伴看来就是一点没有接过外包，被毒打过啊！
鸭鸭有几问：
你有稳定的外包客户来源吗？ 你能有足够的耐心沟通外包客户，让他们天马行空的设想变成可以落地的项目吗？ 找外包的客户大多是钱少事多类型，要求改到满意，还想要你能后续继续维护。你能接受或者能管理客户预期吗？ 尾款难结，你能保证客户按一开始的约定，给你结算尾款吗？
外包的水深，自己接外包，更是容易被坑。
小王是个 35 岁的程序员，在失业后他选择接外包，如果理想化一些，他的故事应该是这样的：
小王接外包的第一天，在朋友圈打了个广告，收获朋友调侃若干，点赞若干，单子0。
小王接外包的第二天，群发好友打广告，收获朋友打趣若干，鼓励若干，说教若干，单子0。
小王接外包的第三天，他终于想起来，可以到某音、某书平台发信息，但因为之前没有做过，他发布的视频和图文淹没在茫茫人海中，单子0。
……
小王接外包的第二周，发现一个程序员接单平台，注册账号后发现，需要先充值，平台还会抽成。但没有单子，小王只能硬着头皮上了。这一周，小王支出充值金额若干，单子1。
小王花了三周，把甲方爸爸要的微信商城做完了。甲方爸爸一看：
——“这个购物车有问题，点击这个按钮没反应”
——“添加收获地址用户体验不好，你再帮忙改改”
——“这里可能还需要加一个分享到朋友圈的功能”
小王内心开始怀念起以前的产品经理。但这是他的第一个单子，担心对方给差评。之前合同也没有约定需求，他只能硬着头皮继续做。
小王接外包的第一个月，完成单子1，到手 5k ，比之前在公司上班还累。
小王接外包的第二个月，之前呼朋唤友有了效果，有朋友私聊小王：能做小程序吗？我有个朋友想做。
加上好友以后，金主爸爸：”我想要个小程序，要 xx 功能，xx 功能，还得 xx。一个月做完。“
小王：”行，报个价。“
“这个……”
金主爸爸完全不了解市场。
小王只能自己评估了一番，“1w5 吧！“
”行，“金主很痛快答应了。
金主爸爸的需求比较多，时间又比较紧，小王想起和自己一起被裁的同事，两个人一拍即合。没日没夜忙活一个月，终于能交付了，金主爸爸一看：
——“小程序怎么打不开了？”
——“这个小程序能支持打车业务吗？”
金主爸爸虽然给钱痛快，但问题源源不断，小王和老同事都非常心累。
小王接外包的第一年，小王在国企上班的亲戚敲了小王：“我记得你是程序员，单位有个系统开发项目，你能做吗？“
小王喜出望外，准备大干一场，然后发现，国企和第三方做项目需要对公的合同和发票，小王一咬牙，准备开个公司。格子间+公司基本户+网银+手机短信通知，支出 8k。
好在亲戚真的靠谱，小王成功接下国企的项目。
随着时间流逝，小王逐渐适应了又当产品经理，又要写代码，又要当测试，还要干售后的日子，公司也逐渐有了几个全职。但小王开始需要不停找单子，因为员工的工资不能拖欠，单子少了养不活员工，单子多了质量不好把控，甲方爸爸还会事无巨细地来找小王反馈问题。但不管怎么说，这时候的小王不用担心失业问题了。
……
小王的经历纯属虚构，还参考了某乎帖子（原帖：Li Jacob)。35 岁的程序员要面临的职场焦虑，并不是靠外包就能解决的。有商业头脑的小王可以靠外包让自己的生活相对稳定，甚至更上一个台阶，但更多的小王，或许连外包的尾款都很难收到。
而当小王变成老王，为了进一步提高利润，他会不会继续让手下的员工 996 并在 35 岁裁员呢？
....
今天的故事说到这里，但该努力仍需努力，35 岁未必是一条终点线。欢迎来通关面试鸭，助力大家收获 offer。
今天也为大家准备好了面试题：
MySQL 默认的事务隔离级别是什么？为什么选择这个级别？
回答重点
MySQL 默认的隔离级别是可重复读（ Repeatable Read ），即 RR。
原因是为了兼容早期 binlog 的 statement 格式问题，如果是使用读已提交、读未提交等隔离级别，使用了 statement 格式的 binlog 会导致主从（备）数据库数据不一致问题。
扩展知识
进一步分析 binlog statement 格式和可重复级别的影响
接下来我们来展开讲解下，便于大家理解。
MySQL 在使用过程中，为了避免单台故障，需要使用主从（备）机制：
而 MySQL 的主从（备）涉及 binlog 的复制，即从（备）库的数据是通过 binlog 从主库复制过来的。
在早期，MySQL binlog 仅支持 statement 格式，这个格式其实存的就是原先的SQL 语句，这就使得在读未提交（ru）和读提交（rc）两种隔离级别下会出问题。
我们来实际看个例子：
例如有两个事务 A 和 B ，以下图的时间顺序执行：
在读已提交隔离级别且手动提交事务的情况下， 插入的 5 这条记录会被保留。
但是由于事务 B 先提交，所以它会先被记录在 binlog 中，这个操作就导致了问题。
binlog 的记录顺序是：
使得从库同步 binlog 重放的时候，先执行了 insert 再执行 delete，这就使得从库的数据与主库不一致了！， 5 这条记录也会被删除了。
所以，为了避免这个问题，只能默认为可重复读级别。因为这个隔离级别下有间隙锁（Gap Locks）、临键锁（Next-Key Locks），所以事务 B 是无法先提交的，会被事务 A 阻塞，因此 binlog 的记录只能是先 delete 再 insert ，这样就没问题了。
往期推荐
我的编程学习小圈子
入职大厂一个月，跑路了...
工作 3 年，只敢面 1 年经验的岗位
Top3本，一手好牌打得稀烂。。。
游戏厂实习，氛围真好，可惜没转正...
