面試題解析 第 11 頁，共 52 頁
瀏覽 OfferCC 面試題解析第 11 頁，查看解題思路、實作細節、追問與公開來源。
Go 1.26 自我引用型別約束如何設計可重用演算法？
圍繞 Go 1.26 放寬泛型型別參數列表自我引用限制，分析 F-bounded 約束、實例化檢查、遞迴型別邊界和相容性測試。
系統設計面試題：設計支援快照與壓縮的事件日誌
設計可追加、可重播、可復原的事件日誌，明確順序、分割、快照、鍵級壓縮、保留策略、消費者進度與並發寫入邊界。
行為面試：沒有正式權力時，你如何提出高風險異議？
用事實、升級閾值和可逆行動表達風險，在心理安全與責任閉環之間取得平衡。
前端面試：如何用 Atomics.waitAsync 協調 Worker 並支援取消
圍繞 SharedArrayBuffer 設計非阻塞等待協定，說明 waitAsync、notify、逾時、取消與相容性降級。
後端面試：如何在不中斷服務的情況下輪換 Webhook 密鑰？
設計重疊驗簽、版本化發布、重放防護與回滾，確保 Webhook 密鑰輪換沒有驗證空窗。
資料科學面試：為什麼調整處理後變數會造成實驗偏差？
用因果圖與處理前估計量解釋：過濾由處理導致的行為會破壞實驗的隨機化保護。
產品經理面試：如何設計客戶顧問委員會？
建立能把客戶意見轉化為可驗證產品決策的顧問機制，避免淪為 VIP 願望清單。
通用面試：如何設計 Oblivious HTTP 的 Relay 與 Gateway？
基於 RFC 9458 設計 OHTTP 的客戶端、Relay、Gateway 與目標服務邊界，涵蓋 HPKE 封裝、重放防護、流量分析、金鑰輪換和可觀測性。
程式設計面試題：實作公平且可取消的信號量
用等待佇列、permit 不變量、FIFO 公平策略、逾時與取消清理，實作不會丟失喚醒、重複發放 permit 或讓取消請求永久占位的信號量。
系統設計面試：設計多租戶 Consent Receipt Ledger
設計可稽核、可撤回、可隔離的多租戶同意記錄帳本，涵蓋版本、傳播、完整性與保留策略。
行為面試：講一次你如何負責任地披露安全漏洞
用 STAR 說清漏洞證據、風險分級、最小披露、升級路徑與修復後的複盤。
前端面試：CSS zoom 與 transform: scale 如何選擇？
比較 CSS zoom 和 transform 縮放對版面、溢出、座標測量與無障礙的影響，並說明如何用 currentCSSZoom 除錯巢狀縮放。
後端面試：如何用 ETag 與 If-Match 防止遺失更新？
設計帶有強驗證器、412 回應、重試與快取語意的 HTTP 樂觀並行控制契約。
資料科學面試：如何發現實驗中的倖存者偏差？
先稽核分母、分派與缺失結果，再判斷只在留存使用者中出現的提升是否可信。
產品經理面試：B2B SaaS 是否應該提供客服代入使用者功能？
用客戶價值、風險邊界與可稽核控制評估 support impersonation，提出分階段上線與衡量方案。
通用面試：如何部署 TLS Encrypted ClientHello 並處理相容性？
從 RFC 9849 的 inner/outer ClientHello、ECHConfig 與重試機制出發，設計保護 SNI 隱私、可觀測且可回退的部署方案。
編碼面試：如何實作一個隨機可合併堆？
實作隨機可合併最小堆，說明 meld 不變量、隨機分支、期望複雜度、重複鍵、所有權與遞迴堆疊邊界。
系統設計面試：如何設計全域配額策略控制面？
從策略發布、全域限流、租戶隔離、一致性、故障模式和可觀測性設計跨閘道的配額控制面。
行為面試：請分享一次你協調衝突利害關係人需求的經歷
用 STAR 說清楚如何把不同團隊立場轉成共同目標、可驗證的取捨與書面承諾，並區分真正協商與單純妥協。
前端面試：如何用 CSS shape() 做響應式裁切並安全降級？
解釋 shape() 與 path()、polygon() 的差異，設計 clip-path 的漸進增強、可存取性和瀏覽器驗證方案。
後端面試：如何用 RFC 9457 統一 HTTP API 錯誤？
從狀態碼、Problem Details 媒體類型、錯誤類型 URI 與欄位脫敏出發，設計可演進的 API 錯誤契約。
資料科學面試：如何發現並解決辛普森悖論？
解釋聚合實驗結果為何會與分組結果反轉，並選擇分層、隨機化或因果調整方法。
產品經理面試：B2B SaaS 是否應提供用量計費價格計算器？
用客戶決策任務、計量可信度、估算假設與護欄判斷用量計費價格計算器是否值得上線。
通用面試：如何選擇聯邦身分的 FAL1、FAL2 與 FAL3？
使用 NIST SP 800-63C 的 Federation Assurance Level 評估斷言注入、持有者綁定、隱私與恢復邊界，避免把 FAL 當成單一認證強度。