Amazon Applied Scientist 面試全流程複盤：五輪 Loop + LP

Amazon 的 Applied Scientist（AS）職位面試有個鮮明特點：幾乎每一輪都會插入 Leadership Principles（LP）行為題，光靠刷題和啃機器學習理論是不夠的，必須提前打磨幾個能被隨意深挖細節、追問到底的真實專案故事。下面按流程拆解各輪考察重點，L4/L5/L6 在行為面試上的權重差異也會一併說明，其他職位方向同樣能參考。需要 VO輔助或 VO代面的同學，也可以照著這份複盤對齊節奏。

AS 面試流程概覽

階段	時長 / 形式	核心考察
電話面	45–60 分鐘	一道 LeetCode 難度演算法 + ML 基礎問答 + 1–2 道 LP
Onsite 第一輪	Coding + LP	資料處理題（雜湊表 + 手寫堆）+ 業務開放題
Onsite 第二輪	Case Study + LP	最佳化理論手寫 + 作業研究建模 + 系統設計
Onsite 第三輪	純 Coding + Ownership	OOD 物件導向設計
Onsite 第四輪	ML Application + LP	ML 系統設計（HM 主持）
Onsite 第五輪	Bar Raiser	Leadership Principles 總攻

一個貫穿始終的規律：每一輪基本都會留出約 15 分鐘問一到兩個行為題，所以 LP 準備絕不能只壓到最後一輪。

電話面：演算法 + ML 基礎的組合拳

Phone Screen 是進 Onsite 的門檻，通不過 Recruiter 就不會繼續排後面的 Loop。這一輪的配方通常是：一道 LeetCode 難度的演算法題，加機器學習基礎知識問答，外加一兩個 LP 行為題當調味。

面試官往往會順著履歷專案往深處挖，常見考點包括：

資料嚴重不平衡時怎麼處理，評估該用 Precision / Recall / F1 還是 ROC-AUC
SFT 訓練流程和 Loss 設計
Bias-Variance 如何權衡，過擬合怎麼判斷、怎麼治
Bagging 和 Boosting 的本質區別

真正拉開差距的是這道情境選擇題：給定不同的分類任務，Logistic Regression、Decision Tree、Random Forest、DNN 該怎麼挑？光背模型特點不夠，還得結合資料量、特徵類型、非線性程度、可解釋性要求和推論成本這幾個維度綜合判斷，講出取捨邏輯才算過關。

BQ 環節固定兩道，且都會被繼續往技術細節裡追問（當時發現了什麼問題、怎麼定位的、為什麼選這個方案、結果如何量化）：

一次主動接下職責外的任務，事後才發現自己經驗不足的經歷
一次靠深入分析揪出問題根因並解決的經歷

這提示一個關鍵點：準備專案和 BQ 故事時不能只背 STAR 框架的空殼，技術原理、方案對比和最終的量化結果都要一起理順，否則追問兩輪就露餡。

Onsite 第一輪：Coding + LP

兩位 Senior AS 面試官聯合面試。流程是自我介紹 → 專案細節深挖（為什麼這麼選）→ 結合你的研究方向和職位業務方向做聯想。這一輪追問深度不如電話面。

兩道 BQ：如何應對緊迫的 deadline，如何做到刨根問底（Dive Deep）。之後會拋一個業務開放題——不用寫程式碼，只講思路：做交易類業務時哪些 feature 最關鍵，怎麼用機器學習篩出容易導致 deal 失敗的那些特徵。

編碼題：活躍度最低的 K 個使用者

給一批日誌資料，每條是 (user_id, timestamp)。算出每個使用者在指定時間段內的活躍天數（去重後的日期數），找出活躍度最低的 5 個使用者。

表面看是雜湊表計數的簡單題，但面試官會追加約束——資料量極大時如何做記憶體最佳化。最佳解是雜湊表配合最小堆：遍歷一遍統計每個使用者的活躍天數集合大小，再用一個大小為 K 的最小堆維護「目前活躍度最低的 K 個」。而且現場禁用 heapq，要求手寫堆結構和上浮 / 下沉調整邏輯。

思路拆解：

用雜湊表 user -> set(day) 去重統計每個使用者的活躍天數；只保留計數，day 集合可邊掃邊丟以省記憶體。
維護一個最小堆，堆裡放 (活躍天數, user)。要找「最低的 K 個」，最直接的做法是全量建堆再彈出 K 個；若記憶體吃緊，可反向用「大小為 K 的最大堆」邊掃邊淘汰較大值，把空間壓到 O(K)。

class MinHeap:
    """手寫最小堆，按元素第 0 位（count）比較。禁用 heapq 時使用。"""

    def __init__(self):
        self.data = []

    def _swap(self, i, j):
        self.data[i], self.data[j] = self.data[j], self.data[i]

    def push(self, item):
        self.data.append(item)
        self._sift_up(len(self.data) - 1)

    def pop(self):
        top = self.data[0]
        last = self.data.pop()
        if self.data:
            self.data[0] = last
            self._sift_down(0)
        return top

    def _sift_up(self, i):
        while i > 0:
            parent = (i - 1) // 2
            if self.data[i][0] < self.data[parent][0]:
                self._swap(i, parent)
                i = parent
            else:
                break

    def _sift_down(self, i):
        n = len(self.data)
        while True:
            left, right, smallest = 2 * i + 1, 2 * i + 2, i
            if left < n and self.data[left][0] < self.data[smallest][0]:
                smallest = left
            if right < n and self.data[right][0] < self.data[smallest][0]:
                smallest = right
            if smallest == i:
                break
            self._swap(i, smallest)
            i = smallest

    def __len__(self):
        return len(self.data)


def least_active_users(logs, k=5):
    """logs: List[(user_id, timestamp)]；timestamp 為秒級 epoch。
    返回活躍天數最低的 k 個 user_id。"""
    day_sets = {}
    for user, ts in logs:
        day = ts // 86400                 # 歸一到「天」
        day_sets.setdefault(user, set()).add(day)

    heap = MinHeap()
    for user, days in day_sets.items():
        heap.push((len(days), user))      # (活躍天數, user)

    result = []
    for _ in range(min(k, len(heap))):
        count, user = heap.pop()
        result.append(user)
        _ = count
    return result

時間複雜度：統計 O(N)，建堆並彈出 K 個為 O(M + K log M)，M 為使用者數、N 為日誌條數。空間複雜度：O(M)。若記憶體吃緊，可把最小堆換成「維護大小為 K 的最大堆」，邊掃邊淘汰，空間壓到 O(K)。

Onsite 第二輪：Case Study + 最佳化理論（Principal AS 技術面）

這輪先從專案深挖切入，再轉向最佳化理論的硬核考察：

手寫梯度下降，講清學習率、收斂條件、停止標準
手寫 KNN，討論距離度量方式、K 值選擇和查詢複雜度
牛頓法的原理，與梯度下降在收斂速度和計算成本上的差異
為什麼凸最佳化問題更容易求全域最優，哪些問題有閉式解
原問題與對偶問題的關係，KKT 條件包含哪些內容、適用場景

這裡給一份現場可手寫的梯度下降參考實作，用最基礎的線性迴歸 MSE 作載體：

import numpy as np


def gradient_descent(X, y, lr=0.01, max_iter=1000, tol=1e-6):
    """最小化 MSE 的批次梯度下降。
    X: (n, d)，y: (n,)。返回權重 w 與偏置 b。"""
    n, d = X.shape
    w = np.zeros(d)
    b = 0.0
    prev_loss = float("inf")

    for it in range(max_iter):
        pred = X @ w + b
        error = pred - y
        loss = np.mean(error ** 2)                 # MSE

        grad_w = (2.0 / n) * (X.T @ error)         # 對 w 的梯度
        grad_b = (2.0 / n) * np.sum(error)         # 對 b 的梯度

        w -= lr * grad_w
        b -= lr * grad_b

        if abs(prev_loss - loss) < tol:            # 收斂：損失不再顯著下降
            break
        prev_loss = loss

    return w, b

時間複雜度：每輪 O(n·d)，共 T 輪為 O(T·n·d)。停止標準通常是「損失變化 < tol」或「達到最大迭代數」，學習率過大會震盪不收斂、過小則收斂太慢。

緊接著是一道作業研究最佳化建模題：為配送中心設計補貨計畫，在需求、供應量、倉儲容量約束下最小化運輸和庫存成本，Follow-up 追問商品動態加價時目標函數和最優策略如何變化。

Case Study 部分是設計一套生鮮配送系統，同時解決車輛路徑規劃和到達時間預測，要考慮即時交通、時間窗口、保存期限和車輛容量限制。追問會落到模型訓練和評估上——路徑最佳化關注總里程、成本、準時率；時間預測則用 MAE、RMSE 和延遲訂單比例衡量，Precision / Recall 在這個場景並不適用，需要現場辨析清楚。最後收尾在三維裝箱問題：給定貨物尺寸、重量和卡車空間，如何擺放提升裝載率，同時滿足承重、方向、堆疊約束。

Onsite 第三輪：純 Coding（穿插一道 Ownership 行為題）

面試官簡單問了一道關於 Ownership 的行為題後直接進入編碼。題目是 OOD 設計——一個物品租賃系統，需要實作 Item、User、Rental 等實體類別，透過 Manager 類別提供借出、歸還、查詢介面。

題目本身難度不高，考察重點在於類別的職責劃分是否清晰、物件關係是否合理、程式碼是否留有擴充空間。Follow-up 層層加碼：增加租賃到期時間和逾期罰金邏輯、支援按名稱模糊搜尋、提供返回完整目錄的介面、以及如何設計單元測試。整體考的是物件導向建模能力和介面設計，不是演算法技巧。

from dataclasses import dataclass
from typing import Dict, List, Optional


@dataclass
class Item:
    item_id: int
    name: str
    available: bool = True


@dataclass
class User:
    user_id: int
    name: str


@dataclass
class Rental:
    item_id: int
    user_id: int
    due_day: int
    returned_day: Optional[int] = None


class RentalManager:
    """租賃系統入口：借出、歸還、搜尋、目錄、逾期罰金。"""

    LATE_FEE_PER_DAY = 5

    def __init__(self):
        self.items: Dict[int, Item] = {}
        self.users: Dict[int, User] = {}
        self.rentals: List[Rental] = []

    def add_item(self, item: Item) -> None:
        self.items[item.item_id] = item

    def add_user(self, user: User) -> None:
        self.users[user.user_id] = user

    def borrow(self, user_id: int, item_id: int, due_day: int) -> bool:
        item = self.items.get(item_id)
        if item is None or not item.available or user_id not in self.users:
            return False
        item.available = False
        self.rentals.append(Rental(item_id, user_id, due_day))
        return True

    def give_back(self, user_id: int, item_id: int, today: int) -> int:
        """歸還並返回應繳逾期罰金（未逾期為 0）。"""
        for r in self.rentals:
            if r.item_id == item_id and r.user_id == user_id and r.returned_day is None:
                r.returned_day = today
                self.items[item_id].available = True
                overdue = max(0, today - r.due_day)
                return overdue * self.LATE_FEE_PER_DAY
        raise ValueError("沒有匹配的未歸還租賃記錄")

    def search(self, keyword: str) -> List[Item]:
        kw = keyword.lower()
        return [it for it in self.items.values() if kw in it.name.lower()]

    def catalog(self) -> List[Item]:
        return sorted(self.items.values(), key=lambda it: it.item_id)

設計要點：Manager 持有實體的字典索引以支援 O(1) 查找；借出 / 歸還只翻轉 available 標誌並追加記錄，便於後續擴充預約佇列、多副本庫存等。逾期罰金用 due_day 與歸還日的差值計算，介面保持單一職責，方便寫單元測試。

Onsite 第四輪：ML Application + LP（Hiring Manager 主持）

偏機器學習系統設計，題目圍繞廣告推薦、CTR 預估等真實業務場景。回答建議按固定順序展開：需求釐清 → 資料與特徵 → 模型選型 → 訓練與離線評估 → 線上部署 → 監控與 A/B 測試。

注意：L4 候選人不一定會被安排這一輪。這輪考察的是 ML 知識的廣度，涵蓋範圍可以從線性迴歸一路延伸到 Transformer，常見考點包括 L1 / L2 正則化、過擬合、梯度消失、損失函數設計和 Transformer 原理。複習時別只背定義，要能講清楚每個方法的適用場景和優缺點，面試官很愛追問「什麼時候不該用這個」。

Onsite 第五輪：Bar Raiser（LP 總攻）

這輪由不屬於招聘團隊的 Bar Raiser 主持，專注考察 Leadership Principles，對最終是否發 Offer 的影響力很大。但要清楚一點：前面每一輪基本都會留出約 15 分鐘問一到兩個行為題，所以 LP 準備絕不能只留到最後一輪才做。

L4 / L5 / L6 行為面權重差異

級別	LP 深度	側重的 LP 維度
L4	講清楚一次完整經歷即可，追問一層	Learn and Be Curious、Ownership
L5	需要體現跨團隊協作與技術決策，追問兩到三層	Dive Deep、Deliver Results、Earn Trust
L6	要求戰略視野、影響力和帶人帶專案	Think Big、Have Backbone、Hire and Develop

級別越高，面試官越想看到你在更大範圍內的影響力和面對分歧時的判斷力，故事的量級和複雜度要相應升級。

備考建議

專案故事技術化：每個 STAR 故事都要能被追問兩三層——發現了什麼、怎麼定位、為什麼選這個方案、結果如何量化，技術原理和資料結果一起理順。
手寫基礎演算法：梯度下降、KNN、堆結構要能現場從零手寫，不能依賴 heapq、sklearn 這類函式庫。
ML 廣度 + 取捨：模型選型題重在講清「什麼時候不該用」，結合資料量、可解釋性、推論成本作答。
LP 涵蓋全 Loop：準備 8–10 個可複用故事，涵蓋 Ownership、Dive Deep、Deliver Results 等核心維度，因為每輪都會問。
最佳化理論：凸最佳化、對偶、KKT、牛頓法這些偏理論的點，AS 職位會真考，別只停在會用框架的層面。

FAQ

Q1：Amazon AS 面試和 SDE 面試最大的區別是什麼？

AS 在演算法之外額外考 ML 基礎、最佳化理論和 ML 系統設計，且行為題會往技術細節深挖。SDE 更偏純演算法與系統設計，ML 理論佔比很低。AS 候選人必須同時準備 Coding、ML 理論和 LP 三條線。

Q2：電話面的演算法題難度如何？

通常是一道 LeetCode 中等偏難的題，外加 ML 基礎問答和 LP。演算法本身不會特別刁鑽，但會追加記憶體最佳化、手寫資料結構等約束，考的是你能否在壓力下把最佳解講清楚並實作。

Q3：Applied Scientist 每一輪都會問行為題嗎？

基本是的。除了 Bar Raiser 專攻 LP，前面每一輪都會留 10–15 分鐘問一到兩個行為題。所以 LP 準備要貫穿整個 Loop，不能只壓到最後一輪。

Q4：L4、L5、L6 在面試上有什麼不同？

級別越高，行為面越看重跨團隊影響力、戰略視野和帶人帶專案的經歷，追問層數更多；技術面則期待更成熟的系統設計和更深的理論掌握。L4 可能不安排 ML 系統設計專場，L5/L6 通常會有。

Q5：現場禁用 heapq 之類的函式庫怎麼辦？

提前把最小堆 / 最大堆的上浮、下沉邏輯手寫練熟，梯度下降、KNN 也要能從零實作。面試官禁用函式庫就是想看你對底層資料結構和演算法的真實掌握，背 API 沒用。

正在準備 Amazon Applied Scientist 或其他 ML / AS 職位的 VO？ 我們熟悉 AS 這類「演算法 + ML 理論 + 最佳化 + LP」多線並考的 Loop 打法，能陪你把專案故事技術化、手寫演算法和 LP 涵蓋一次打磨到位，提供全程 VO輔助與 VO代面支援。

立即加入微信 Coding0201，取得一對一客製備考方案。

聯絡方式

微信：Coding0201
Email：[email protected]
Telegram：@OAVOProxy