隨著前後端技術演進，姑且不論是否採用微服務(microservice)架構，前後端分離成為越來越常見的開發模式，例如前端採用 NEXT.js 等框架，或者編譯成靜態網頁(static site)部署在雲端，所需要的後端 API 功能則是呼叫部署在另一個網域(domain)的伺服器，例如下圖：
不過採用此種前後端分離的架構，就需要理解何謂 CORS(Cross-Origin Resource Sharing)，才能讓前端正常運作。
p.s. 通常有用到前後端分離架構的公司，就有可能問到何為 CORS 。
後端工程師日常不僅要跟程式、作業系統、架構搏鬥，也要跟資料庫(database)打交道。
資料庫的類型也隨著時代演變越來越多，除了 NoSQL, In-memory database 之外，面試過程最常聊到的還是關聯式資料庫(relational database management system)，而且關聯式資料庫也是目前業界常見的資料儲存系統，各個公司無論規模大小或多或少都會有關聯式資料庫的存在，除此之外，關聯式資料庫也相當適合用以儲存交易(transaction)類型的資料。
因此操作關聯式資料庫需要用到的 SQL(Structured Query Language) 幾乎成為後端工程師面試時的必考題，而且考 SQL 的好處在於它是一項標準，無論你是 MySQL 還是 PostgreSQL 還是 MS SQL Server 的使用者，基本上都能夠用 SQL 進行交流。
本文來介紹經常會被問到的 SQL 面試問題吧！
Last updated on Oct 17, 2023 in 後端面試準備 by Amo Chen ‐ 8 min read
在程式設計中，平行處理可能會同時訪問共享資源，這樣就可能導致共享資源的競爭與執行結果不一致等等問題。
為了避免這些問題，就需要使用 lock 進行同步，保證在同一時間只有一個執行緒或 process 能夠存取共享資源。
所以在面試中，許多面試官都會考面試者對於 lock 的了解和應用。常見的考題包括 lock 的原理、種類、常見問題和解決方法等。
了解 lock 的使用不僅僅可以應對相關面試問題，也有助於在實際開發中知道如何使用 lock, 以避免平行處理所造成的相關問題。
談到快取，一定會談到 Cache 的置換策略，也就是快取滿了要怎麼處理的問題。
理想上，能將所有資料都快取起來的話，就可以有效加速系統回應時間以及減輕資料庫負擔，但這是相當耗費/浪費系統資源的作法，除了系統資源有限之外（記憶體有限、儲存空間有限），另外根據 80/20 法則，系統中 80% 的資料存取要求，可能僅僅來自那 20% 的資料，我們僅需要針對這 20% 的資料進行快取就能夠在有限資源的條件下，十分有效地提升系統效能。
所以一般快取都會設定大小(size)，不會無限制的快取任何資料，也因此談到快取就會談到快取的置換策略，在 cache 滿的時候選擇刪除哪些舊資料以容納新資料的方法。
本文將介紹幾種面試常見的快取置換策略。
後端（或全端）工程師面試時除了 leetcode 之外，遇到系統設計相關的題目也是高機率（打工仔越來越難當😭 ByteByteGo Youtube 頻道有提供不少系統設計面試會遇到的經典題目解說
Posted on Feb 8, 2023 by Amo Chen ‐ 2 min read
面試時，每當談到平行處理(parallel processing)、多執行緒(multithreading)、多行程(multi-processing)之後，通常都會衍生一些關於 race condition 的問題，也可稱為 race hazard（競爭危害）。
本文以實際 Python 範例創造 race condition, 以理解何為 race condition 以及如何解決 race condition 所造成的問題。
快取(Cache)也是經常會被問到的經典題目。
隨著資訊技術的發展，工程師的面試越來越五花八門，面試過程問什麼都不足為奇，不過仍有些問題能夠事先準備，這些問題不僅常問也很實用，除了能夠應付面試之外，也能增加個人實力。
本文記錄後端工程師面試時經常會問到的資料庫 ACID 原則，並以實際範例作為說明，以讓人能夠對 ACID 有足夠的理解，避免死背。