4-人 5 团队的东西让一个人去做，这什么通用问题啊

这个分数跟页面的内容复杂度有关系吗

我寻思你这些 mac 端的不是工具软件就是 UI 美化版而已。。。 这种东西在 win 上真没什么好折腾的，关键是 win 用户也没有美化的需求，稳定够用就行了。。。很多东西 win 都自带，涉及开发的很多也是虚拟机搞定

这有啥问题吗，你不要把“不信任”看成贬义词
至于说谁比谁更不值得信任，这都是萝卜白菜各有所爱
另外你以为大公司用开源软件堆积成的基础是基于信任？错，是基于“他们也给这个开源项目贡献了代码，他们会从头到尾审查一遍这个项目的代码，才决定用它”。这确实是一种不信任，没有贬义。

你没挂过梯子吗

我的原则是看影响。你要提前预判到你的 bug 会产生什么影响
有的两小时就修了，那我就不管，到时候修还能给自己找 kpi
有的可能要涉及到运营、运维、测试等多人，折腾好几天或者通宵搞。这种就提前修，不然到时候苦的还是自己。当然你愿意这样做当我没说

这种还好吧……用起来就跟多渠道打包一样，还是往 apk 里面写入每个业务员自带的 id 。
但是原理有些不一样，首先多渠道的话渠道数最多也就几十个，一次性全部打一遍就行了。而业务员显然更多，而且会有随时增加减少的情况，所以不能预先打好包。但是根据文章，可以在客户扫码的时候，每个码有自己的 id ，然后就是快速把 id 的那一部分写入 apk 生成新包，这个过程必须很快，不能重编译、重签名，因为用户扫码的时候是要立刻打开下载链接的。

对于比较大的团队和比较严格的规范，应该是远程合并，因为普通开发不应该有 write main 分支的权限。
而对于简单项目和小团队，以及实际操作上来讲，本地合并的话，解决冲突更容易，因为远程合并一般都是命令行或者 web 界面，本地可以用一些 gui ，鼠标点点就能正确合并，操作更简单。

java 的轮子生态很强，轮子的开发者不支持就没那么好用
安卓的话有谷歌在强推，新的安卓轮子都是 kt 写的

这跟 go 有啥关系，很多岗位都是这样的，面核入拧
至于为什么这么卷，我想问你应聘 go 的目的是为了不卷吗，如果是那你失算了，如果不是那你应该适应这种情况。
回到你这个事情上面来，这个事情能看出的不是 go 很难，只有这个公司有问题。再进一步也就只有招聘市场很卷。跟 go 语言关系不大

顶级公司出了个新理念，我赶紧现整一个粗糙的系统出来，直接拿去卖服务，赚第一桶金再说。能赚钱最好，赚不到就荒废。
俗称给自己找 KPI

你没写你想要啥建议啊，是想问要不要参加？都报名了就参加一次，第一次经历过以后就知道要不要报下一次了。

现在这么卷吗。。。

直接 MS 全家桶呗，不行上 MS 云，一整套，价格表他们网站上也有

分批就分批呗，慢点来就行了，老板问你就说我电脑太差了没办法

选 java ，钱多。
什么 C/C++永不失业都是虚的，你前期赚的少，不失业又有啥用
而且选 java 的同时也不是不可以兼修，后期再转也没事

有这个心态说明你在 2C 公司容易被当成大头兵，如果你体验过后真的乐在其中那你就是卷王了，如果你发现并不是自己想的那样，那你就惨了