本文以本人有限的經歷提供一些思路，實際真的有解決過比較棘手的問題的同學就沒什麼看的必要了。
我認為這個問題主要考察的一方面是求職者解決問題的能力，另一方面是求職者的總結覆盤能力，有時還考察求職者是否對技術有關注和接觸。這類主觀題我覺得可以針對JD的要求去貼近招人需求。
平時忙於業務開發的同學，有時很容易忽略一些問題，或者有時急著完成需求和修復bug，解決問題後沒及時記錄下來，本文就起個拋磚引玉的作用，列舉一些比較通用型的問題。
按鈕重複點選的問題
其實這場景應該還蠻容易遇見的，所以我覺得比較適合做前端年限不太長比如一兩年的同學來作為備選。
有時因為網路問題，或者手機效能問題，或者一些未知原因，導致使用者點選按鈕的操作沒有及時得到響應，使用者下意識的就會頻繁重複點選。
如果該按鈕的點選回撥是去呼叫介面，假設使用者頻繁點選，不可避免的就會給伺服器造成壓力，最簡單的處理就是在使用者點選之後設定按鈕為不可點選，等到介面有返回後再將按鈕狀態重置；如果介面沒有合適的返回，為了防止因網路等原因導致的沒有響應，也可以前端設定定時，使使用者操作控制在一定的頻率，比如傳送驗證碼這種場景。
如果該按鈕的點選回撥是開啟一個彈窗，頻繁點選的後果可能就是開啟一串的彈窗，當然也可以給按鈕設定狀態標記欄位或者定時，此時就可以結合節流與防抖作答，正好面試中也很容易遇到節流與防抖的問題，化被動為主動更好把握面試節奏，當然前提就是對這方面的內容有所準備。
如果該按鈕是與原生有互動，比如本人曾經遇到過呼叫原生開啟新的webview或者其他app，如果原生因為某些系統原因沒有及時開啟，節流防抖也做了，但是如果響應延遲很久，使用者可能在頁面上做其他操作了，此時如果之前開啟新的webview或者其他app有了響應，就有可能同時出現多個操作的互動反饋，造成混亂，後來的解決方案還是做了欄位標記，在第一次開啟webview的操作就作標記，如果此標記沒重置（沒開啟新的appview），就不響應後續此頁面上的其他互動，這在使用邏輯上可能有些不太合理，但是開啟webview和其他app的操作原生無法取消，當時還沒想到比較好的其他處理方案。
輪詢介面的問題
此類場景也還算常見，適合兩三年、三四年的同學作為備選。
有時我們會遇到一些需求，比如頁面要定時獲取最新的資料，如使用者積分、app內訊息通知，一般簡單的處理就是使用介面輪詢，定時呼叫後端介面，如果應用的流量不大、使用的使用者不多，這麼處理也沒什麼大問題。
但實際這樣做會使請求過多，佔用伺服器資源，出於最佳化思考，可以考慮websocket，就可以提前對websocket做一些瞭解學習，如果專案實際開發中有使用經驗就更好了。
單次載入圖片過多的問題
這個問題通常發生在移動端，尤其圖片體積偏大時，可能影響其他請求的傳送。
比較常見的就是列表，往往這些列表的資料是使用者在後臺上傳的，因此如果使用者傳一些高畫質圖，就可能導致圖片體積過大，圖片壓縮當要做，同時在移動端，我們也可以做圖片懶載入，只渲染進入可視區域的圖片，等待圖片即將進入可視區域時再進行載入；現在移動端列表一般會做分頁，也就是常見的上拉載入，一次不會載入太多圖片，如果對效能要求比較高的時候也可以加上懶載入。
如果圖片託管在OSS平臺，也可以在連結後面追加處理引數（x-oss-process），對返回的圖片的大小和尺寸進行限制，也是一種方法。
移動端適配問題
移動端老生常談的問題了，css中的相對單位，常用方案rem可以說，配合瞭解一些webpack外掛。
也可以說說vw、vh，螢幕解析度，瀏覽器視口。
移動端相容問題
移動端手機型號多，尤其安卓機型，或多或少會碰到這類問題，但這些問題又不能一概而論。
如果有同學解決過較多這方面的問題，但是平日裡沒有整理過，可以提前做一些整理，去mdn、caniuse等網站針對做一些補充完善，就可以在面試時發揮了。
應用效能問題
如果實在工作開發中沒碰到過什麼大的問題，還可以有個萬能的回答，就是對應用效能進行最佳化，我看很多JD裡也會希望候選人有效能最佳化方面的經驗，正好可以對應上。
隨著需求迭代，專案程式碼不可避免會增多，打包體積隨之增加，使用者首次開啟應用也會變慢。這個問題可以從多方面著手去作答。
從互動層面，可以做骨架屏，使得頁面首次載入不會長時間白屏，也能讓使用者預先知道頁面的分佈；或者增加一些等待的互動。
從程式碼層面，可以提取公用程式碼、通用程式碼，抽取出來做成公用函式，或者封裝成元件，業務元件或者基礎元件。
從構建工具方面，比如webpack，可以提前瞭解它的一些配置，比如程式碼壓縮、程式碼拆分、tree-shaking、懶載入。
從效能工具方面，比如lighthouse，量化指標，根據提供的建議進行調優，可以提前瞭解一些程式碼和效能分析工具。
從網路請求方面，比如使用者端設定快取，可以提前預備強快取和協商快取方面的儲備知識，一方面減少使用者請求，一方面及時更新快取；使用CDN等等。
從技術方面，可以準備微前端等相關知識。
線上問題定位
對於前端來說有個很頭疼的問題，就是線上問題，不想後端一樣可以有線上日誌，前端問題出現在客戶端時我們不知道發生了什麼，使用者操作了什麼，就算可以聯絡到使用者，有時他們也不一定記得自己做了什麼，而往往很多時候知道原因就很容易解決問題了，難的就是不知道導致問題的原因。
這個問題我大概是五六年前的時候第一次碰見，很緊急的一個線上支付問題，前端反反覆覆盲改，一直沒改好了，後來加了錯誤捕獲，再透過呼叫介面獲取到錯誤資訊，才知道原因是什麼；後來換了工作在新公司中接觸到埋點，才開始瞭解到這一塊的東西，不過當時公司的埋點主要用於使用者行為分析，在使用者進行一些互動操作，比如點選、進入頁面、登入時，將使用者行為資料上報給埋點平臺，資料分析的同學會利用這些資料進行統計，可以給運營同學做一些運營策略的參考，給產品經理規劃需求時做參考。
再後來在工作中又接觸到監控平臺sentry，使用它將應用中捕獲到的錯誤上報給平臺，在sentry平臺可以看到哪些錯誤是比較頻發的，還可以直觀的看到在丟擲錯誤時上報的相關資料，比如作業系統、使用者標識、ip、錯誤資訊等等，還可以看到問題是在哪些時間段頻發，從而可以確認新發的包是否解決了之前的問題；當然還有很多功能我用的不怎麼多還不知道。
如果有同學想把這個問題作為備選，可以提前瞭解前端的埋點和監控平臺。
其實我覺得埋點的核心一個是前期將需要的資料透過介面上報，不管是使用者行為資料還是錯誤資訊資料；另一個是後期解決後確認是否該問題不會出現或者被控制在一定範圍內。
手動打包問題
我最早待過的一家公司是開發自己手動打包，然後將包發給運維部署，這很容易出錯，眾所周知，我們通常是拉分支做需求的，如果在做新需求時要切換到舊分支，流程繁瑣，很容易誤操作，存在安全隱患，也影響新需求的開發效率和進度，後來我們運維就自己搞了一套自動化構建的東西，當時我也沒有接觸。
後來換了一家公司，接觸到jenkins，才開始對自動化構建有一些瞭解。
如果崗位的JD有這方面的偏好，就可以從自動化構建、CICD方面做一些準備。
工作效率問題
一個是上述的手動打包問題可以說，還可以發揮的地方有，如果專案程式碼過多，影響構建效率，當我們的程式碼還在測試階段時，有時候改bug可能要頻繁構建，如果構建慢就很影響測試進度，甚至有時構建慢影響到緊急bug的修復上線，此時可以針對構建工具比如webpack做一些相關配置，相應的就是要對webpack的相關配置提前有所瞭解。
也可以說說單測，前提是去了解下常用的單元測試工具。
還可以從程式碼規範著手，講講eslint、husky等，提高團隊的協作效率；組織學習工作方面的分享，提升技術的同時防止一些問題的重複發生；提取公用程式碼，減少重複勞動。等等。