cswork / libraryOpen practice workspace

Articles

趨勢科技軟體工程師面試準備：程式題、專案深挖與資安產品情境

趨勢科技軟體工程師面試準備：區分官方校園招募與個別面經，用資安事件的租戶隔離、重送、衝突和錯誤處理練習程式、專案深挖與產品取捨。

趨勢科技軟體工程師面試準備，應從你投遞的職缺與招募管道開始，而不是先背一套固定輪數。確認程式測驗要求、準備能被深挖的專案，再用資安產品中的資料、權限與可靠性情境練習技術判斷。會寫演算法與能說明一個事件處理流程，是兩種需要連起來的能力。

本文區分官方資訊、候選人自述與原創練習，不保證題目重複或錄取結果。若要把專案經驗轉成可追問的回答。

先分清楚校園招募與個別職缺

趨勢科技台灣官方招募 FAQ說明，技術職的甄選可能涉及線上程式測驗與面試，實際安排依職缺與團隊而異。它不是所有人共用同一平台、同一題數或同一輪數的證明。

截至2026年10月6日可查閱的官方2026校園招募頁，在該計畫範圍內列出 Codility 程式測驗，以及部門與人資相關甄選安排。這是特定年度、特定招募方案的資訊，不能直接延伸為所有中途招聘或未來梯次的規則。頁面上的活動時程也不能當作今天仍開放申請的保證。

拿到邀請後，請以自己的信件確認期限、時區、平台、可用語言、作答形式、外部工具與求助管道。若沒有寫明，問招募窗口，不要用另一位候選人的題目數補空白。練習可以安排自己的計時，但不能把自訂時長寫成公司規定。

公開面經提供的是差異線索。GoodJob 的趨勢科技面試經驗頁可看到2026年的不同記錄，有人提到線上測驗後討論履歷，也有人記錄多人面談與經驗提問；公開預覽並非全部內容，作者身分也未獨立驗證。一篇2026年8月發布的新卒自述則描述不同團隊把重點放在程式、物件導向或履歷討論。該文的求職記錄跨越2025年起的時間，不能把發布日期當成每場面試日期。這些是個人報告，不是官方流程，也不足以推出所有人的出題分布。

按職務把準備轉成證據

同一招募入口可能包含不同工程方向。官方校園頁的角色說明可以幫助辨認工作內容，但不代表每個角色接受同一種考試。先記錄職缺名稱、工作內容、主要語言與你要交付的成果，再決定補哪個弱點。

你實際投遞的方向準備一段可查證的經驗不要用什麼代替
C/C++或系統實作物件生命週期、資源釋放、併發或效能問題的切分只說熟悉語法，沒有失敗案例
後端／服務工程API契約、資料庫、重試、快取與權限邊界堆列雲端服務名稱
SDET／測試工程測試分層、隔離、flaky test診斷與漏測風險只列使用過的框架
威脅研究相關方向依職缺整理分析方法與可安全展示的證據因為是資安公司就宣稱所有SWE都考惡意程式分析

這張表是準備建議，不是趨勢科技的評分表。若你沒有資安工作經驗，可以用熟悉的資料管線、API或測試專案說明相同的工程問題，再補足產品語境。不要把尚未做過的研究描述成實際成果。

程式練習：租戶事件、重送與衝突

以下是原創的簡化練習，不是趨勢科技真題或產品架構。輸入是一批 (tenant, event_id, severity)，其中租戶與事件ID是非空字串，severity是0至10的整數。我們要計算每個租戶的severity總和，同一租戶的同一事件若完全相同，只計一次；同一鍵但severity不同則拒絕整批輸入。

這裡的severity加總只為練習資料處理，不是實際風險分數模型。把數值相加不代表資安風險可以這樣聚合，也不代表總和較高就一定要自動封鎖。

tenantevent_idseverity處理
Ae13接受，A累計3
Ae13相同重送，不再加總
Be17不同租戶，B累計7
Ae20有效事件，A仍為3

結果是 {'A': 3, 'B': 7}。如果只用event_id去重，B的e1可能被錯誤丟棄。若用每一筆資料直接加總，A則會因重送而變成6。兩種看似簡單的寫法，破壞的是不同契約。

def summarize(rows):
    seen = {}
    totals = {}
    for tenant, event_id, severity in rows:
        if not isinstance(tenant, str) or not tenant:
            raise ValueError("invalid tenant")
        if not isinstance(event_id, str) or not event_id:
            raise ValueError("invalid event id")
        if type(severity) is not int or not 0 <= severity <= 10:
            raise ValueError("invalid severity")
        key = (tenant, event_id)
        if key in seen:
            if seen[key] != severity:
                raise ValueError("conflicting replay")
            continue
        seen[key] = severity
        totals[tenant] = totals.get(tenant, 0) + severity
    return totals

先比較舊值再決定是否新增，是這段程式的重點。若先把 seen[key] 覆寫成新值，之後就無法辨認衝突。用 type(...) is int 是為了排除Python中也會被視作整數子類別的布林值，符合這個例子的明確輸入契約。

平均字典操作成本下，處理n筆資料的時間為O(n)，保留u個不同租戶事件鍵與t個租戶總和，需要O(u+t)空間。這是記憶體內、單次呼叫的簡化模型，不是持久化服務的交易保證。遇到錯誤會丟出例外，不回傳部分結果；函式並未寫入外部資料庫，所以不能據此宣稱「所有副作用都能回滾」。

從正確函式走到服務邊界

程式通過上述例子後，追問才開始。若資料來自外部客戶端，不能因為請求內寫了tenant=A，就認定呼叫者有A的權限。服務端要以已驗證的身分與授權上下文限制可讀寫的租戶，並讓查詢與快取也遵守同一邊界。輸入欄位和可信身分不是一回事。

若事件隔了很久才重送，要保留去重資料多久？永遠保留會增加空間，太早清理則可能重複計算。回答需要先確認可接受的重送期間、事件量、保存政策與下游是否也能去重，而不是只說「加一個set」。

若同一事件ID的內容不同，本例選擇拒絕。產品中可能要隔離可疑資料、記錄衝突並供人員調查。不能直接把最新到達值當成最新事實，因為到達順序未必是產生順序。若需要接受更正，應另定版本、來源權威與稽核規則。

若資料量超出記憶體，則要改變儲存與處理方法。持久化去重鍵、唯一性約束、批次失敗範圍與重試可以討論，但要交代併發、提交與失敗時的實際行為。單機函式的一次例外，不能自動證明分散式系統只處理一次。

練習時至少加入：空批次、完全重送、跨租戶同ID、0與10、負數、11、布林值、同鍵不同內容。把期待結果先寫下來，再跑程式。接著把需求改成「保留各事件明細」，看看回傳契約與空間估計是否仍正確。

衝突處理的產品取捨，不只有拒絕或接受

原創函式選擇整批拒絕，是為了讓練習契約明確。但如果一個客戶每次送一萬筆，其中只有一筆衝突，整批重送可能讓正常資料長期無法處理。面試追問可以因此轉成：錯誤要影響整批、單筆，還是某個租戶？先確認客戶與下游需要的保證，再決定處理方式。

假設一批有四筆，第三筆衝突。整批拒絕代表沒有結果可交付；逐筆隔離則可能先接受其餘三筆，另回報第三筆失敗。兩者需要不同的回應契約與重試方式。不能只把程式中的例外改成 continue，因為呼叫者若仍以為全部成功，就失去重要錯誤訊息。

若採逐筆結果，應能讓呼叫者識別哪筆接受、哪筆是相同重送、哪筆需要處理。錯誤回應也不要洩漏其他租戶的事件內容。重試相同批次時，已接受的資料仍需避免再次計算；錯誤資料則要有可追蹤的狀態，不能永遠重試卻沒有負責人。

這些是產品決策，不是單純演算法優化。完整拒絕較容易維持批次語意，但失敗範圍較大；局部接受提高資料流動性，卻增加回報與補償的複雜度。回答可以選一個方案，但要說明適用條件和未解決的代價。

告警暴增的原創診斷例

用一組架空數字練習切分問題：前一時段原始輸入60筆，下一時段120筆；按可信租戶與事件ID去重後，下一時段只有80筆不同事件，其中兩筆有內容衝突。這不是實際客戶資料，也不是對趨勢產品的觀察。

第一個問題是「120」代表傳輸筆數還是獨立事件數。若直接把兩倍輸入當作兩倍威脅，就混淆了重送與新事件。第二個問題是80筆中哪些可正常處理：兩筆衝突需要另外記錄，不能為了得到乾淨圖表就偷偷採最新內容。第三個問題是同樣規則版本與客戶範圍下，獨立事件是否真的增加。若規則或資料來源改變，前後數字未必可直接比較。

下一步要收集來源、時間範圍、租戶分布、重送原因和版本變更，避免記錄不必要的敏感內容。確認是投遞重試，就修復重試或去重；確認是規則變更，就檢查覆蓋與誤報；若是合法事件增加，則再評估容量與優先處理。這種順序讓「先限流」成為有條件的選擇，而不是掩蓋所有原因的答案。

談到監控時，也要區分原始輸入、接受數、重送數、衝突數與處理延遲。它們反映不同環節。單一告警量不能回答管線是否正確，單一CPU指標也不能回答是否遺失重要事件。

專案深挖：選型、故障與本人範圍

專案回答不要只沿著履歷的技術名詞走。選一個你能查證的改動，說明原來的問題、限制、候選方案、自己的決定與驗證。若是團隊專案，要區分本人實作、共同設計、同事處理與尚未完成的部分。

以事件API為例，面試官可能問「為什麼放快取」「資料過期時會怎樣」「查詢會不會跨租戶」「故障是怎麼發現的」。如果你只是使用現成服務，說清楚你設定、驗證和監控了什麼，不要把服務的所有內部設計算成自己的貢獻。

可以準備一份簡短的證據紀錄：使用情境、輸入規模、失敗現象、修改前後的比較方法、結果與限制。沒有真實量測時，就說明尚待驗證的假設。不要補上虛構的吞吐量或改善百分比。單元測試通過，也不等於生產環境沒有權限或併發問題。

下面是回答方式示範，不是真實候選人的經歷：

我負責事件查詢的租戶過濾與重送處理。最初用事件ID作去重鍵，跨租戶案例會漏資料，所以改成租戶與事件ID的組合。相同鍵卻有不同內容時，先拒絕而不覆寫，保留調查線索。測試確認了這些輸入契約；持久化重試與高併發還需要另外驗證，我不會把這次測試當成完整的交易證明。

這種回答能讓對方追問具體邊界，而不是只聽到「我很重視資安」。若談到客戶事件，使用經允許的匿名資料或自建反例，不公開機密日誌、存取憑證與敏感樣本。

資安產品情境：不要只追求告警更多

資安產品中的工程決策可能同時影響偵測覆蓋、誤報、處理延遲與客戶操作。面對「告警量暴增」的練習題，先區分事件真的增加、重複投遞、規則版本變更或資料品質問題，再談抑制與限流。直接刪掉低分事件可能降低負荷，也可能掩蓋重要線索。

若加入規則抑制，應說明規則由誰管理、有效期間、作用租戶、可追溯性，以及回復後能否重播。若新增資料擴充插件，則考慮逾時、錯誤隔離和敏感資料能否送到外部。這些是可轉移的產品工程練習，不是對趨勢科技內部系統的推測。

也要問工作重點。「這個職缺主要處理端點、雲端服務還是測試平台？」「新人要對哪個模組負責？」「團隊如何驗證偵測規則或服務改動？」答案會幫你調整準備，不能由公司名稱自行猜出。

面試前讓同伴追問一個真實改動

找一個允許公開的專案改動，請同伴依序問四件事：沒有這個改動時會發生什麼、為什麼選這個方法、怎樣證明它有效、什麼條件改變後要重做。不要先背滿一頁回答，再期待對方按照相同順序提問。

如果回答停在「框架會處理」，查清楚自己依賴了哪個保證。如果停在「應該不會發生」，補一個可重現的失敗輸入。如果停在「團隊決定的」，說明你提供了哪些分析與實作，而不是把共同決策全部歸為個人成果。這樣準備能同時改善程式、專案和產品情境的回答。

把五個練習題連成一條工程推理

題目記錄的公司或職位標籤也不能取代自己的邀請與職缺內容。

練習題這篇文章建議練的追問
Debug a cache incident end-to-end如何區分過期資料、錯誤鍵與來源問題；先看什麼證據
Extensible Security-Event Pipeline: Rule Suppression and Plugin-Based Enrichment抑制的範圍、插件失敗、重播與稽核
Review getEvents endpoint for readability, performance, scalability, security租戶授權、輸入契約與效能改善的先後
Testing a New Feature: Planning Test Cases and Handling Flaky Tests怎麼隔離不穩定測試，而不是反覆重跑掩蓋原因
Resume Project Deep Dive: Tech Stack Choices, Trade-offs, Business Logic and Ownership選型限制、本人責任與能查證的成果

準備完成的標準，是能按自己的招募範圍處理程式與提交要求，並用具體反例說明專案決策。下一步可以從資安事件管線題開始，先畫資料與權限邊界，再討論規則、錯誤與恢復方式。

資料來源與延伸閱讀