@forever0y 并不是...刚好知道一个你们项目以前毕业的人而已...内部 transfer 策略变化太多，最好问问校友群或者 HR 这方面的政策。单纯作为一个参考： http://forums.redflagdeals.com/amazon-sde-vancouver-transferring-seattle-l1b-visa-poe-us-consulate-2257887/

> Just curious , Why are you moving from Vancouver to Seattle considering its a same company?
> The new salary could easily be 2x after exchange; even for effectively the same position.

@Allianzcortex 发现我这个指代更不明确，符合要求的学校更多了...

还有一个隐形优势是亚麻 L1 transfer 去西雅图后可以隔周回温哥华满足居住年限要求，谷歌满足不了这个条件。但如果决心用 TN 或者嫌温哥华房价太高那就是另一种情况🙄🙄

还是那个老问题...各位同时把 LeetCode 题解放到 Github 和把 Github 放到简历上，担心的是面试出的题不够难么(:D

楼主表意不明啊， [国内某省唯一 985] 还有可能是厦大，建议改为 [国内某省唯一 211] 。这个 2+2 项目真是出人才啊...

@m9rco 不不...不要说"您"，太折煞我了😂 刚好做过一点而已。楼里其他几位的建议都很好，可以都试试，嘿嘿

@m9rco 这里的 sql 是广义的 sql，包括 hql(hive 跑 mapreduce ) 和 sparksql，如果隔天晚上或半天跑出结果存储起来供调用，感觉不会有太大压力

感觉搜 `elasticsearch as recommendation engine` 有很多不错的文章，比如官方这篇 https://www.elastic.co/blog/looking-at-content-recommendation-through-a-search-lens，以及 https://opensourceconnections.com/blog/2016/09/09/better-recsys-elasticsearch/ , **We argue recommendations and search are two sides of the same coin** 推荐和搜索就是一体两面的东西 LOL。要不要先试着直接用现成的 API 搭一个小的推荐系统跑跑看，之后再优化算法选择什么的

@alexmy 并没有...真心没有，我很认真地说

@m9rco T^T 看业务需求和工期长短吧...主要是能跑的 demo 和实际上线之间差的还是挺远的，可能到时候还要建集群存储已有的结果，要跑 Spark 分布式计算 etc 好多。糙也有糙的做法，听说不少公司上线一开始就是跑 SQL 跑出来的推荐结果，简单直接😄

我本科毕设做的就是音乐推荐系统(拿了优秀，算是本科四年里为数不多的不灰暗的记忆，现在来看多少有点逆天改命). 算法因为账户系统太难建立所以用的是 ItemCF，基本思路是 **有更多的人同时喜欢物品 A 和物品 B，那么物品 A 和物品 B 就有比较明显的相似度** . (e.g. 一个人喜欢《红日》和《十年》，那么说明他比较喜欢有年代的粤语歌，推荐《难念的经》就不是一个差的选择). 当时的做法包括但不限于：

1. 用爬虫爬取各大音乐网站专辑，存储在： https://raw.githubusercontent.com/Allianzcortex/MusicRecommendSystem/recommend/recommend/base.txt ，根据评论数量进行 1-5 的打分

2. 每次加载系统时计算相似度，用户点击页面后会提供一些随机歌曲进行打分，然后根据打分(计算 similarity) 来查找近似的歌曲，返回后让用户对这次推荐的满意度和新鲜度打分

3. 杂七杂八说了很多数据可视化 /Web MVC 架构的东西

---

refer :

1. 不知道楼主未来职业目标是做什么。如果是工程的话了解下算法原理就行，不一定要亲自 `get your hands dirty`，真做起来挺费时间的

2. 如果是想要从事推荐算法工程师方向的话可以直接考虑看 G 家的 Wide & Deep，推荐系统里深度学习已经落地不少了

理论上只是纯阅读的最好方法是直接 git check out 到最旧的版本看，主干相对清晰些，之后每次 git diff 看都有哪些新功能。

很佩服能看得下去 Spring 代码的同学，每次那么长的堆栈报错都会打消我继续看下去的想法....现在主要看 Go 的代码比较多，之前看过 Python 一些库，有一些挺有意思的发现，比如 requests 在 github 上列出的第一个版本 v0.2.3 里 core.py 这个文件竟然是用 tab 作为 whitespace (之后就修正了)

挺好的，可以考虑加上用 Mockito 加上单测，与 travis 集成下(e.g. 我的这个 Spring 项目： https://github.com/Allianzcortex/LaraForum/blob/master/src/test/java/com/laraforum/controller/UserControllerMockitoTest.java )

@cyspy 维度表 join 也可以随时更改对外显示的字段，本质上还是外部配置文件呀

如果前端不做处理的话，可不可以考虑后端用一个表存储数字与性别对应关系(gender_relationship {0 : female , 1 : male})，根据 model 再定义一个 DTO，查询的时候原表与关系表 join 一下直接返回的 DTO 就是在前端展示的数据。用 redis 存储查询会快但写起来复杂些。