LINE 台灣工程師面試準備：依前端、後端與搜尋職缺選對練習

準備 LINE 台灣工程師面試，第一步不是背一套「LINE 都這樣考」的流程，而是確認邀請上的公司、團隊與職缺。前端要說清楚畫面狀態和非同步結果；後端要處理 API、資料與重試的邊界；搜尋則需要區分候選召回與排序品質。同一份通用刷題清單，無法代替這三種能力的證據。

本文以2026年10月6日查核的官方職缺資料，加上三個原創練習案例，協助你依實際 JD 選擇準備內容。這些案例不是 LINE 真題，也不是目前全部開缺的清單。若邀請、團隊或職缺已更動，應以自己的最新通知為準。

需要先挑選練習素材。這是職務練習入口，不是 LINE Taiwan 專屬題庫；先選符合自己 JD 的路線，再決定要做哪一題。

先分清 LINE Taiwan 與 LINE Pay Taiwan

LINE 官方職缺列表把 LINE Taiwan、LINE Pay Taiwan 等公司分開標示。搜尋引擎可能把這些職缺、其他地區的工程師職務，以及過往面經放在一起；它們不能直接合併成一個選考流程。記下完整公司名稱、職缺名稱、地點、團隊與邀請日期，才有辦法判斷資料是否適用。

官方的LINE Taiwan_Portal & Content_Product Engineering 職缺在查核時可以閱讀，且出現在職缺列表。它描述的是 server-side 工作，包括 Java／Kotlin、API 與資料庫 schema、可擴展服務，以及與東京和首爾團隊合作。這些是準備技術經驗的依據，不代表面試一定會逐項考問，也不是前端職缺的要求。

舊職缺頁即使出現在搜尋結果或相關推薦，也不代表現在仍能閱讀或申請。本次查核也遇到無法開啟的後端職缺連結，因此沒有用它補齊現行要求。先在官方列表找到職缺，再確認內容與招募狀態；若連結失效，請招募者提供適用於自己邀請的職務說明，而不是從快取文字推定目前條件。

前端與搜尋也要遵守同一原則。本次未確認可用的 LINE Taiwan 現行前端或搜尋 JD；搜尋結果裡的舊職缺名稱不等於目前開缺。下面兩條練習路線，適用於你的實際邀請或 JD 確實包含該工作時。本文不據此推定統一面試輪次、OA 題數、使用語言、合格線或等待時間。

用 JD 的動詞決定準備哪條路線

技術名稱只能告訴你工具，工作動詞才能幫你選練習。「維護既有頁面」和「設計搜尋排序」可能都寫 JavaScript 或 Python，但需要的案例完全不同。把每個要求轉成你能展示的產物，例如測試、API 契約、故障追蹤或評估表。

自己的 JD 出現的工作	優先練習	準備的證據
前端介面、互動、API 串接	狀態更新、請求競態、錯誤與可及性	一段可重現的時間線與 UI 測試
後端 API、schema、平台服務	冪等、交易、資料一致性與失敗恢復	事件紀錄、資料變化與契約測試
搜尋、相關性、檢索效能	候選召回、排序、資料更新與延遲	明確標註的評估資料與分層指標
跨地區合作、設計與品質	解釋取捨、責任邊界與驗證	自己做過的決定及未解決事項

如果職缺只要求一般後端服務，不必因為看到別人的搜尋面經，就把所有時間轉去學向量資料庫。反過來，搜尋職缺也不應只用幾道陣列題證明相關性判斷。先處理實際工作要求，再補足通用程式能力。

前端案例：搜尋 B 已顯示，為何又變回 A？

以下是原創練習，不是 LINE 的介面或考題。使用者先搜尋 A，再很快改成 B。B 的請求較快回來，畫面正確顯示 B；稍後 A 的結果返回，把畫面覆蓋成 A。伺服器回應都可能正確，問題在於前端接受了已經過期的結果。

時點	事件	可以更新現在的畫面嗎？
T1	開始 A，請求版本1	先記錄當前版本1
T2	開始 B，請求版本2	當前版本改為2
T3	B 的版本2回應	可以接受
T4	A 的版本1回應	不可以覆蓋 B

修正時，取消舊請求可以節省不必要的工作，但不能把「呼叫取消」本身當成畫面永不接收舊結果的證明。還要在接受結果的時候，確認它屬於目前的請求。錯誤訊息與 loading 狀態也應遵守同樣的版本邊界。

MDN的AbortSignal文件說明，fetch應在選項中接收signal，已取消的signal不能重新用於新請求。這支持取消操作的實作細節，不代表已替應用完成畫面接受規則；新請求要用合適的controller，後續處理仍需遵守目前版本。

下面是可以獨立測試的接受規則，不是完整 React 元件或網路取消實作。

function createResultGate() {
  let version = 0;
  return {
    begin() { return ++version; },
    accept(requestVersion, data) {
      return requestVersion === version
        ? { accepted: true, data }
        : { accepted: false };
    },
    dispose() { ++version; }
  };
}

測試時依序取得 A 的版本1、B 的版本2，先接受 B，再嘗試接受 A。前者應回傳accepted: true，後者應為false。dispose()讓目前尚未完成的版本也失效；實際元件卸載時，仍要處理網路、訂閱和其他資源的清理。

再加三個情境：A 失敗但 B 成功，A 的錯誤不應蓋住 B；B 先失敗、A 後成功，A 不應把 B 的錯誤擅自改成成功；元件卸載後，舊結果不得繼續更新畫面。這些測試比「用了AbortController」的描述更能顯示你知道要保護什麼。

面試解釋可以從「使用者最後的意圖」開始，接著展示時間線與接受條件。若產品允許保留上一次結果以減少閃爍，也要區分「刻意保留舊資料」與「過期回應偷偷覆寫新狀態」。兩者視覺上可能相似，但設計契約不同。

後端案例：相同事件重送，資料能只變一次嗎？

官方台灣後端 JD 的 API、資料庫與服務要求，可以轉成可防守的技術案例。以下仍是虛構的練習系統：每個事件有租戶、事件ID、商品與數量變化。相同事件重送時，不再套用一次；相同ID但內容不同時，回報衝突，而不是默默忽略。

收到的事件	預期結果	數量變化
A／e1／pen／+2	接受	A 的 pen 變成2
A／e1／pen／+2 再送	重複	A 維持2
B／e1／pen／+7	接受	B 的 pen 變成7
A／e1／pen／+5	衝突	A 維持2
A／e2／pen／−1	接受	A 變成1

只以事件ID當鍵，會把 B 的事件誤認為 A 的重複。只記「看過這個ID」，又可能把相同ID、不同內容的錯誤藏起來。下方 Python 是單一程序、依序處理的模型，用來說明鍵與內容的關係；不是資料庫交易或分散式 exactly-once 保證。

def apply_event(seen, totals, tenant, event_id, sku, delta):
    key = (tenant, event_id)
    payload = (sku, delta)
    if key in seen:
        return "duplicate" if seen[key] == payload else "conflict"
    total_key = (tenant, sku)
    totals[total_key] = totals.get(total_key, 0) + delta
    seen[key] = payload
    return "accepted"

正式實作還要回答：兩個 worker 同時處理 A／e1，誰能取得唯一的處理權？寫入事件紀錄和修改數量能否在同一個交易完成？若紀錄成功但數量更新失敗，重試會怎麼走？若數量成功但紀錄沒寫入，是否可能再加一次？單純的「先查是否存在，再寫入」沒有自動解決這些問題。

你可以提出租戶與事件ID的唯一約束、明確的衝突處理，以及把業務效果和處理紀錄放在適當的原子邊界。跨外部服務的效果還有另一個問題，不能靠本地交易包住所有網路呼叫。依情境討論outbox、重試、補償或對方的冪等契約，但不要為了展示名詞把不需要的架構堆上去。

另外，冪等不等於授權。先確認呼叫者能操作該租戶，再討論重送如何處理。測試資料也不能混入其他租戶的紀錄。清楚說出模型已驗證的順序行為，以及尚未驗證的併發與崩潰恢復，會比宣稱「保證只做一次」更有說服力。

搜尋案例：第一名很好，為何還是漏掉重要文件？

如果你的 JD 涉及搜尋，練習時要把取回候選和重新排序分開。搜尋品質差，可能是資料未進索引、查詢理解有誤、候選數不足、權限過濾過早，也可能是排序不佳。直接換reranker不一定能修復前面各層的失敗。

假設某個測試查詢的相關文件已由人工標註為D2與D4。候選階段只取到D1、D2、D3，排序後變成D2、D1、D3。以下數字只是這一個虛構查詢的練習值，不是 LINE 的指標、門檻或實際測試成績。

指標	計算	結果與限制
候選Recall@3	取到1篇相關文件／已標註2篇相關文件	0.5，D4 沒有進入候選
排序後Precision@1	第一名相關篇數／1	1，第一名很好但不代表沒有漏檢

排序器不能替未進入候選的 D4 排名。只看Precision@1，可能把候選召回不足隱藏起來；只增加候選數，則可能增加計算與延遲，但仍不保證相關文件能出現。應先查看漏掉的文件在哪一層被排除。

也要確認指標的分母是否可信。這個小例子有完整給定的相關集合，所以可以直接算recall；正式資料若只標註部分文件，不能把沒標到的文件全部當成不相關，再假裝算出了完整召回率。把查詢分成代表性類型，檢查標註一致性，說明未知的相關文件和資料缺口。

延伸一個資料更新案例：D4 剛修改內容，資料庫已更新但索引還沒完成。這時排序模型可能沒變，搜尋結果卻仍然過期。先確認索引版本、更新延遲與可接受的新鮮度，再討論模型。刪除或權限撤銷的資料尤其要有清楚的處理邊界，不應只靠離線相關性分數決定。

練習的產物可以是一張按查詢分類的表：候選是否包含相關文件、排序是否提升它、端到端延遲、索引更新時間。平均值之外，還要看長尾查詢和高延遲情況。這些是你提出的驗證方法，不是本文已做過的 LINE 生產測量。

把專案介紹變成一個可以追問的決定

選好路線後，從自己的經驗找一個相近但真實的案例。前端談一次非同步錯誤如何重現，後端談一個交易或重試決定，搜尋談一個資料或評估問題。不要把本文的案例改成「我在公司做過」；沒有相關實務時，可以自己完成小專案，明確說是練習。

介紹時依序交代問題、自己的範圍、比較過的選擇、採用方案、驗證和限制。例如「我修改的是請求結果的接受邏輯，不是搜尋API。用固定回應順序重現舊資料覆寫後，加入版本檢查；還沒測真實網路取消」。這樣對方可以追問具體工作，而不是只能問使用過哪些套件。

官方部分台灣後端職務描述與跨地區團隊合作有關，你可以準備用英文說清楚一次技術決定。不過這不等於每個面試一定全程英文。向招募者確認面談語言與形式，並準備描述自己的角色、取捨、結果和未完成的驗證，而不只是背一段自我介紹。

JD 中若提到 AI 開發工具，也要區分工作期待與受測規則。工作上允許AI-assisted coding，不等於測驗期間可以使用AI。以邀請的規則為準；平常使用工具時，也要能解釋產生的程式碼和驗證方法。不確定允許範圍就先向招募者確認，不要把JD當作許可書。

用一個小產物確認自己真的掌握了這條路線

為了避免讀懂文章卻做不出來，可以把練習限制在一個可交付的小產物。前端做一個控制回應順序的測試；後端寫一張重送與衝突的資料表；搜尋保存一組查詢、標註、候選與排序結果。每次只改一個條件，記錄結果如何變化。

前端可以先固定 A 比 B 慢，再讓 A 比 B 快。兩種順序都應保護最後一次輸入，而不是只在原先的失敗順序通過。接著把成功回應換成錯誤，確認過期錯誤也不能改掉現在的訊息。若你用框架整合，還要測生命週期與清理；上面的純函式只驗證接受規則，沒有替你完成元件測試。

後端則把同一事件送兩次、跨租戶送同ID、同ID改內容、數量改成0。數量沒有變化，不代表事件就不用記錄；否則下一次不同內容可能無法被辨識為衝突。用程式列出每一步的結果與最終資料，並說明如果程序在兩次寫入之間停止，這個簡單模型有哪些缺口。

搜尋可以增加一個沒有任何已標註相關文件的查詢。此時recall的分母為0，應先定義不適用、另行報告或其他明確策略，不能隨意填成1來提高平均值。若不同查詢的相關文件數不同，逐查詢平均與加總後計算也可能回答不同問題。先說清楚評估單位，再討論指標好不好。

把結果整理成短說明：原始問題、預期規則、反例、修改、通過的測試、尚未確認的事項。這份產物可以用來練習專案深挖，但公開時要移除機密程式碼、客戶資料與真實測驗內容。面試邀請若不允許攜帶或展示外部材料，就把它當作自己的準備紀錄，不要直接帶入受測環境。

剩餘時間如何分配，也由這個產物決定。如果前端測試不會控制回應順序，先補測試能力；如果後端把衝突當重複，先補事件契約；如果搜尋只會看第一名，先補候選與分母。不要因為另外一條路線看起來新穎，就跳過實際JD最需要的能力。

資料來源與延伸閱讀

• LINE Careers：官方職缺列表與公司分類
• LINE Taiwan_Portal & Content_Product Engineering：官方職務說明
• MDN Web Docs：AbortSignal與fetch取消行為