新手问题 Ruby on Rails 工程师去大厂

leijun · 2020年10月19日 · 最后由 leijun 回复于 2020年11月14日 · 1829 次阅读

最近面试的时候, HR 说我简历做不了他们的后端工程师, 不断强调我没有分布式经验。 还说他们公司的 ful stack 岗位百分之 80 都是做前端工作, 所以叫我要投的话那么就投前端做 typescript + react, 然后叫我重新拾起 javascript 用它来刷 leetcode, 最好要刷到 hard 难度, 所以我的总结是大厂的后端和中小后端要求不一样,所以这是不是和 github 使用 rails 做前端, 使用 GO 做后端分布式有点类似啊? 这换 tech stack 对我好不好???

那是因为那个 HR 的后端 hc 差别不多够了,但前端 hc 还没够,拿你完成 kpi 所以这么和你聊而已。不用理会的。

“没有分布式经验就不能参加分布式系统开发”,也是伪命题。即使没有相关经验,你可以先学习分布式系统相关知识,向面试官证明你知识储备和学习能力都足以胜任,其实就可以了。

分布式系统无非是性能,一致性,容错,冗余等话题。已经是几十年的话题,太多资料可以学。

关于做前端和后端,还有换 tech stack。前端还是后端,我也经历过从 ruby on rails 换到 java,其实不用太关注 “用什么语言写代码” 这个事,这在日常工作中是个特别微不足道的点。

一般一个团队只要一个有经验的人来处理一下架构问题,其他人搬砖 crud 即可。各个人都要求无短板的话,团队成本会过高。而且团队里对于架构都会有自己的看法,到时候要统一思想也是问题。

没岗位,比较难坚持,还是挺难撑下去的。

我之前在阿里,Ruby 写了 3 年,能用的项目少,各方面原因都有,后面不得不写一些其他的,比如 Java、Node.js


然后看你说的,难道你作为 Rails 工程师,不会前端么?

大厂后端对算法要求很高。很多地方都需要极致优化。

  1. 首先,是人家怎么看的问题 大家可能对后端的理解不一样,或者 hr 不是很理解 RoR 的工作方式。可能工作内容 ok,但别人没理解。面试什么,主要还是面试官说的算。。。

  2. 然后分布式个人经验来说,这个还是有用的。 我们被分布式数据库坑了两次,最后是了解了实现,才解掉。 不久前才刚跟同事扯时间戳没有办法保证时序(起因是我需要调用他的服务,我的业务需要有时序保证,他建议用时间戳,我跟他解释说时间戳帮助不大)。

    分布式会影响思考和解决问题的方式。想说的是有影响,但有没有意义,是不是好的影响,这就要看情况了。

    我们招聘对分布式没硬性要求,问到的情况也不多。

我三年前做过 1 年前端, 现在这个职位 (一个 10 个 rubyist 的团队) 几乎是纯 Ruby, 前端要求不高,也就刚开始过来的时候改了一下前端, 所以我个人认为自己做的是后端工作, 我会好好学和点满 js / typescript 外加 react 技能树的, leetcode 也刷了 2 百题以上了, 以后要两个语言一起刷。 现在想好了, 不受 HR 的分布式单词迷惑了, 也对自己在就业市场有个定位了解。

yfractal 回复

“不久前才刚跟同事扯时间戳没有办法保证时序”

可否解释下?

恩,是这样的。改数据的时候,数据库,要知道两次操作的先后顺序。

比如 put(a, 1) 和 put(a, 1) 这两个操作发生的先后顺序。

如果这两个请求先后发送到两个服务器上个,server0,server1。

如果 server1 的时间比 server0 慢的话,用时间戳的话,顺序可能就反了,数据就是错的。

服务器之间需要 ntp 之类的协议同步时间,这个是不准的,有可能会差 100ms(只是打比方)之类的,还不考虑时间配错了之类的。

具体的可以看,设计数据密集型应用 里有关于时间戳的说明。

简单来说,就是分布式场景下,使用时间戳,作为顺序是不可靠的。

不要怂,互联网大厂也没多少高深技术,水平和流程也挺差的

如果你有做自由职业/独立开发/创业的规划,那么 Rails 最好还是不要丢掉

非常认同炮哥这句话。

yfractal 回复

分布式为了保证时序的策略通常有:

  1. Lamport 逻辑时钟,或它的各种衍生逻辑时钟。CockroachDB 用的这种策略。
  2. 原子钟提供的绝对时间。google spanner 用了原子钟的绝对时间策略。TrueTime
  3. 有个中心节点负责顺序,用单调递增函数来保证顺序。所有其他节点做任何事情之前,要先和它沟通,要一个 sequence number。TiDB 好像用的是这种策略。
xiaoronglv 回复

恩,是的 👍

其实这个场景,比较合适的是 compare and set,设置之前,先查,之后掉 comap and set,失败了就重试,好处就是实现简单。

或者那个服务把查询请求代理到我这。

rails 工程师想去大厂还是得多网络社交。。。

所以真去做前端了?

Github 一直是用 ruby 做后端。哪里来的虚假消息说用 go 做后端 ,没有证据不要乱说好吗。

SunA0 回复

没要我。 水平不行。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册