上周刚面完 Google 的一轮远程技术面，现在还心有余悸。作为一名在湾区卷了多年的华人码农，本以为对各种算法题型早已刀枪不入，但当面试官在共享文档上悠悠地敲出那道题时，我还是结结实实地捏了一把汗。 它没有考什么高深的动态规划，也不是复杂的图论，而是一个我们生活中再熟悉不过的场景。 面试题的原文如下： Implement a restaurant waitlist data
如果用一个词形容亚麻的SDE面试，那就是“窒息感”。刚结束的这场远程面试，一位语速飞快的印度小哥，从头到尾没给我半点喘息的机会。没有多余的寒暄，直接就甩给我一个大部头的系统设计题，感觉大脑的CPU瞬间被拉满。 面试开始没几句寒暄，直接就甩给我一个大部头的系统设计题。 “Design a scalable API Rate Limiter.” 面试官希望我设计一个可扩展的API请求速率限制器。这题算是老朋友了，但亚麻问得非常深，完全不是背模板就能过的。我先稳住心神，确认了几个关键的设计目标，比如要支持按用户或IP进行限制，并且延迟要做到毫秒级，还要保证高可用和高扩展性，轻松应对上万QPS的流量。我的核心思路是围绕Redis集群和令牌桶算法来构建。当请求进来时，不是直接放行，而是先向“桶”里申请一个“令牌”。我跟面试官解释了如何利用Redis的原子操作，特别是通过Lua脚本来保证“取令牌”和“更新时间戳”这两步的原子性，避免并发场景下的数据不一致问题。我还详细设计了Redis里的key格式，例如 ratelimit:{api_id}:{user_id}，以及里面存储的字段，包括当前剩余的令牌数和上次补充令牌的时间。整个过程像是在白板上和同事讨论技术方案，感觉他对我这种抽丝剥茧、主动沟通的风格还比较满意。
最近刚结束了亚麻（Amazon）SDE岗的远程面试，脑细胞阵亡无数。作为在科技大厂求职路上苦苦挣扎的同胞，深知一份热乎乎的面经有多重要，所以赶紧把这次的题目和一些个人感悟码出来，希望能给正在备战或者未来要面试亚麻的小伙伴们一点小小的参考，主打就是一个信息共享，少走弯路！这次面的是New Grad岗位，整体感觉亚麻还是挺看重候选人的思考深度和代码基本功的。 面试第一轮上来通常少不了一些行为问题（BQ）热身，面试官小哥语速适中，氛围还算轻松。他先问了： q1: realize a deeper level for your