Betsson Web3 前端把 iGaming 變成流程戰

我拆 Betsson 的 Web3 前端職缺，翻成真正的 stack、怪點，最後給你可直接貼用的職缺模板。

我盯 Web3 職缺一陣子了，很多都像把區塊鏈名詞撒在一般前端工作上，然後假裝自己很有方向。Betsson 這份 Frontend Software Engineer - Web3 的職缺https://betssongroup.com/job/frontend-software-engineer-web3-2/，老實說也不是什麼超完整規格，但它剛好把我最在意的那個洞露出來：你到底是在招一個會做 UI 的人，還是一個只會講錢包和鏈的人？這兩種人差很多，做出來的產品也差很多。

我會想拆這份職缺，不是因為它多神，而是因為它夠典型。iGaming 本來就一堆摩擦：登入、驗證、提領、地區限制、責任博彩、付款失敗。再塞進 Web3，前端就不是「做漂亮畫面」而已，而是要把一堆不確定狀態講成人話。這件事做不好，使用者只會覺得卡、煩、怕，然後客服爆掉。

這份職缺先要前端，不是來找幣圈嘴砲王

Are you a Frontend Software Engineer with a keen interest in everything Web3 and how this can be applied to iGaming? Then this is the role for you!

我把這句翻成白話，就是：先把前端做好，Web3 是加分項，不是拿來遮蓋基本功的遮羞布。它要的人應該是能把產品 UI 做穩的人，再去處理錢包、鏈、簽名、交易狀態這些麻煩事。

我以前最怕這種角色被招成「Web3 觀光客」。嘴上很懂 token、NFT、L2，結果一碰到表單、狀態管理、錯誤回復就開始飄。這在 iGaming 特別危險，因為這裡不是做社群頁面，這裡碰的是金流感很重的流程。使用者一旦看不懂，信任就掉光。

實操上，我會把這種職缺拆成兩層：第一層是前端基本功，像 React、TypeScript、元件切分、API 串接、測試、可用性；第二層才是 Web3 特化，像錢包連接、chain switch、transaction state、signature prompt。這樣寫才不會讓候選人誤會自己是來當鏈上傳教士。

• 核心技能：前端產品工程，不是區塊鏈簡報
• 特化技能：錢包、簽名、交易狀態、鏈切換
• 面試重點：能不能把複雜流程做得像一般流程一樣順

Web3 前端最煩的不是技術，是狀態永遠不乾脆

我看這類職缺時，腦中浮現的不是 NFT，而是 pending、failed、rejected、expired、mismatch。Web3 前端真正麻煩的地方，不是畫面長什麼樣，而是每一步都可能中途翻車。使用者按了 deposit，錢包跳出來，網路不對，簽名被拒，交易卡住，重新整理後狀態又半殘，這時候 UI 要怎麼講清楚？

這就是我覺得 Betsson 這類職缺有意思的地方。iGaming 本來就很吃即時感，但 Web3 偏偏不是即時系統，至少不是你想像的那種即時。前端如果只會顯示 loading 和 success，基本上就是在騙人。真正該做的是把「現在發生什麼事」講清楚，讓使用者知道自己是在等簽名、等上鏈、等確認，還是已經失敗可以重試。

我之前做過一個錢包串接流程，staging 跑得很漂亮，結果一上真實環境，使用者只要拒簽、切網路、或跳出頁面再回來，整個流程就開始像壞掉。問題不是後端不行，是前端沒把狀態拆乾淨。那次之後我很討厭任何只寫「processing」的 UI，太偷懶了。

實操寫法很簡單：不要只設計 loading / success / error，請直接列出 pending signature、awaiting confirmation、network mismatch、transaction rejected、confirmation timeout、retry available、manual refresh 這些狀態。只要產品碰到錢，UI 就不能含糊。

• pending 在 Web3 不是一般 API 的 loading
• 每個狀態都要有可理解的文案
• 每個失敗都要有回復路徑，不然就是在製造客服單

iGaming 的合規不是法務文件，是前端畫面的一部分

很多人看到 iGaming 會想到 UI 花俏、活動多、視覺刺激。我看到的是限制。年齡驗證、地區限制、責任博彩、提款規則、身份檢查、稽核需求，這些東西不是「等法務看完再說」就結束了，因為最後使用者真的看到的，還是前端。

一旦 Web3 進來，這個壓力更大。你可能要在錢包連接前就說清楚支援哪些鏈，在哪些地區不能用，交易失敗怎麼辦，資產到底是怎麼流動的。這些都不是 footer 小字可以解決的。使用者在碰錢的那一刻，不會去翻條款頁。

我以前看過很多團隊把合規藏在 tooltip 或頁腳，結果就是轉換率沒救，抱怨先來。真正好的做法，是把限制放在流程裡該出現的地方。不是嚇人，是不要騙人。你如果先讓人走到最後一步才說「抱歉你不符合資格」，那就是在浪費大家時間。

實操寫法：在流程最前面做地區與資格檢查，對不可逆動作在按下前先說明，錯誤訊息要能回答三件事：哪裡卡住、為什麼卡住、下一步怎麼做。這種寫法看起來不華麗，但真的省很多命。

如果我是主管，我會直接問：這個人能不能把合規做成 UX，而不是把 UX 做成合規告示牌？答不出來，八成不適合這種產品。

沒寫出來的 stack，通常才是你真正要懂的東西

職缺頁面通常不會把 stack 交代得很細，Betsson 這份也一樣。這很正常，但也很煩，因為真正會踩雷的地方，往往就在那些沒講清楚的整合點。我會猜這份工作大概圍繞現代前端框架、錢包整合、API client、設計系統、以及一堆需要小心維護的流程狀態。

如果是我來翻譯成實際工作內容，我會預期是 TypeScript、React 類堆疊、狀態管理、測試、元件化、和對外部 provider 的整合。再往下看，還可能有錢包 SDK、交易歷史、鏈上/鏈下資料同步、以及把 Web3 邏輯隔離在 service 或 hook 裡，不要散到每個 component 都像灑鹽一樣。

這種工作最怕的不是技術不夠新，而是責任邊界不清。前端要知道什麼該自己判斷、什麼要問後端驗證、什麼只是把鏈上的真實狀態反映出來。邊界一亂，最後所有人都會把鍋丟給前端。

實操寫法：面試或評估這種職缺時，我會直接問這幾個問題：

• 錢包 provider 用哪個？支援哪些 chain？
• 交易狀態存哪裡？怎麼 replay？
• 驗證與合規文案誰負責？
• Web3 邏輯怎麼避免污染整個 component tree？

好的 Web3 前端，是把不確定講到人聽得懂

我最在意的其實不是技術名詞，而是這份工作有沒有在做一件真正重要的事：把不確定變成可理解的狀態。Web3 本來就充滿不確定，交易不是按下去就完成，錢包不是永遠連得上，鏈也不是永遠對，使用者更不是永遠知道自己在幹嘛。

所以我會把這種角色定義成「狀態翻譯員」。他不是把鏈上世界原封不動丟給使用者，而是把那些難懂的中間態拆成清楚的畫面。連線中、等待簽名、等待確認、網路不符、交易失敗、可重試、需人工處理，這些都要能說人話。

我以前曾經因為一個很爛的「processing」字樣，把客服量拉到很誇張。後來不是靠加 log 解決，而是把 UI 文案、流程分支、回復機制全部重做。那次我才真的確認，很多所謂技術問題，其實是 UX 沒把狀態講明白。

實操上，我會建議先寫狀態文案，再寫 code。真的。你如果連一句話都講不清楚，代表你還沒想清楚流程。候選人如果能拿出一個失敗交易的完整說明流程，我會比看作品集更有感。

如果我來面試，會看這三件事

如果把這份職缺翻成面試標準，我會只看三件事。第一，前端基本功夠不夠穩，包含元件設計、效能、可存取性、測試。第二，能不能處理高失敗率流程，因為 Web3 和金流類體驗本來就不會永遠順。第三，對 Web3 的理解是不是實用的，而不是只會講口號。

我說的實用，不是要你背一堆 EIP，而是你至少要懂 wallet、signature、chain ID、transaction confirmation、client trust 跟 protocol trust 的差別。你要知道哪些事情前端只是顯示，哪些事情要交給後端驗證，哪些事情要直接相信鏈上的結果。這才是能上線的人。

而在 iGaming 這種場景，我還會額外看一件事：這個人有沒有尊重使用者。不要暗黑設計，不要模糊費用，不要把風險藏起來。這種產品的前端如果只顧轉換，不顧理解，最後都是在燒信任。

實操寫法：候選人可以做一個小 demo，包含錢包連接、網路不符處理、pending 狀態、失敗重試、清楚的錯誤文案。主管可以直接要求候選人走一次失敗交易流程，通常比問八題八股更準。

可抄的模板

## Frontend Software Engineer - Web3 (iGaming)

### 我們在找誰

我們需要一位能把前端產品做穩、做清楚的人，能在受監管的 iGaming 環境裡處理 Web3 相關流程。

### 這個角色真的在做什麼

- 開發與維護錢包串接、Web3 互動與相關使用者流程

- 把鏈上與交易狀態翻成使用者看得懂的介面與文案

- 和產品、後端、法遵一起處理受監管流程

- 處理網路不符、拒簽、交易 pending、確認失敗與重試流程

- 用 TypeScript、測試與元件化維持可維護性

### 我會想看到的條件

- 有現代前端框架經驗，像 React

- 做過非同步、容易失敗、需要回復的流程

- 懂基本到中階的 Web3 概念：wallet、signature、chain ID、transaction state

- 能在受監管產品環境裡工作

- 會寫讓使用者看得懂的狀態文案，不靠術語裝懂

### 面試我會問什麼

1. 你會怎麼設計一個錢包存款流程，讓 pending、failed、confirmed 都清楚？

2. 使用者在交易中途切換網路，你怎麼處理？

3. 你怎麼在不犧牲轉換的前提下放進合規訊息？

4. 交易狀態你會存哪裡、怎麼回放？

5. 你怎麼避免 Web3 邏輯滲進每個 component？

### 做得好的標準

- 使用者永遠知道發生了什麼、正在發生什麼、下一步是什麼

- 錢包與鏈相關錯誤都能被理解與回復

- 合規要求出現在正確的流程節點

- 前端即使面對不穩定狀態，仍然保持可讀、可維護

### 短版應徵自介

我做前端產品，擅長處理非同步、受監管、跟金流感很重的流程。我在乎清楚的 UX、明確的失敗處理，以及使用者真的能完成的 Web3 體驗。

這段模板是我把 Betsson 這份職缺翻成人話後的版本。它不是唯一寫法，但如果你想少一點 buzzword、多一點訊號，直接拿這段去改就行。

原始來源是 Betsson Group 的職缺頁：https://betssongroup.com/job/frontend-software-engineer-web3-2/。上面大部分拆解是我自己的解讀，模板則是我根據這份職缺整理出來的可直接套用版本。