的确sde已经没坑了，网站稳定性工程师西雅图地区还有坑。上周去参加了onsite面试，他们西雅图的办公室在5楼，但是号码是6开头的，是600，马上要到面试时间了，紧张得让我找了半天。面试题都是原题，我是参考血洗的确公司那位大哥的帖子准备的，受益很多，这是我找的总结比较好的资料
总共四轮。
第一轮是验证python indentation. follow-up1: 在每行后面有个#评论，你怎么处理这种情况，不需要考虑空行或者整行是评论的。 follow-up2：如果匹配control block，比如上一行是if，下一行就得是else if or else。我当时没时间了，只考虑了最简单的情况，if else.
第二轮是mincost from root to leaf. follow-up1: 用dfs遍历，能不能提前退出？ follow-up2: 记忆化搜索。
第三轮上机题。query recommendation这道题。大家下去后一定多写写test case，我当时去之前写好后，测了一个test case过了，结果当时到那边一个都过不了。debug了60分钟，心想要胡了。这时候突然另一个公司给我发offer了，心情一下大好，然后突然灵光一闪，发现bug在哪里了，立马修正。最后十三个case，通过了十二个。
第三轮troubleshooting。三个数据中心那道题，有两个数据中心有 user servcie, user webapp, db relica. 一个主数据中心只有primay db and db relica。你读只能从各自地区的replica读，写只能往主要的db写。问题是全球的用户都不能登录。先锁定肯定是主数据中心出错了。分析时就从最简单的情况开始，比如那台机器死掉了，断电了，安装什么软件让数据库挂了等等。接下来分析user service能不能正确接收到请求，你可以用自己的账号尝试去登录。接受请求后，面试官返回的结果是不能登录，超时了。然后你想为什么超时，你就去模仿user sercie具体那个登录的function。另外一点，就是那个主数据库是能读也能写，问题的发生是在凌晨（想想凌晨会发生啥事啊）。模仿后，发现你能从relica读数据，也能把session写进去主数据库，但是发现之后还是登录不了。最后发现的问题就是你的session信息虽然写进去主数据库了，但是relica没有及时得更新，导致有15分钟延迟。分布式数据库如果保持relica同步，请google。我当时是不懂，直接问面试官的，面试官也挺友好得讲了下原理。然后去主数据库那台机器，发现在做backup，导致它没空去及时写最新的更新去一个log file。但是正常情况下，backup不应该在主数据中心做，只能在slave做。这种情况为啥会发生呢？原因就是以前把主数据中心和slave替换时，忘了换回来了。导致本应该在slave做backup呢，变成在主数据库做backup了。最后的问题是接下来你会做什么？比如在他们backup的script里加入check 现在这台机器是不是slave，然后在做backup，比如发生情况了，及时发邮件通知，而不是等着客服收到用户的举报电话才知道问题发生了。