@EminemW 代码优化分为几个层次。

初期的优化主要集中在功能上，不写 bug。
然后是鲁棒性，在异常情况下不写 bug。
然后是性能，提高系统吞吐量，或者执行降低延迟。
然后是可维护性，在团队开发过程中降低其他人的理解难度，再做好一些，通过设计做到模块解耦，降低删除无用代码的难度。
然后是可扩展性，能够预测系统或者业务的发展方向，提前设计好锚点，让系统能够通过扩展而不是修改的方式增加功能。

再往后就是各自的境界了，我至今也还没参透……

@takemeh 线性扩容有两种情况，一种是“无状态”服务，比如常见的 web 后端；另一种是“有状态服务”，比如 mysql 这种数据库。

对于无状态服务，一般只要解决了“服务发现”功能，在服务启动之后能够把请求量引到新服务上，就可以做到线性扩容。常见的服务发现包括 DNS 调度（通过域名解析到不同机器）、负载均衡调度（通过反向代理服务转发到不同机器）或者动态服务发现（比如 dubbo ），等等。

对于有状态服务，除了要解决服务发现问题之外，还要解决状态（数据）迁移问题，迁移又分两步：先是数据拆分，常见的都是用哈希或者一致性哈希把数据打散。然后是迁移，常见的办法有快照和日志两类迁移方式。也有一些数据库直接实现了开发无感知的状态迁移功能，比如 hbase。

@yesicoo 医院就诊皮肤科，一般脂溢性脱发都会外用米诺地尔，内服非那雄胺。

但更重要的是尽快接受“该掉还是会掉的”这个现实，保持心态乐观就好。

@native nas 不就是私人的么……买个放家里就行了啊

怎么听都是 nas 更合适……

mweb

@jackltx 抱歉，我只在国内互联网公司待过，唯一接触过的几次是校招的同学没来我这边而是去了 amazon 之类的跨国大厂，几年之后再次沟通感觉成长有限，让我感觉外企在国内的一些部门并不是有很强的技术竞争力。但是这毕竟只是几个个例，更明确的建议听听其他人的意见吧。

@xderam 打泰的已经被我打死了：）

@daryl
@yizhimamong
面试是双向的，有些来面试的同学我们觉得不合适（今年我们筛选的标准稍微有些严格），也有一些同学面试通过了，觉得我们不合适（比方说有 bat 核心部门的 offer，那微博再核心的团队吸引力都要打折）；另一个角度说，今年团队整体比较稳定，招人是为了变得更好，而不是赶紧招过来填坑，这在一定程度上也让我们对招人这件事更加谨慎。

我们招人的标准是好奇心=能力>经验，大部分人在上一份工作中只是遵照上级的要求写完了代码，但是既没有了解更深的原理，也没有达到“用技术改变了什么”的程度。我认为这部分同学就算来了我这里，对于个人发展或者团队进步来说，不会有什么大的帮助（我们期望的是“更好”），因此卡掉了不少人。

而对于那种，“需要一个更大的平台施展拳脚”的同学，很多地方都求贤若渴，能不能来我这里只能说是缘分，所以我现在招人基本上都是随缘……

对于 jvm 内存来说，变量的引用只是一个指针，指向具体对象还是指向 null，占用的内存大小都不变，64 位机器下应该是 8 字节，但是会受 UseCompressedOops 参数的影响。

对分布式缓存中的内存（比如 redis ）来说，取决于你的序列化方式。比如说，对于 java 原生序列化 ObjectOutputStream 来说 https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/io/ObjectOutputStream.java#L1110，null 会写入 TC_NULL 这个常量（ 112 ），占用空间 1 字节。

另外 1 的话建议分清楚是“后端开发”还是“后台开发”，如果单纯是后台管理系统开发的话，那竞争力肯定要打个折……

字节跳动内部的情况我不清楚不敢瞎说，不过以我个人的经验来说，如果按照你的说法，如果是“不属于十足的技术控”的话，我不太建议你去做分布式存储。

因为这个方向一般离具体的业务比较远，技术方案无论是基于开源方案维护还是自研，都很容易陷入要么变成运维，故障驱动开发；要么技术自嗨，一撸袖子造了一堆轮子的情况……

可以发一下昵称，我看下。

写能解决你实际问题的东西。

@superbai 半年了也没招到合适的人，招聘令我头秃……

@daryl 要

@NewDraw 可以

bbh2g-d2vk9-qd4m9-f63xb-43c33