行為面試、CTO 對談與反問

Appier 面試流程與每關重點 高頻

履歷準備：後端實習履歷怎麼寫 高頻 基礎

履歷是技術面試的「題目卷」——面試官 30–45 分鐘的深挖幾乎都從你的履歷出發。寫上去的每一個技術名詞，都要準備好被問「為什麼用它、它怎麼運作、遇到什麼問題」。

結構（一頁為原則）

1. Header：姓名、Email、電話、GitHub、LinkedIn、（可選）個人網站。
2. Summary（可選，2 行）：例如「Backend-focused CS student experienced in Python/Go services, PostgreSQL and Redis; built an event-tracking service handling 2k RPS in load tests.」
3. Education：學校、科系、預計畢業時間、（可選）相關課程：作業系統、計算機網路、資料庫、分散式系統。
4. Experience：實習、研究助理、接案、社團技術職。
5. Projects：2–3 個最能代表後端能力的專案，各 2–4 個 bullet。
6. Skills：分類列出，只寫你能被追問的。可分「熟練 / 使用過」。

Bullet 寫法：動詞 + 做了什麼 + 怎麼做 + 量化結果

• 量化：延遲（p95/p99）、吞吐（RPS、每天處理筆數）、成本、時間節省、錯誤率、使用者數、測試覆蓋率、image 大小。沒有正式 production 數字時，可用壓測數字並誠實標註（in load tests）。
• 強動詞：Designed, Implemented, Optimized, Reduced, Migrated, Automated, Diagnosed, Scaled。
• 凸顯職缺關鍵字：Linux、REST API、SQL/NoSQL、Redis、Docker、CI/CD、profiling、testing、observability——但必須是真的做過。
• 每個數字都要能解釋怎麼量的：「p95 從 480ms 降到 90ms」→ 面試官會問「怎麼量？在什麼負載下？瓶頸在哪？」

GitHub 與 side project 建議：做一個小型事件追蹤服務

如果缺乏實習經驗，最有效的補強是一個貼近 Appier 業務、能展示後端完整能力的 side project。建議題目：小型事件追蹤（event tracking）服務——模擬客戶端 SDK 回報大量 JSON 事件、後端收集並產生統計報表（這也正是網路分享中出現過的系統設計題）。

專案清單（每一項都是面試可以深挖的話題）：

• API 設計：批次上報、schema 驗證、idempotency key（event_id 去重）、限流、回傳 202 Accepted。
• 非同步處理：Redis Streams 或 Kafka，consumer group、at-least-once 語意與冪等寫入。
• 儲存與查詢：原始事件表 + 預聚合表，索引設計，UV 用 HyperLogLog。
• 效能：用 k6 / Locust 壓測，記錄 RPS 與 p99，用 py-spy / pprof 找瓶頸並優化，寫進 README（前後對比）。
• 工程品質：pytest（單元 + 整合用 testcontainers / compose）、GitHub Actions CI、multi-stage Dockerfile、docker compose 一鍵啟動、K8s manifests（可選）。
• 可觀測性：結構化 log、Prometheus metrics、健康檢查端點、graceful shutdown。
• README：架構圖、設計決策與取捨、壓測結果、已知限制與下一步。面試官很可能只看 README 兩分鐘。

# 範例：事件收集 API 的核心（展示批次、驗證、去重、非同步寫入的思路）
from datetime import datetime, timezone
from typing import Any
from uuid import UUID

import redis.asyncio as redis
from fastapi import FastAPI, HTTPException, status
from pydantic import BaseModel, Field

app = FastAPI()
r = redis.from_url("redis://localhost:6379/0")

class Event(BaseModel):
    event_id: UUID                       # client 產生，用於去重（重試不會重複計數）
    app_id: str = Field(min_length=1, max_length=64)
    name: str = Field(max_length=64)
    user_id: str | None = None
    ts: datetime
    props: dict[str, Any] = {}

class Batch(BaseModel):
    events: list[Event] = Field(min_length=1, max_length=500)

@app.post("/v1/events", status_code=status.HTTP_202_ACCEPTED)
async def ingest(batch: Batch) -> dict[str, int]:
    now = datetime.now(timezone.utc)
    accepted = 0
    async with r.pipeline(transaction=False) as pipe:
        for e in batch.events:
            # SET NX 做 24 小時去重窗口；重送的 event_id 會回傳 None
            pipe.set(f"dedup:{e.event_id}", 1, nx=True, ex=86400)
        results = await pipe.execute()
        for e, is_new in zip(batch.events, results):
            if is_new:
                pipe.xadd("events", {"data": e.model_dump_json(), "recv_ts": now.isoformat()},
                          maxlen=1_000_000, approximate=True)
                accepted += 1
        await pipe.execute()             # 第二輪：只把新事件寫入 stream，由 consumer 批次落地 DB
    # 取捨（面試好題材）：若第二輪失敗，事件已被標記為「見過」卻沒寫入 → 會遺失。
    # 改進方向：用 Lua script 讓「SET NX + XADD」原子化，或把去重移到 consumer 端以 DB unique key 處理。
    return {"accepted": accepted, "duplicates": len(batch.events) - accepted}

自我介紹範本：中文與英文、1 分鐘與 3 分鐘 高頻

自我介紹的目的不是背履歷，而是引導面試官接下來想問的方向。結構：我是誰 → 我做過最相關的事（1–2 個亮點 + 數字）→ 我為什麼在這裡（為什麼 Appier / 這個職位）。結尾留一個「鉤子」讓面試官想追問你最有把握的專案。

中文 1 分鐘版（約 250–300 字）

中文 3 分鐘版的擴充方式

• 背景（30 秒）：為什麼走後端——例如「修作業系統和網路課時發現自己喜歡理解系統底層怎麼運作」。
• 亮點一（60 秒）：最自豪的專案，講問題、你的角色、關鍵技術決策、量化結果。
• 亮點二（45 秒）：團隊合作或實習經驗，展示協作、code review、處理線上問題。
• 學習方式（20 秒）：例如「最近在讀 Designing Data-Intensive Applications，把書中的 log-structured storage 概念對照到我專案中的 Redis Streams」。
• 為什麼 Appier + 可投入時間（25 秒）。

English 1-minute version

English 3-minute version（骨架）

1. Who I am (20s)
   "I'm ..., a ... student. I got into backend engineering when I took the OS course
    and realized I enjoy understanding what happens under the hood."

2. Highlight #1 – technical depth (70s)
   "The project I'm most proud of is ... The problem was ... I was responsible for ...
    The key decision was choosing X over Y because ... The result was ... (numbers)."

3. Highlight #2 – teamwork / real users (50s)
   "During my internship at ..., I worked with two other engineers on ...
    One challenge was ... I handled it by ... I learned ..."

4. How I learn (20s)
   "Recently I've been reading ... and applying it to ..."

5. Why this role (20s)
   "I'm excited about Appier because ... I can commit ... days a week for ... months."

STAR / STAR-L 回答方法 高頻 基礎

行為題（「說一次你……的經驗」）的潛台詞是：過去的行為是未來行為最好的預測。面試官要的是一個具體、真實、有你個人行動的故事，而不是「我通常會……」的空泛原則。

S — Situation（10–15%）

背景：什麼專案、什麼時間點、團隊規模、為什麼重要。一兩句就好。

T — Task（10%）

你的責任或目標是什麼，困難點在哪。

A — Action（50–60%）

你做了什麼（用「我」不是「我們」）、為什麼這樣做、考慮過哪些選項。這是重點，要有技術細節與決策理由。

R — Result（15%）

量化結果、影響、別人的回饋。結果不好也可以，誠實說明。

L — Learning（10%）

學到什麼、之後怎麼應用、如果重來會怎麼做。這一步是區分「做過」與「反思過」的關鍵，Appier 這種重視學習能力的公司特別看重。

建立你的故事庫（6–8 個故事對應多種題型）

不要每題準備一個故事，而是準備 6–8 個「多用途」故事，每個故事可以從不同角度切入不同題目：

完整 STAR-L 範例：「說一次你解決困難技術問題的經驗」

「最自豪的專案」深挖準備法 高頻 深入

這是 Appier 面試中被分享最多次的題目，而且通常不是一題，而是一連串 20–40 分鐘的追問，可能從架構一路問到某一行程式碼為什麼這樣寫、資料量放大 100 倍會怎樣。你要準備的是一份「專案檔案」：

1. 一句話描述：「這是一個 ___，解決 ___ 的問題，給 ___ 使用。」
2. 架構圖：能在白板或共享螢幕上 1 分鐘畫出：client、API、queue、worker、DB、cache、外部服務，以及資料流向。標註你負責的部分。
3. 規模與數字：使用者數、QPS、資料量、延遲、團隊人數、開發時間。沒有的就說壓測數字或估算，並說明怎麼得來。
4. 技術選型理由：每個元件「為什麼選它、考慮過什麼替代方案、取捨是什麼」。例如為什麼 PostgreSQL 不是 MongoDB、為什麼 Redis Streams 不是 Kafka。
5. 最難的問題：1–2 個具體的技術難題，描述症狀 → 排查過程 → 根因 → 解法 → 驗證。這是最能展現深度的部分。
6. 量化成果：前後對比。
7. 如果重做會怎麼改：展示反思與成長。例如「一開始沒有做冪等，後來重試造成重複資料；重做的話第一天就設計 idempotency key」。
8. 擴展性思考：流量 ×10、×100 時哪裡會先壞？怎麼改？
9. 可靠性與維運：怎麼測試、怎麼部署、怎麼監控、出過什麼事故。

面試官可能的 20 個追問（請逐一寫下答案）

1. 這個專案要解決什麼問題？誰在用？沒有它的時候大家怎麼做？
2. 請畫出整體架構，資料怎麼流動？
3. 你個人負責哪些部分？哪些是別人做的？
4. 為什麼選這個語言 / 框架？如果用 Go（或 Java）會有什麼不同？
5. 為什麼選這個資料庫？schema 怎麼設計？有哪些索引？為什麼？
6. 最慢的查詢 / API 是哪一個？為什麼慢？你怎麼知道的？
7. 遇到最難的 bug 是什麼？花了多久？怎麼找到根因的？
8. 效能數字是怎麼量的？在什麼負載、什麼機器規格下？p50 和 p99 差多少？
9. 如果流量變成 100 倍，哪裡會先撐不住？你會怎麼改？
10. 如果資料量到上億筆，現在的設計還行嗎？（Appier 真的問過類似問題）
11. 服務掛掉時會發生什麼？資料會不會遺失或重複？怎麼保證？
12. 有做快取嗎？快取失效、一致性怎麼處理？
13. 並行（concurrency）怎麼處理？有沒有 race condition？
14. 怎麼測試？測試覆蓋哪些情境？有整合測試嗎？
15. 怎麼部署？怎麼回滾？有 CI/CD 嗎？
16. 怎麼監控？出問題你怎麼知道？
17. 安全性：認證、授權、輸入驗證、secret 管理怎麼做？
18. 如果重做一次，你會改什麼？
19. 過程中和隊友有過什麼分歧？怎麼解決的？
20. 從這個專案學到最重要的一件事是什麼？

常見行為題題庫（28 題，含回答框架） 高頻

每題附「考察重點」與「回答要點」。用你的故事庫套入 STAR-L，不要背誦範文。

團隊合作與衝突

失敗、壓力與責任

學習能力與自學

主動性與 ownership

時間管理與優先順序

動機與自我認識

英文面試準備 高頻 進階

依網路分享，VP of Engineering 那一關會確認英文能力。目標不是講得像母語人士，而是能清楚、有結構地表達技術內容，聽不懂時能有效澄清。面試官通常更在意溝通的有效性而非文法完美。

常用句型

聽不懂時如何澄清（非常重要）

• "Sorry, could you repeat the question?" / "Could you say that again a bit more slowly?"
• "Just to make sure I understand correctly — are you asking about X or Y?"（重述問題是最好的策略，同時確認範圍）
• "When you say 'scale', do you mean more users, more data, or more regions?"
• "Could you give me an example of what you mean?"
• 不懂某個字：「Sorry, I'm not familiar with the term '...'. Could you explain it?」——比猜錯然後答非所問好得多。

如何用英文解釋技術

1. 先講結論 / 一句話定義："A message queue lets services communicate asynchronously."
2. 再講為什麼需要："Without it, if the downstream service is slow, the upstream service has to wait."
3. 舉例："In my project, the API puts events into Redis Streams, and workers write them to the database in batches."
4. 取捨："The downside is added complexity and eventual consistency."

技術字彙要能自然說出：latency / throughput、bottleneck、trade-off、scalability、availability、consistency、idempotent、retry with exponential backoff、race condition、deadlock、cache invalidation、index、query plan、sharding、replication、load balancer、rollback、deployment pipeline、on-call、postmortem、root cause。

英文範例回答

CTO 技術觀點對談 進階 深入

依網路分享，CTO 關卡會聊「你對技術的看法」。這不是考試，沒有標準答案；CTO 想看到的是：你有沒有自己的觀點、觀點背後有沒有理由、是否理解取捨、是否持續思考與學習。一個好的觀點回答結構：立場 → 理由（2–3 點）→ 反面考量 / 何時不成立 → 我自己的實踐。

主題一：AI / LLM 對軟體開發的影響

主題二：如何做技術選型

主題三：技術債

主題四：Monolith vs Microservices

主題五：Python vs Go

主題六：你最近關注的技術

準備 1–2 個你真的有動手玩過的技術，講出：它解決什麼問題、原理大概是什麼、你試用的心得、適用與不適用的場景。可選方向（挑你有興趣的）：

• uv / Ruff：用 Rust 重寫 Python 工具鏈，為什麼快（平行下載、全域快取與硬連結、Rust 實作），對 CI 時間與 Docker build 的影響。
• eBPF：在 kernel 安全地執行程式，用於觀測（不改程式碼就能看到 syscall、網路延遲）、網路（Cilium）與安全。
• LLM serving：continuous batching、KV cache、量化如何影響延遲與成本（vLLM 等）。
• OpenTelemetry：統一 traces/metrics/logs 的標準，如何避免廠商鎖定。
• Python free-threading（PEP 703）：移除 GIL 的意義與挑戰（C extension 相容、單執行緒效能）。
• 資料湖表格式（Apache Iceberg / Delta Lake）：在 S3 上提供 ACID、schema evolution、time travel。

其他可能主題與一句話方向

「為什麼 Appier」「為什麼後端」「職涯規劃」 高頻

為什麼 Appier？

好答案 = 對公司的具體理解 + 與你的興趣/經驗的連結 + 你想在這裡獲得與貢獻什麼。避免「因為是知名新創 / 待遇好 / 離家近」。

為什麼選擇後端？

職涯規劃（3–5 年）

實習生的特別關注點 基礎

實習生面試和正職不同：面試官不期待你什麼都會，而是在評估「投資你是否值得」——你能不能穩定投入、學得快、不需要一直被盯、未來能否轉正。

Coding 面試溝通框架與白板技巧 高頻

Coding 面試評分的不只是答案對不對，還包含溝通、問題拆解、程式碼品質、測試意識。即使最後沒寫完，清楚的思考過程也能拿到不錯的評價；反之，沉默寫出正確答案的人可能被評為「難以合作」。

1. 釐清（1–3 分鐘）：輸入範圍與大小？可能為空嗎？有重複嗎？要原地修改嗎？回傳什麼？例如 Valid Parentheses：只有三種括號嗎？空字串算 valid 嗎？
2. 舉例：自己寫 2–3 個例子，包括邊界（空、單一元素、全部相同、極大值），並和面試官確認預期輸出。
3. 暴力解：先說出直覺解法與複雜度——「最直接的做法是……，時間 O(n²)」，讓面試官知道你至少有解。
4. 優化：說出瓶頸在哪、可以用什麼資料結構（hash map、stack、heap、two pointers、sliding window、DP）改善。得到面試官點頭再寫。
5. 寫碼：有意義的變數名、小函式、邊寫邊說明「這裡我在做什麼」。不確定的 API 直接說「我假設有一個……函式」。
6. 測試：寫完主動用例子逐行跑一次（dry run），檢查邊界與 off-by-one；能執行的平台就實際跑。
7. 複雜度與延伸：講時間與空間複雜度，並預想追問（資料大到放不進記憶體？要串流處理？要並行？）。

# 示範：LeetCode 678 Valid Parenthesis String（含 '*'，Appier 曾出過）
# 邊寫邊講的思路（中括號內是你要說出口的話）：
# [釐清] '*' 可以當 '('、')' 或空字串；只有 '('、')'、'*' 三種字元；空字串為 True。
# [暴力] 每個 '*' 三種選擇 -> O(3^k)，太慢。
# [優化] 維護「尚未配對的 '(' 數量」可能的範圍 [lo, hi]：
#        '(' -> lo+1, hi+1；')' -> lo-1, hi-1；'*' -> lo-1（當 ')'）, hi+1（當 '('）
#        hi < 0 代表即使把所有 '*' 當 '(' 也不夠 -> False；lo 不能小於 0（截斷）
#        最後 lo == 0 代表存在一種選法讓括號恰好配對。

def check_valid_string(s: str) -> bool:
    lo = hi = 0
    for ch in s:
        if ch == "(":
            lo += 1
            hi += 1
        elif ch == ")":
            lo -= 1
            hi -= 1
        else:  # '*'
            lo -= 1
            hi += 1
        if hi < 0:
            return False
        lo = max(lo, 0)
    return lo == 0

# [測試] 主動跑邊界案例
assert check_valid_string("") is True
assert check_valid_string("(*)") is True
assert check_valid_string("(*))") is True
assert check_valid_string(")(") is False
assert check_valid_string("((*") is False
# [複雜度] 時間 O(n)、空間 O(1)。也可以說出替代解：兩個 stack 存索引，O(n) 空間。

白板與線上平台溝通技巧

• 先講思路再寫碼，面試官可以在你走錯方向時提早提示；把提示當成合作而非扣分。
• 卡住時說出來：「我現在卡在如何處理重複元素，我在想是不是可以用 set……」，沉默是最糟的。
• 畫圖：樹、圖、指標移動、DP 表格，畫出來能幫你也幫面試官理解。
• 程式碼可讀性：避免 a、tmp2 這種變數；適度抽出 helper function。
• 時間分配（45 分鐘題）：釐清與設計約 10 分鐘、寫碼約 20 分鐘、測試與討論約 10 分鐘，留時間給追問。
• 追問模式：Appier 曾有「graph DFS → backtracking → 能否用 DP 優化」、「能否把遞迴改掉」這種逐步加深，答完一題要準備好被往下推。

反問清單 高頻

「你有什麼問題想問我們嗎？」不是客套——好的問題展現你的興趣、思考深度與對職位的認真程度，同時幫你判斷這份工作是否適合你。原則：依面試官角色調整問題、問你真的想知道的、避免問官網查得到的事、第一輪不先問薪資福利（交給 HR 關卡）。每關準備 2–3 個，視時間挑。

面試當天 Checklist、面試後 Follow-up 與 Offer 考量 基礎

前一天與當天

面試後 Follow-up

• 24 小時內寄感謝信（中文或英文皆可，依面試語言）：感謝時間、提及一個具體討論的話題、重申興趣。簡短即可。
• 補充回答：如果面試中有題目沒答好，事後想到更好的解法，可以在感謝信中簡短補充（例如附上改進的程式碼思路），展現積極態度，但不要長篇大論。
• 詢問進度：若超過 HR 告知的時間未收到消息，可禮貌來信詢問。
• 復盤：記錄每關的問題、答得好的與不好的，無論結果如何都是下次的養分。

Subject: Thank you – Backend Development Intern interview

Hi [Name],

Thank you for taking the time to speak with me today. I really enjoyed our
discussion about how the bidding service handles traffic spikes — it made me
even more excited about the problems your team is solving.

After our conversation, I thought more about the question on merging user
attributes at the scale of hundreds of millions of records. Beyond the hash-map
approach I described, I would partition both datasets by user_id and merge each
partition independently (or use a sort-merge join in Spark), so memory usage
stays bounded.

Thanks again, and I look forward to hearing from you.

Best regards,
[Your Name]

Offer 考量

面試自測題

以下每題請先自己用 STAR-L 或觀點結構口頭回答（計時 2 分鐘），再對照參考大綱。