身份证号去掉，剩下的时间多做项目，不管是做偏应用的工程项目，还是偏理论的科研项目，把项目的干货多堆一点，学习成绩好的话，可以把 GPA 列出来， Rank 列出来，核心课程（ OOP ，算法，操作系统，编译原理，网络）单科分数选择性列出，占 3-5 行的样子，其他统统拿掉或者缩短。

@peneazy 是的，我开始就是看的 C ，从链表开始就要应对底层的指针，我还是从嵌入式转过来的，当初微机原理，计算机架构， x86 汇编基础都还可以，看起来都觉得麻烦，主要是需要应付很多底层实现，但事实上算法应该更侧重于方法本身，他的确是需要一点底层的知识，但更重要的是方法，特别是到了后期学图论，运筹学，优化以及图形学，图像处理方面，其实跟底层没啥关系了，很多高阶算法都是在 Matlab 里面做的，只是在应用的时候，对性能有要求，才会用 C/C++去实现。

其实算法就是算法，而算法的实现，有 Matlab(高阶抽象语言，最接近人类语言)实现， Java/C++/C 实现，以及 FPGA/VHDL 实现，理论上同一个算法， Matlab 实现性能最低，但是最方便； FPGA 性能最高，但实现难度最大。

算法导论不建议直接看书，有个 ppt ，是 MIT 讲课用的，先翻这个，不懂的再仔细看书。

其实新手不推荐看算法导论，主要是压力太大了，那么厚一本，而且都是伪代码，看半天看不懂或者花了好长时间看懂了发现效率怎么这么低，很容易产生挫折感。

建议还是看 java 或者 C++的算法书，最好是不太关注太底层的实现的，专注方法本身，算法跟数学一样，本来是很有意思的东西，但是弄不好就会产生挫折感，并不是你笨，而是没有找到合适的方法，适合自己的方法。

所有与算法相关的，我都建议先看那种直接撸代码能跑出效果来的，然后自己慢慢调，这样会有持续的成就感，这点很重要，要有持续的激励。

杨幂都 50 亿身价了，你们还在这里谈月薪年薪什么的。。。

@johnnie502 别的不吹，就那个锅底，国产怕是很难赶上。。。

听我的，不要买电饭锅了，买个电磁炉+德国亚马逊 WMF 高压锅套装煮饭，秒杀市面上绝大部分电饭锅，包括带 IH 的。而且还节省能源，好洗，夏天可以煲绿豆粥，冬天可以压排骨，比电饭锅不兹道高到哪里去了～

tumi ，问一百遍也是 tumi ，不要搞那些小众的，很容易碰到坑。

@jmy 同魔都，还有个最老的神州行，无月租，接电话 3 毛 5 一分钟。专门用来收垃圾短信。

熟悉 office ，能把 excel 全套公式整明白就不错了，还不谈 VBA ～～～

楼主还可以，应该能找到合适的坑，反正我毕业的时候没有楼主这个水平

二手小型塔式服务器才是王道

必须 tumi

不错，我自己原来写过一个打印的，是横着分层排列的，命令行下面很有挑战性，如果同一层级上面节点个数一个屏幕显示不下就很麻烦，所以我每次做实验都是最多不超过 xx 个节点，你这个比我当初那个好多了。。。

@chaleaoch 其实我比较关心的是，来一个真正的案例，然后用纯 join 实现，纯子查询实现，部分 join+部分子查询实现，各个方案都在尽量优化的情况下来 PK 一把。以前在做的时候，也是事先在网上做了调研的，貌似 Stackoverflow 上面有比较。不过我最终还是放弃了 join 而选择了子查询，这不是经过仔细的考量得出结论后选择的，我当时的直觉是如果是三四个表 join ，在 key 和索引的帮助下，效率应该也还可以，但是一旦表多了之后，我个人感觉数据库性能会有急剧的下降。当然这都是我自己的感觉。当时时间紧迫，业务急着上线，凭直觉做出了选择，后来业务也能扛得住就没有再去关心过这个问题。

现在我确实也非常想听听碰到过这个问题的其他同行的经历以及对应的处理方法。

join 太多自己都觉得麻烦，不过对于这种一个 associate 表，专门负责各个 index 关联的，除了 join ，再就是分解成子查询了，还有其他方法么？我也很想知道。

#r13 @jarlyyn 你们是一条记录主键，关联这么多表的各条记录的 id ，这样实现的吧。
我有一个问题是，如果要对这一条记录进行操作，是不是要分解为多个子查询？

举个例子，我有一个功能是显示用户的累计消费金额。如果用户对一个订单的某个商品进行了退款操作，我要更新用户的累计消费金额，就得在退款的同时，更新这个关联表，然后通过关联表，查询对应的用户 id ，更新用户的累计消费金额。很麻烦，但是感觉也没有其他很好的办法。你们是怎么做的？

还有就是这个累计金额，你们是在用户表里面单独定义了一个字段，还是每次都重新查表计算生成？我们是单独定义了一个字段，因为这个累计金额会很频繁的用到，比如用户登录之后提示，用户每次打开用户信息页面等等，每次都通过查询计算生成的话，感觉会占很大的开销。但是这样做的话，可能会有字段存储的值与实际值不一致的潜在风险，比如用户退货的时候需要更新这个字段，用户在降价之后申请价格保护也会更新这个字段，用户下新的订单会增加这个字段，我们现在是封装了一个函数，业务完成后自动 update ，目前业务逻辑梳理的还算是比较清晰，没有出过问题。但是如果以后有新手接手，忘记添加这一个操作，就有可能造成不匹配，所以一直想问问同行这种情况到底怎么处理算是 best practice 。

我早发贴问了，还专门发到工单系统里，结果被挪到水区里了。。。
https://www.v2ex.com/t/344466#reply0

后端表示 jQuery 已经够用了。。。

会就会，不会就不会，会一点的稍微扩展一下没问题，吹太厉害了会被自己打脸的。再就是不要浪费彼此的时间，面试官特别是做技术的都不蠢。

@Limius 基本上外企上班都不需要验指纹吧，那些办公的需要定位的 IM ，一律也不用，强制用的话就走人，换一个屋檐的事情，天不会塌。