Interview on 施星宇

關於 Mutex、Semaphore 與 Spinlock

Sat, 15 Aug 2026 19:48:32 +0800

起源

今年年初在準備一些嵌入式系統相關的面試時，又遇到了 Mutex、Semaphore 跟 Spinlock 這三個東西，其實之前在面一些大廠時就有被問過，像是某薯條公司或是某水果公司，但當時沒什麼準備，所以答得也不是很好，所以趁著準備面試時再來複習一下，有修過作業系統的人對這三個名詞應該不陌生，只要碰到 RTOS、Linux Kernel 或是多執行緒程式之後多少都會遇到

其實如果沒有特別去記，大多人的印象都是：

「Mutex 不就是鎖嗎？」
「Semaphore 好像也是鎖？」
「那 Spinlock 又是什麼鬼，為什麼已經有 Mutex 還要再多一個 Spinlock？」

而且三個東西印象中都像是在做同一件事情：不要讓大家同時碰同一個東西，所以這篇一樣想用一個超級白話的方式把這三個東西整理起來，以免哪天又忘記 Mutex、Semaphore 跟 Spinlock 到底差在哪裡，就可以快速回來複習一下

所以為什麼會需要這些東西？

我們先不要管 Mutex、Semaphore 跟 Spinlock 這些東西各自在幹嘛，先設想一個情境好了，如果今天寫的是一個超級簡單的 Bare Metal Firmware：

1
2
3
4
5
6
7


main()
{
 讀 Sensor
 控制 Motor
 更新 LED
 ...
}

CPU 就這樣一件事情一件事情照順序做下去對吧，其實很多時候根本不會需要到什麼 Mutex 或 Semaphore，這就是我們在 MCU 上最常見的寫法，也不太會有什麼問題，因為同一個時間基本上就只有現在這段 Code 在執行，可以自由使用系統裡的資源

但如果我們今天需要系統有多個執行緒分別去跑不同的邏輯，開始使用 RTOS，例如 Zephyr、FreeRTOS、ThreadX，那情況就不一樣了

我們假設系統裡面有三個 Thread：

1
2
3


Sensor Thread
Motor Thread
UI Thread

通常 MCU 只有一個 CPU Core，而 RTOS Scheduler 會在不同的 Thread 之間快速切換，例如說系統裡可能同時有用來收集 Sensor 資料的 Sensor Thread、用來控制馬達狀態的 Motor Thread 跟用來顯示裝置狀態的 UI Thread，Scheduler 會讓它們輪流使用 CPU，雖然這些 Thread 並不是真的同時執行，但只要其中一個 Thread 做到一半時切換到另一個 Thread，另一個 Thread 就有機會碰到還在被前一個 Thread 使用的資源，在 Single Core 上，前一個 Thread 雖然已經暫停執行，但資源可能仍處於使用中的狀態，而在 Multicore 上則真的可能發生同一個資源被兩個跑在不同 Core 上的 Thread 同時存取，所以問題就來了：如果兩個 Thread 同時想要操作同一個東西怎麼辦？

例如 Motor Thread 跟 UI Thread 可能同時修改 Motor 的控制狀態，或是 Sensor Thread 跟其他 Thread 同時存取某一塊 Shared Memory，這時候如果沒有適當的保護就會出問題

我們先從一個最簡單的狀況開始，假設有一個很單純的變數：

1

counter++;

看起來只是一行，但 CPU 實際上通常需要先讀取 counter、加一，再把結果寫回 Memory

如果 Thread A 跟 Thread B 都在差不多的時間讀到 counter = 10，它們最後就可能各自寫回 11，明明執行了兩次 counter++，結果卻只增加一次，這個大家在作業系統課程裡應該都有學過，這就是很典型的 Race Condition，而 Mutex、Semaphore、Spinlock 這些東西，本質上就是為了解決這類 Concurrency / Synchronization 問題而存在的

嚴格來說，並不是說「Bare Metal 就絕對不會有這種 Race Condition」，實際上只要有 Interrupt、Multicore 或其他非同步的 Execution Context，其實 Bare Metal 一樣可能碰到 Synchronization 問題，只是說一般在嵌入式韌體開發中，這些搶佔情形比較常出現在開始使用 RTOS、Linux 或其他有 Thread / Scheduler 的系統之後，即使只有單核心 CPU，只要系統存在 Preemption，一個 Thread 在 Critical Section 中被另一個 Thread 搶走 CPU，一樣可能產生 Race Condition，Linux Kernel 的文件也特別指出，即使只有一顆 CPU，Preemption 仍然可以造成類似的 Race Condition（Linux Kernel Documentation — Locking）

所以回到 Mutex、Semaphore 跟 Spinlock，這些可以理解為是作業系統為了管理這種搶佔狀況而提供的同步機制，也就是說如果我們今天只是用 Bare Metal，那通常就沒有 RTOS 直接提供的現成 Lock 可以用啦，如果需要就要自己在系統裡去刻出來了

OK，所以知道問題從哪裡來之後，接下來就看看這三種東西到底分別在幹嘛，以及想解決什麼問題吧

Mutex：這個東西現在是我的，你們先不要碰

先從最好理解的 Mutex 開始，Mutex 全名是 Mutual Exclusion，從名字就差不多知道它想做什麼：

同一個時間，只允許一個 Thread 進來

假設 Motor Thread 跟 UI Thread 都可能修改同一顆 Motor 的狀態，我們不希望其中一邊正準備把轉速設成 1000 RPM，另一邊突然把它改成 200 RPM，兩個 Thread 一起修改 Driver State 或 Hardware Register，最後控制結果很容易亂掉而且出現不可預測的隨機狀態，很可怕，這時候 Mutex 就上場了

Thread 在操作 Motor 之前要先取得 Mutex，拿到之後，其他 Thread 就不能進入同一段程式，這段只有 Lock 持有者能執行的區域，就是作業系統課程裡常聽到的 Critical Section

1
2
3
4
5
6


mutex_lock(&motor_mutex);

motor_set_speed(1000);
motor_set_direction(FORWARD);

mutex_unlock(&motor_mutex);

等 Thread A 操作完 Motor 並 Unlock 之後，Thread B 才能取得 Mutex 繼續執行，這樣兩個 Thread 就不會同時碰同一個硬體資源了，Zephyr 對 Mutex 的建議用途也是讓多個 Thread 互斥地存取同一個資源，像是保護一個 Physical Device（Zephyr Project Documentation — Mutexes）

當然，Mutex 保護的不一定是硬體，也可以是 Shared Memory、Linked List、File、I2C Bus、SPI Bus、UART 或 Driver State，總之呢，只要某個東西同一時間只能讓一個 Thread 操作，第一個可以想到的通常就是 Mutex

這時候一定有人會好奇說，那如果 Mutex 已經被別人拿走，系統又是怎麼調度 Thread B 呢？

其實做法很直接，RTOS 會把 Thread B 從 Running State 移到 Blocked State，接著讓 Scheduler 從 Ready Queue 裡挑選其他可以執行的 Thread，例如 Sensor Thread，這段期間 Thread B 不會一直檢查 Mutex，也不會繼續消耗 CPU

等 Thread A 呼叫 mutex_unlock()，RTOS 再把 Thread B 移回 Ready State，如果 Thread B 的 Priority 比目前執行中的 Thread 高，就可能直接搶占 CPU，否則就留在 Ready Queue 等待下一次調度，所以這也是 Mutex 跟後面 Spinlock 很重要的一個差別：Mutex 等不到的話，可以睡

一個實際的例子是 Linux Kernel 裡的 Mutex 就屬於 Sleeping Lock，拿不到 Mutex 時，Task 可以 Suspend，讓 CPU 去執行其他工作（Linux Kernel Documentation — Locking）

Semaphore：我不是在鎖東西，我是在數「還有幾個」

接下來來說說 Semaphore，中文通常翻作「信號量」，這個名字第一次看到其實不太容易懂，其實可以把它想成一個裝著 Token 的盒子，假設盒子裡有三個 Token，Semaphore Count 就是 3，每當 Thread Take() 一個 Token，Count 就減一；有人 Give() 一個，而且 Count 還沒有到上限時，Count 就加一，所以 Semaphore 最核心的東西其實就是：一個 Counter（Zephyr Project Documentation — Semaphores）

如果 Count 一開始是 3，Thread A、B、C 各自拿走一個之後，Count 就會變成 0，這時 Thread D 再呼叫 Take()，就只能等到有人 Give() 一個回來，這種可以記錄多個 Token 的 Semaphore，就叫做 Counting Semaphore，如果 Count 只有 0 或 1，則稱作 Binary Semaphore

看到這邊可能會冒出一個問題：「等等，Binary Semaphore 最大就是 1，那不就跟 Mutex 一樣嗎？」

沒錯，表面看起來真的很像，但兩者想表達的概念不太一樣：

Mutex 在意的是 Ownership：這個 Resource 現在是誰的？
Semaphore 在意的是 Count / Signal：現在有幾個 Resource，或者發生了幾次 Event？

Mutex 通常有明確的 Owner，也就是哪一個 Thread Lock，就應該由那一個 Thread Unlock，而 Semaphore 則不一定有這種 Ownership 關係，以 FreeRTOS 為例，Mutex 額外具有 Priority Inheritance，而 Binary Semaphore 沒有，因此官方也建議 Resource Mutual Exclusion 與 Synchronization 分別使用不同的 Primitive（FreeRTOS Documentation — Mutexes）

這個差別看起來還是有點抽象，所以我們直接來看一個嵌入式很常見的例子吧

假設今天有一顆 Sensor 不斷取樣，並且把資料暫存在自己的 FIFO，當 FIFO 裡的資料到達某個 Threshold，Sensor 就拉起 Interrupt，通知 MCU：「我這邊累積了一些資料，記得來讀取喔」

MCU 進入 ISR 之後，當然可以直接讀 Sensor Register、搬出 FIFO 資料，再做 Filter 與後續運算，但通常不會想這樣做，因為 ISR 最好越短越好，比較常見的做法，是讓 ISR 只負責 Give Semaphore，再由 Sensor Thread 執行真正耗時間的工作：

1

Sensor Interrupt -> ISR -> Give Semaphore -> Sensor Thread -> Read FIFO

概念上，ISR 只做很少的事情，下面是方便理解的通用寫法，實際使用時仍要換成該 RTOS 允許在 ISR 中呼叫的 API：

1
2
3
4


void sensor_isr(void)
{
 semaphore_give(&sensor_sem);
}

平常 Sensor Thread 則停在 semaphore_take() 等待通知：

1
2
3
4
5
6
7


while (1)
{
 semaphore_take(&sensor_sem);

 read_sensor_fifo();
 process_sensor_data();
}

沒有 Interrupt 時，Semaphore Count 是 0，Sensor Thread 會保持在 Blocked State，不需要一直輪詢 Sensor 有沒有資料，當 Interrupt 發生後，ISR 將 Count 從 0 加到 1，等待中的 Sensor Thread 就會被喚醒；它 Take 掉這個 Token，再去讀取 FIFO

這樣分工就很清楚：ISR 負責通知，Thread 負責真正做事情

Zephyr 官方文件也把這列為 ISR Offload Work 的典型方法：ISR 可以透過 Semaphore 等 Kernel Object 去 Signal 一個 Helper Thread，把比較耗時間的工作留到 Thread Context 執行（Zephyr Project Documentation — Interrupts）

所以從這個例子就很容易看出 Mutex 與 Semaphore 的語意差別：

Mutex 比較像：「廁所有人了，你先不要進來」
Semaphore 比較像：「現在有一件事情要處理」
Counting Semaphore 則可以表示：「現在累積有三件事情要處理」

這邊還有個細節是，如果使用 Binary Semaphore，它的 Count 只會是 0 或 1，假設 Sensor Thread 還沒開始處理，Sensor 又連續觸發了三次 Interrupt，最後的 Count 可能仍然只有 1，也就是說，Binary Semaphore 比較接近「有事情發生了」，而不是精確記錄「事情發生了三次」

如果你的系統需要每一次 Event 都不能遺失，就要考慮使用 Counting Semaphore 並設定足夠的 Count 上限，甚至改用 Queue，Semaphore 可以代表可用的 Resource 數量，也可以代表等待處理的 Event 數量，會比 Mutex 更泛用

Spinlock：反正應該馬上就好了，我站在這邊等

最後來看看 Spinlock 吧，前面說過，Thread 拿不到 Mutex 時可以進入 Blocked State，讓 RTOS 的調度策略去把 CPU 交給其他 Thread，這聽起來很合理對吧，但 Context Switch 其實不是免費的

系統需要先保存目前 Thread 的 Register、Program Counter、Stack Pointer 等 Execution Context，再載入另一個 Thread 的 Context，這些動作當然都有成本，假設 CPU 1 上的 Thread B 正拿著 Lock，但它只剩下 shared_data++ 這種非常短的操作，可能再幾個 CPU Cycle 就會釋放，這時如果 CPU 0 上的 Thread A 立刻 Block、儲存 Context、重新排程，忙了一圈之後，Thread B 搞不好早就把 Lock 放掉了

所以另外一個想法就出現了：

既然我猜它馬上就會用完，那我乾脆站在這裡等

這就是 Spinlock，概念上它會不斷檢查 Lock 是否已經被釋放，也就是直接佔住 CPU 做 Busy Waiting：

1
2
3
4


while (lock_is_taken)
{
 // Busy waiting
}

等待期間 Thread 不會進入 Sleep State，它所在的 CPU Core 也不會去執行其他 Thread，而是一直嘗試取得 Lock，它一直在原地「轉」，所以才叫 Spin Lock

Linux Kernel 對 Spinlock 的描述也是這個概念：拿不到 Spinlock 就持續嘗試；相較之下，拿不到 Mutex 則可以 Suspend，讓 CPU 去做其他事情（Linux Kernel Documentation — Locking）

那 Spinlock 不是超級浪費 CPU 嗎？沒錯，所以 Spinlock 有一個非常重要的前提：Critical Section 必須非常短，否則就會讓等待這把 Lock 的 CPU Core 白白浪費在那邊

例如下面這種很快就結束的操作，才適合使用 Spinlock：

1
2
3
4
5
6


spin_lock();

shared_state++;
update_pointer();

spin_unlock();

如果持有 Spinlock 時去 Sleep、執行很慢的 I/O，或等待 Hardware，其他正在等待同一把 Lock 的 CPU Core 就只能一直空轉，除了浪費 CPU，在許多 Kernel Context 中，持有 Spinlock 時 Sleep 本身就是不允許的

所以可以很粗略地記成：

等待時間可能比較長，而且允許 Sleep：考慮 Mutex
Critical Section 非常短，而且不能或不適合 Sleep：考慮 Spinlock

這就是 Spinlock 最基本的 Trade-off：拿 CPU Time 換掉 Context Switch 與 Sleep / Wakeup 的 Overhead

看到這邊通常就會覺得，哦，所以 Spinlock 是只會在多核心系統上出現對吧

當然 Spinlock 在多核心系統上特別好理解，假設 CPU 1 正在修改 Shared Data，而 CPU 0 也想修改，CPU 0 即使原地 Spin，也不會妨礙 CPU 1 繼續完成手上的 Critical Section；只要 CPU 1 很快 Unlock，CPU 0 就能接著取得 Lock

不過這邊有個很容易誤會的地方：Spinlock 並不是只有 Multicore 才有意義

Linux Kernel 裡還有 Thread Context、SoftIRQ、Hard IRQ 等不同的 Execution Context，其中有些 Context 根本不能 Sleep，如果 Interrupt Handler 拿不到 Lock，我們不能叫它先睡一下，因此 Mutex 這種 Sleeping Lock 就不適合，反而需要 Spinlock 或其他不能 Sleep 的 Synchronization Primitive，Linux Kernel 也因此提供了 spin_lock_irq()、spin_lock_irqsave() 等不同形式（Linux Kernel Documentation — Locking）

所以更完整地說，Spinlock 常見的使用條件是：Critical Section 很短，而且目前的 Execution Context 不適合或不能 Sleep，Multicore 只是這個需求最直覺的一種情境，另外，在某些單核心 Linux Kernel Configuration 中，Spinlock 甚至不一定需要真的 Spin，例如系統沒有 SMP，也沒有 Preemption 時，就不存在另一個同時執行的 Task 可以搶走這個 Critical Section；Linux Kernel 會依 Configuration 對 Lock 做不同處理（Linux Kernel Documentation — Locking）

補充一下，Linux 的 PREEMPT_RT 會改變 spinlock_t 的實作語意，真正會在所有 Kernel Configuration 中維持 Spinning Lock 語意的是 raw_spinlock_t，這篇先用一般 Spinlock 的概念理解就好（Linux Kernel Documentation — Lock Types）

所以 Mutex、Semaphore、Spinlock 到底差在哪？

前面講了一大堆，最後其實可以用三句話快速記：

Mutex：「這個東西現在是我的，你們先不要碰」主要用來保護 Motor、I2C Bus、Shared Data、Driver State 或 File 等 Shared Resource，而拿不到時通常可以 Block / Sleep
Semaphore：「現在有幾個 Event 要處理？」主要用來做 Synchronization、Signaling 或 Resource Counting，而且不一定有 Owner
Spinlock：「它應該馬上就好了，我站在這邊等」主要用來保護非常短的 Critical Section；拿不到時不會 Sleep，而是持續佔用所在的 CPU Core 等待

當然現實世界沒有這麼絕對，不同作業系統對搶佔的實作機制也可能有差異，調度策略可能也不太一樣，但如果只是想快速判斷，可以先從下面三個方向想：

我要保護一個 Resource 嗎？先想到 Mutex
我要通知另一個 Thread「有事情發生」嗎？先想到 Semaphore
我要保護一個非常短的 Critical Section，而且這裡不能 Sleep 嗎？考慮 Spinlock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


 要解決什麼問題？
 |
 +---------------+---------------+
 | |
 保護 Shared Resource Event / Resource Count
 | |
 v v
 Mutex Semaphore
 |
 |
 拿不到 Lock 怎麼辦？
 |
 +-----+------+
 | |
可以 Sleep 不能/不想 Sleep
 | |
 v v
 Mutex Spinlock

結語

總之大概就是這樣了，Mutex、Semaphore 跟 Spinlock 第一次看的時候，很容易覺得三個東西長得差不多，反正都在避免多個 Execution Context 互相干擾，但真正去看它們想解決的問題，思考當初發明這些東西的人的核心思想，就會覺得還真是精妙啊，各自對應不同 Thread 之間的互動情境

Mutex 比較偏向 Ownership / Mutual Exclusion 強調資源的唯一性，Semaphore 比較偏向 Count / Signaling 更適合當有事件發生時的提醒信號，Spinlock 則是在 Mutual Exclusion 的問題上選擇 Busy Waiting，用 CPU Time 換掉 Context Switch 可能造成的額外成本

這些經典機制會被廣泛運用在不同的作業系統中，而它們背後其實都在處理不同的問題，理解這些機制以及它們背後想解決的問題，也能讓我們在設計系統時靈活運用這些作業系統提供的功能

希望這篇對大家有幫助啦

Reference

關於 Aligned Memory Allocation

Thu, 30 Oct 2025 21:48:32 +0800

起源

由於在這個東西上吃了大悶虧，至於是什麼虧就不細究了，總之是我當初在看到這東西的時候沒有認真摸透，就趁著這個機會好好還債了我想要用一個超級白話的方式讓人快速可以理解，下次遇到這個議題再回來看就能快速回憶起來

什麼是 Aligned Memory Allocation？

設想一個情況，今天程式運行到一個地方，如果我需要一些額外的記憶體來儲存新的資料，在 C 語言中我們一定會用到 malloc() 來跟系統要額外的記憶體空間

舉個例子，我現在突然需要 32 bytes 的空間，所以我就使出 malloc()，然後系統就翻啊翻找啊找，最後在記憶體中找到了 32 bytes 的空間，並把起始的記憶體位置傳回來。這個起始的位置可能很隨機，像是 0x08004321，不過這也無傷大雅，總之我現在有了 32 bytes 空間，我現在想對他幹嘛就幹嘛。

然而然而，在某些情況（至於是哪些情況後面再講），我們會希望我們得到的記憶體的起始位置是「對齊」的。那什麼叫做對齊呢？

舉個例子，如果你用一些 Hex 檔案的預覽工具，你會看到左邊的起始位置很整齊以 32 bytes 間隔，像下面這樣：

1
2
3
4
5
6
7
8
9


一般隨機分配 (未對齊):
0x08004321 | Data...
 ^ 起始位置很隨意

32-byte Alignment (對齊):
0x08000000 | Data...
0x08000020 | Data... <-- 0x20 就是 32
0x08000040 | Data... <-- 0x40 就是 64
 ^ 起始位置都可以被 32 整除

所謂的 Aligned Memory Allocation，就是我在要新的記憶體空間時，想要拿到一個起始位置可以被 32（或是其他數字）整除的記憶體空間

OK，所以說到這邊應該對這個 Aligned Memory Allocation 是什麼應該有點概念了，這樣就成功了一半了。因為大多數人第一次聽到應該都比較難想到這是什麼，又或者知道這是什麼，但不知道有什麼用

所以，這個有什麼用呢？

為什麼需要 Alignment？

會需要 Alignment 大多是受到硬體設計的限制，例如：

向量指令集 (如 AVX)，當執行這類指令集的時候，會要求目標的記憶體位置是對齊的，沒有對齊的話得要拆成兩步去處理，或是直接出現錯誤，那為什麼不設計成指令集可以讀取任意位置起始的記憶體呢？我覺得大多是成本考量，如果能從驅動程式端去解決，又何必浪費昂貴的硬體空間呢

其他像是 CUDA 中 GPU 透過 PCIe 抓取資料時，使用 DMA 也會要求記憶體要對齊，又或者 GPU 指令抓取他自己記憶體的資料也會要求對齊，另外在 STM32 這類單晶片上使用 DMA 時，buffer 的記憶體位置也會要求對齊，才能夠被 DMA 正確寫入或讀取

這時候一定有人跳出來說：「我平常用 CUDA 或是在 STM32 上用 DMA 都沒遇到這問題啊！」

那是因為 CUDA driver 或是 HAL library 之類的會幫你處理好，所以當然沒感覺，反過來說，如果你今天寫的是 driver 或是 bare metal 開發，那一定要小心記憶體對齊這東西，不然可能連動都動不起來

所以該怎麼做到 Alignment？

前面說了這麼多，那要怎麼才能做到記憶體分配時 Alignment 呢？

設想今天我們目標要一塊新的 64 bytes 記憶體，並且要求 32-byte 對齊。如果今天 malloc 給的起始位置剛剛好就是 0x08000040，是 alignment block 的起始位置，這樣就中大獎了，但實際上當然不會那麼幸運，他可能給你的起始位置是 0x08000041（偏移了 1 個 byte），也可能起始是 0x0800005F（偏移了 31 個 bytes）

但沒關係，這時候就會想到，只要malloc的記憶體夠長，從中找到一個 Alignment Block 的起點並從那邊開始存資料，這樣也算對齊吧

那麼問題就回到，我們該要多長的記憶體呢？觀察前面的例子，如果做 32 bytes 的 alignment，偏移的量最多就是 0 ~ 31 bytes。所以我們要 malloc() 的空間至少要是 size + alignment - 1

等等，好像少了什麼？這樣的話要怎麼才能 free 掉 alignment 起始位址前面的那些空間呢？我們需要紀錄真正原本 malloc 出來的起始位址，所以還需要再多一個位置去存這個指標，這個需要的空間是 sizeof(void*)

總結來說，我們真正要 malloc() 的長度是： size + alignment - 1 + sizeof(void*)

記憶體結構示意圖：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


實際 malloc 得到的區塊 (Original)
|
v
+-------------+---------------------+-------------------------+
| padding ... | 原始指標 (Stored) | 使用者拿到的指標 (Aligned)|
+-------------+---------------------+-------------------------+
 ^ ^
 | |
 這格存著 original 符合 32-byte 對齊
 的地址 我們回傳這個地址

然後我們只要找到這裡面 alignment 的起始位址，並且把「原始的起始位址」存在 alignment 起始的前一格。這樣在 free memory 時，只要從 alignment 位址往前找一格，就可以找到我們應該要釋放的記憶體起點。

原理概念上就是這樣了，那麼就來看看要怎麼實作吧。

C 語言實作

以下用 32-byte alignment 為例子，可以把 32 換成任意想要的正整數 alignment（通常是 2 的次方）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


#include <stdlib.h>
#include <stdint.h> // 為了使用 uintptr_t

void* aligned_malloc(size_t size) {
 // 1. 計算需要的總空間：
 // size + (alignment - 1) 的調整空間 + 存放原始指標的空間
 void *original = malloc(size + 32 - 1 + sizeof(void*));
 
 if (!original) return NULL;

 // 2. 算出 alignment 的起始位置
 // 先預留一個 pointer 的空間給我們存地址
 uintptr_t raw = (uintptr_t)original + sizeof(void*);
 
 // 利用 Bitwise 操作進行對齊
 // 原理：(address + mask) & ~mask
 // 注意：這裡要用 ~(32 - 1) 也就是 ~31 才能遮掉後五位達到 32 對齊
 uintptr_t aligned = (raw + (32 - 1)) & ~(32 - 1);
 
 // 其實也可以用(void*)(original - (original % 32));去算
 // 只是用bit manipulation感覺比較優雅

 // 3. 把原本 malloc() 的起始位址存到 alignment 位址的前一格
 ((void**)aligned)[-1] = original;

 // 4. 最後回傳 alignment 的起始
 return (void*)aligned;
}

void aligned_free(void *ptr) {
 if (!ptr) return;
 
 // free 的時候，去找到 alignment 位址前一格存的原來 malloc 的位址
 void *original = ((void**)ptr)[-1];
 
 // 然後把它釋放就行了
 free(original);
}

結語

總之就是這樣，Aligned Memory Allocation這個東西重要又有一些實作小細節，藉由這個機會算是有搞懂他了，以後忘了也可以快速回來複習一下

Reference

2023 Google Technical Program Manager 面試經驗

Fri, 07 Jul 2023 12:00:18 +0800

Google Technical Program Manager 面試經驗

前言

一直有許多Google SWE的面試經驗分享，然而Technical Program Manager(TPM)的面試經驗則幾乎沒有，其實不光是Dcard國外各大網站TPM的面試經驗分享也很少，因此來分享一下，雖然沒有拿到Offer，但有面到最後，經驗應該可以參考一下。

過去學經歷是112電資相關學碩，今年當完兵之後在比Google略大一點的公司當TPM。以前就有想進去Google，去年也投了Google SWE的面試，面完過HC等Team match時就遇到Hiring Freeze，詳細經歷可以參考：Google SWE 面試心路歷程，直到今年景氣變好才又開始Fit talk，結果連match了三個team都沒中，心灰意冷之際就收到另一個HR寄來TPM的面試邀請，抱著打聽情報的心態就跟HR排了個1:1，其實本來是對Google TPM缺沒什麼興趣，但在會議中被HR一波洗腦後，抱著那就試試的心態就接下面試邀請了。

時間

5/12 - 收到HR的TPM面試邀請
5/23 - 跟HR約1:1了解職缺
6/13 - VO:Technical Judgement*2
6/20 - VO:PgM + GCA
6/30 - 跟HR1:1通知面試結果: not move forward

面試

Google TPM的VO面試總共有五關，每關45分鐘:

兩關的Technical Judgement面試
一關Program Management related(PgM)面試
一關General Cognitive Ability(GCA)面試
一關Googleyness面試

可能因為之前已經面過Googleyness，所以這關就直接跳過了，實際上只面了四關，考慮到我技術能力可能比PM能力好一點，HR先幫我排了兩場Technical Judgement面試，結果不錯的話再排PgM和GCA，後來也證明這是正確的策略。

根據網路上的情報跟HR提供的文件，我認為Technical Judgement面試可能像是技術面試，可能會問Codeing，也可能會問System design，為此還翻出leetcode刷了幾題暖身；PgM可能會問跟經驗相關的問題；GCA則可能問解決問題的邏輯，但這部分當下也想不到有什麼準備方向，所以我只把HR給的參考資料看完，再多回想幾個小故事，由於實在想不到要怎麼準備，我也想辦法跟HR要些Hint，不過HR看起來已經給我全部能給的東西了，那就硬著頭皮上吧，學習嘛…。

順帶一提，TPM的面試是全英文的，四關差不多兩小時都在不停的說英文，這樣的要求也是可以理解，在Google這種公司Cross-function的溝通是極度仰賴英文的，這點也跟SWE面試很不一樣，SWE只有兩關英文，而且不會一直講話。

Technical Judgement 老實說聽到第一個問題時就開始懷疑人生了，我原本已經擺好寫Code的姿勢了，結果第一個問題是：「你最成功的專案什麼？」(詳細題目記不得了，反正是類似這的問題)，是那種我以為應該在PgM或GCA面試會問的問題，還好之前已經準備了不少小故事，姿勢一換搬出從大學、研究所到工作時做的還算有技術深度的案子，講解要解決的問題、我在團隊扮演的腳色、技術的選擇、克服的問題等，過程有來有回，面試官聽也還算滿意，不過一連的幾個問題也都是差不多這種類型，讓我有種我是不是走錯棚的錯覺，結束時還問了一下：「請問這個是Technical Judgement Interview嘛？」面試官愣了一下回：「是阿」，「Ok…」瞬間好像懂了甚麼又覺得甚麼都不懂，第二場Technical Judgement也是差不多的情況，總之自認表現還行，後來HR的feedback也是說Positive。
Program Management Related Knowledge(PgM) 有鑒於Technical Judgement面試問題實在出乎意料，因此再次問HR有關PgM面試的細節，HR還是回說他給的文件已經有資訊了，那就只能自行腦補了，既然名字叫Program Management那應該就是問PM相關能力吧，那應該多往PM的腳色去回答就行，果然不其然，面試的題目跟Technical Judgement幾乎一樣，而我就搬出之前做專案時怎麼定Scope、怎麼寫Spec、怎麼drive project、怎麼溝通協調，面試官看起來還算滿意我的回答，結束面試前小聊了一下這個position的情報，面試官覺得跟我目前的經驗差距頗大，不過還是祝我Good luck。
General Cognitive Ability(GCA) 到了GCA，我是真的想不到要怎麼準備了，如果是問解決問題的邏輯好像也很難準備。果然這關又問了跟前三關差不多的問題，然後我先從執行面去回答，但感覺面試官不太滿意，因此我又換一條路從技術面切入回答，面試官還是不太滿意，並建議我應該先從更High level的架構回答，因此我再給出了一個這方向的答案，不過沒有想得很透徹，應該是Bug滿滿，自己覺得答的超級爛，有感自己答的很爛，結束前後臉皮的跟面試官請教了一回，他也人很好跟我解釋了每一個問題的回答重點，大方向的概念是要先想出一個解決問題的框架，再將這個框架套入回答問題的框架去依序回答才有辦法打到得分點。

結果

後來再跟HR約了一次1:1，結果跟想像的差不多，前面表現都還不錯，主要掛在GCA，沒辦法再move forward，只能回去等還有沒有team match的機會了。

後來想了一下這次的面試確實有很多可以改進的點，除了現在真的菜，能講的經驗還太少外，就是對TPM面試回答的框架還不夠熟，這邊指的框架像是: 面對PgM的問題可以依序從以下幾點下手:

專案範疇與組織
專案執行
溝通與影響力
釐清模糊不清的情況

面對GCA的問題可以依序從以下幾點下手:

理解問題
蒐集資訊
找出解決方案
支持解決方案的證據
良好的溝通

下次要再嘗試Google TPM的面試時，應該要多花點時間打磨手上的案例，想辦法塞進這些框架組織，然後熟練使用這些框架回答問題，某種程度上也算是刷題吧。

結語

個人覺得TPM的面試比SWE面試還要難而且複雜，即便如此Google似乎很想找有EECS背景且有PM能力的人進去當TPM，只是這類人不多又或者沒興趣所以一直找不到人，如果有相關背景的人有興趣可以去嘗試看看。

如果有看完這篇對你有幫助，就順便祝福我早日拿到Google Offer啦。

附一張今年去101蹭飯的照片，好想進Google呀。

科技業台商與外商公司暱稱

Sat, 06 May 2023 14:52:00 +0800

科技業台商與外商公司暱稱

台商

IC設計 (豬屎屋)

項次	公司名稱	Ptt、Dcard暱稱	說明
1	聯發科	發哥、發弟、M、大M、麥當勞、篤行路麥當勞	分紅多的時候就是發哥，少的時候就變發弟，因為被稱為M，員工自嘲為篤行路麥當勞打工仔，去上班謙稱為鏟薯條。叫大M是因為曾經有小M(晨星)
2	聯詠	滷肉、N	聯詠的英文是Novatek音似「滷肉」
3	瑞昱	螃蟹、R、帝王蟹、寄居蟹、海產店	Realtek、Logo就是一隻螃蟹，帝王蟹專指分紅特別多的部門，如果分紅少，鄉民就鄙稱寄居蟹，因為是螃蟹所以也有人稱海產店
4	群聯	全聯、P、請支援收銀	群聯音似全聯
5	慧榮	S
7	奇景	海馬	Himax音似海馬¹
8	達發	客運、發哥子公司	發哥的一家子公司，英文名是Airoha發音似早期的阿羅哈客運
9	瑞鼎	鼎王	取鼎字。由於鼎王麻辣鍋是相較昂貴的餐廳，故這是分紅好的意²
10	矽創	洗窗	取矽創的諧音
11	敦泰	保全	有一家保全公司叫敦泰保全
12	奕力	一粒、粒粒	奕力的諧音。或取粒字，源自《憫農詩》：「誰知盤中飧，粒粒皆辛苦」，為員工自嘲工作辛苦²
13	華邦電	邦邦
14	信驊	股王
15	新唐

品牌廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	宏達電	紅茶、紅茶店、Hㄒㄈ、阿姨	紅茶店是取諧音，阿姨是指雪紅阿姨
2	華碩	石頭	華碩品質，以卵擊石
3	宏碁
4	微星	小星星、中二龍、微薪、G星	微薪是只薪水給的不多
5	技嘉	雞排店	英文名字是GIGABYTE，GIBYTE發音跟雞排很像²
6	群暉	亞東Google	公司在捷運亞東醫院站附近，跟Google一樣吸引很多軟體頂尖人才

面板廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	友達	戀人、戀人未滿	取名稱：友達以上，戀人未滿
2	群創	包子	之前與奇美電子合併，因奇美包子而得名

系統廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	和碩	皮卡	音似其英文名Pegatron
2	廣達	肉鬆、肉鬆店	有一家肉鬆廠叫做廣達香肉鬆
3	緯創	W、大W
4	緯穎	小w、we win	因為是緯創的子公司
5	仁寶	寶寶
6	光寶	點燈	英文名字LITEON，表示light-on²
7	研華
8	華擎	小石頭、妖擎	因為華擎是由華碩分家出來的所以叫小石頭，又專門生產一些奇怪的主機板和產品(妖板)
9	台達店	三角、三角形	Logo是一個三角
10	鴻海	海公公（取海字）、海邊、海底、紅海	取海字。《烏龍派出所》的阿兩常說：「你家住海邊啊！」這句話意指「多管閒事」（因為海邊鎖管(小卷/透抽)很多）。之所以稱鴻海為海邊，是暗指公司管很多²
11	英業達	小英	名字裡有英字
12	啟碁	道士	取諧音，道士會起乩

半導體製造

項次	公司名稱	Ptt、Dcard暱稱	說明
1	台積電	台GG、GG、護國神山、神山、大哥、祖墳冒煙	因為台灣有台積電因此中國不敢隨便打台灣，所以稱之為護國神山。祖墳冒煙是在說能近台積電的人都是有祖先保佑
2	聯電	二哥、U、大碩	因其員工常以該公司為跳板跳槽至台積電，近似研究所補習班「大碩」而謔稱之
3	世界先進	仙境、RO	取先進兩個字的諧音
4	日月光	神教	出自金庸小說《笑傲江湖》的虛構組織日月神教²
5	南亞科	牙科
6	華亞科	滑牙科
7	矽品	三口、三口組	三個口、很多口的那間、三口組 (因最後一個字品，而被鄉民取這些名稱 )
8	力積電	假G、小GG	叫假G是因為名稱跟台積電很容易混淆

軟體、電信、銀行

項次	公司名稱	Ptt、Dcard暱稱	說明
1	中華電信	種花、種花電信、種花點心、小公司（出自徐旭東）	取諧音，加上工作很悠閒
2	台灣大哥大
3	遠傳	大公司	為網友呼應其老闆徐旭東之言論而謔稱之
4	趨勢	亞洲最大純軟
5	國泰	大樹、花椰菜	Logo是一顆大樹，大樹長的很像花椰菜
6	Dcard	豬腳、低卡、低能卡	取諧音、又Dcard上的發文通常太過浮誇很低能故稱低能卡
7	愛卡拉	卡拉雞

外商

IC設計製造

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Qualcomm(高通)	Q
2	Marvell(邁威爾)	漫威		Marvell發音跟漫威一樣
3	Nvidia(英偉達)	NV
4	Intel(英特爾)	牙膏廠	牙膏廠、藍廠	core i系列每一代效能都高一點點就像擠牙膏
5	AMD(超微)	推土機廠	推土機廠、紅廠	AM3時代處理器名稱
6	Micron(美光)	光光、發光、人生發光		來自徵才標語「加入美光，人生發光
7	Texas Instruments(德儀)
8	Broadcom(博通)
9	NXP(恩智浦)

品牌與軟體設計

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Google(科高)	G	G社、狗家	狗家取字Google的諧音
2	Microsoft(微軟)	M$、MS	巨硬、巨嬰³	M$是指微軟什麼東西都要錢，巨硬來自於微軟字面上的相反
3	Meta(臉書)		臉家、M社	Facebook翻譯為臉書
4	Amazon(亞馬遜)		亞麻、雨林、香蕉廠³	亞馬遜以對員工小氣聞名，公司福利只願意提供香蕉給員工
5	Apple(蘋果)	阿婆	A社、水果家
6	IBM(國際商業機器)	外星科技	大藍	據說真的有從事外星科技
7	Netflix(網飛)		N社、網飛
8	Tiktok(抖音)	父母白養	字節	取自「抖音一響，父母白養」
9	Dropbox		D社、丟盒子
10	Airbnb
11	Salesforce		賣力
12	Orcale(甲骨文)		烏龜殼
13	Sony(索尼)	$ony、大法		相機技術很厲害，就跟魔法一樣
14	Dell(戴爾)	呆鵝
15	騰訊	企鵝		騰訊的Logo是一隻企鵝
16	百度		百毒	中國網友慣稱呼，諧音
17	Uber		黑車
18	Uber Eats	吳柏毅
19	Foodpanda	熊貓
20	Garmin
21	Samsung(三星)	三爽

半導體設備商

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	ASML(艾斯摩爾)	A4ML	阿斯麥	A4ML是只這家公司給的分紅很少，阿斯麥是中國ASML的翻譯
2	TEL(東京威力科創)
3	ASM(先藝)
4	AMT(應材)
5	KLA(柯磊)
6	LAM(柯林研發)

系統廠

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Supermicro(美超微)
2	Lenovo(聯想)

知名企業家

項次	名稱	暱稱	說明
1	郭台銘	果凍
2	Lisa Su(蘇丰姿)	蘇媽
3	Jason Huang(黃仁勳)	老黃、皮衣刀客、AI教父
4	Sundar Pichai	皮柴
5	Elon Musk	鋼鐵人、馬投顧	其言行對加密貨幣很有影響力
6	Sam Altman	奧特曼
7	蔡力行	Rick	聯發科CEO

Google Taiwan Hiring Event Recording

Wed, 26 Apr 2023 09:00:18 +0800

Google Taiwan Campus Talk, 2023 線上直播校園徵才說明會

Date: 2022/11/11
Title: Google Taiwan Campus Talk, 2023 校園徵才說明會
Agenda:

主題	講者
Welcome & Google Culture
Hear more from the Googlers
Fireside Chat with all the

Recording:

Made by Google: Behind the Scenes Livestream

Date: 2022/11/5
Title: Taiwan Made by Google: Behind the Scenes 2022
Agenda:

主題	講者
Next-gen Google Tensor processor
Fireside Chat : Pixel Camera
Live Q&A and Latest Opportunities @Google Taiwan

Recording:

Google 台灣 Platforms 團隊介紹＆徵才說明會

Date: 2022/07/08
Title: 2022 Google Taiwan Platforms Team Face to Face
Agenda:

主題	講者
Google Taiwan Platforms Team at a glance	Director Platforms HW Test/Quality & Eng Labs
Software & Hardware Engineers in Google Taiwan Platforms Team	Hardware & Software Managers
Google Hiring Process & Tips	Recruiter
All You Want to Know - Q&A & See You at Google!	All Speakers

Recording:

Google 台灣軟體開發及測試團隊分享＆招募說明會

Date: 2022/05/18
Title: Google 台灣軟體開發及測試團隊分享＆招募說明會
Agenda:

主題	講者
解密Google 台灣軟體開發團隊
Googler 分享 - Engineering Manager\Test Engineer\Tech Lead 及 Software Engineer
Google 招募流程
Q&A 時間

Google 台灣 Silicon & CPU 團隊面對面

Date: 2022/04/29
Title: 2022 Google Taiwan Silicon & CPU Face to Face
Recording:

Campus Talk 校園徵才線上說明會

Date: 2021/11/18
Title: 2022 Google Taiwan Tech Campus Talk YouTube Livestream
Recording:

Life@Google台灣硬體工程師篇

Date: 2019/07/19
Title: Life@Google台灣硬體工程師篇
Recording:

2022 Google Taiwan SWE 面試心路歷程

Mon, 05 Dec 2022 09:00:18 +0800

一個普通人的Google面試經驗

前言

大學時期正處AI技術火熱發展的幾年，也因此經常有媒體報導AI技術領頭的Google的工作環境，像遊樂場一般的辦公室、吃不完的零食和飲料、五星級的免費三餐、領著百萬年薪上班還可以想睡覺就睡覺，其內部夢幻的刷新我對一份工作的三觀，從那時起對這間公司逐漸產生好奇，儘管好奇，我卻一直抱持著觀望的心態，如此夢幻的企業收人的標準想當然也是異常的高，傳言中只收台大電資的書卷大神或是競賽選手，望向我那慘慘的在校成績，完全不敢想像要如何才能拿到進入Google的門票。

大四那年系上開了企業參訪，地點就是朝思暮想的Google，當下毫不猶豫就報名了，就此開啟了與Google的第一次相遇的緣分，那時候板橋的總部還沒有成立，我們參觀的是位於101的總部，隨著前往76樓的電梯快速上升，興奮的心情難以壓抑，電梯們打開的剎那，迎接我的是我朝思暮想的夢幻國度，原來新聞裡講的都是真的，免費的冰、免費的飲料、免費的五星級三餐，搭配著76樓的高空美景，真有種去度假的感覺，遊樂器材、打盹房也是真的，完全體現了Google對員工的信任，在與帶領我們的員工交流後了解到Google對員工管理的自由，不僅僅是工時上的自由，工作項目上員工也有相當大的主導權，員工甚至可以自行組建小組發起專案，就這樣在震撼中結束了與Google的第一次邂逅，從那之後進入Google成了我的夢想，我深知自己的不足，只能一步步的朝那裡邁進。

大四的暑假有了一次前往美國舊金山的機會，趁著這個機會再次造訪心中的夢想之地，位在山景城的Google總部，不過這次比較可惜沒有人脈可以帶我進去參觀參觀，只能當個觀光客在園區閒晃，雖然說只能從外部看，也能感受到整間公司以Have Fun為中心思想的氛圍，隨處可見的腳踏車、沙灘排球場、還有各式各樣的野餐區域簡直就是個大型的度假中心，後來也去了園區附近的紀念品中心買了不少伴手禮回來，朝聖之旅讓我感受的這間公司迷人的活力與矽谷這個科技業的傳奇之地的魅力，這裡的創造力與帶給世界的改變，我心想未來的某一天，我也希望能來到這裡工作。

回台灣之後進入了研究所就讀，原本就對自己的技術能力不太抱有信心，進入研究所後被各路大神強者環繞，更是讓我深切的感受到想要進入Google還有很長的路要走，在技術能力與研究能力上必須要有更上一層的累積，抱持著這個心態，在被研究進度追趕之餘也儘可能的參與各式各樣的side project、hackathon，也參與了幾個新創專案累積了一些參與新創的經驗，在跌跌撞撞之中夾雜著過人的運氣，在研究所的最後一年極度幸運的拿到了微軟的實習機會，開啟了一年的實習與研究所兩邊跑的生活，儘管這個老牌的軟體公司在Google、Facebook這些當紅的網路公司略顯遜色，但作為老牌卻長青的科技巨頭，仍提供了我不少的成長養分，開發技術能力的提升、專案管理能力的培養，也讓我得以窺見在科技公司中的生活模式。

2021年板橋的Google成立，將會是亞洲最大的硬體研發中心，能預期的是Google在台灣將會有大規模的人才招募活動，進入Google的難度也會較以往稍微容易，我深知想要進入Google這是個非常好的機會，在2021年底我在Linkedin上第一次收到來自Google HR的面試邀約，在與HR面談後了解到這是屬於Google Silicon的Hardware Engineer職缺，招募台灣電機背景或是有硬體開發經驗的工程師，只可惜我完全沒有學過硬體設計，對於verilog是一竅不通，面談後就完全沒有後續消息了…

2022年初聽聞有個學弟進入Google，我厚著臉皮請他幫忙推薦並投了2022年度的Software Engineer校園招募，這一次我總算沒有被拒於門外，順利的拿到了第一次面試的機會，就這樣開始了魔王級的面試挑戰之旅。

背景

112資管系雙主修森林系學士+112電信所碩士，沒有參加過程式競賽，也沒有貢獻過開源專案，只有和幾個朋友做過Side Project和Hackathon，大二修程式設計時因為花太多時間在社團而被當掉，大三重修A+過，資結演算法只能說是普通水準。

準備

差不多從2021年12月左右開始刷題，中間有一段時間在趕研究進度跟過年荒廢了一段時間，過完年後為了要強迫自己刷題買了一年份的Leetcode Premium，現在看起來是很不錯的投資，另外我也有買很多人推薦的Cracking the coding interview不過只有看一兩個不太熟的章節而已，刷題的策略前期我自己是從動態規劃開始練習，那時候是看花花醬的動態規劃終極學習方案系列影片累積思考動態規劃問題的技巧，差不多二月開始開始以寫完Leetcode前100題為目標，首先從Easy開始，然後是Medium，三月時開始以寫完Blind 75為目標，刷完一遍Blind 75後在去看前100題中的Hard題，最後在Onsite前一週努力刷Google面試的高頻率題，不得不說Leetcode Premium都將高頻題整理好了真的蠻方便的(而且真的蠻有用的XD)，這段期間每天會固定上去寫Daily，算是強迫自己每天維持解題手感，刷的題目數量，在Phone Interview前差不多150題左右，在Onsite之前差不多230題左右，相對於各路大神來說應該不算多，不過對我自己而言還算夠，各方面的題型都算是有顧到，自己的感覺是都能夠穩定的解出Medium，Hard則是可以想出可行解。比較可惜的是這段時間沒有找朋友幫忙Mock interview，面試經驗的累積是靠實戰累積，在這之前還面了Amazon、Nvidia。因為Google的Technical Interview至少會有兩關以上的全英文面試，英文也是很重要的一部分，雖然不用到Native specker那樣流利，但至少邏輯要能正確傳達，我英文的部分主要就仰賴實習的時候累積下來的，抱括日常聊天用語與解釋技術的能力，很感謝在這段時間願意跟我交流和我練習英文的人。這一段時間的刷題紀錄

刷題的三圍

時辰

2022/01/20 -> 收到朋友的內推通知信，官網投遞履歷，投的是Software Engineer, University Graduate, 2022 2022/03/07 -> 收到HR來信通知安排面試 2022/03/28 -> Phone Interview 2022/04/07 -> 通知通過Phone Interview，準備安排Virtual Onsite Interview 2022/04/25 -> 第一天Virtual Onsite Interview，兩關Technical Interview + 一關Behavior Interview 2022/04/26 -> 第二天Virtual Onsite Interview，兩關Technical Interview 2022/05/07 -> 通知面試結果most on positive 2022/05/26 -> 得知Hiring政策可能會異動

過程

要說面試有什麼最需要注意的，我會覺得是要保持平常心，這也是我認爲面試最困難的部分，畢竟在跟自己的夢想公司面試，興奮、期待、緊張等情緒交雜，很難保持平常心，在第一次Phone Interview時我甚至前兩天晚上都緊張到睡不著，能做的就是去Youtube上找各種國外講軟體工程師面試的影片來看，提醒自己面試該注意的點，英文類的也順便可以練習英文聽力，以下推薦幾個不錯的影片：

面試流程大解析，用SOP的方式講解軟體工程師面試，淺顯易懂
Google谷歌技术面试经验分享，這個講解面試的過程與注意事項講的很仔細，很有參考價值
How to tech interview Like a Pro，這個用搞笑的方式呈現程式面試的過程，蠻有趣的

Phone Interview

我差不多在預定時間的前十分鐘就坐在電腦前等，不過在預定時間點進去時面試官還沒上來，讓我緊張了一下以爲是不是記錯時間，等了差不多十分鐘後面試官終於來了，很抱歉的表示因為前面有一個會有一點耽擱到。面試官其實是一個親切的中國的小姊姊，一開始問了一個類似字串比對的問題，差不多是Easy等級，基本上一看到題目想到解法了，陳述了解法後面試官也同意這個解法，就花了10分鐘左右完成這題的coding，接著他表示有Follow up，比較像是會重複使用到第一題的概念屬於Medium等級，在思考這題的時候我原本以為只需要重複使用第一題的解法就行，結果發現我第一題使用的解法並非最佳解，到這邊其實有一點慌了，還好小姊姊人很好，不斷引導我去思考更好的解法，最終想出一個更佳的解法並花了幾分鐘實現，面試結束前小姊姊表示其實還有更好的解法，因此又花了幾分鐘請教一下，不過他表示這個解法他自己也沒有想到。個人評價，整體來說面試表現還行，解題並不是很流暢，中間卡了一下，但算是有解出來，所以也不到差。後來是通過了這一輪面試。

Onsite Interview

Technical Interview #1

這一關是一個人很不錯的中國的大叔，也沒有遲到，問了一題排序的變化題，一開始以為是Easy，但實際解下去後發現有Medium難度，完全錯估了這題的深奧程度，最一開始提了一個可行解，但面試官希望我提出最佳解，就這樣在這討論解法的30min中我至少提出了五六種解法，並分析在輸入範圍不同的情況下複雜度的差異，但我都沒有提出最佳解，後來在面試官的提示下想出了最佳解，但時間基本上已經用完了，我只能快速的將想法實作出來，後來想想自己實作的演算法是有Bug的，還好面試官人很好，並沒有很急著要結束面試，反而盡可能多留一些時間讓我完成面試，最後面試官回應我認為這是個很有趣的討論，認爲我提出了許多有趣的想法。有了Phone Interview的經驗後，並沒有讓我比較不緊張，反而一直很擔心面試官一上來就會來一題Hard，就面試情形而言自己覺得表現是比較糟糕的。

Technical Interview #2

這一關是一個懶得說話的小哥，問了一個類似尋找子字串的問題，他先請我思考一個brute force solution我基本上看完題目就有想法直接給出了解法，他聽完後也覺得可以因此就請我實作，我差不多花十分鐘實作完成並解釋了一下時間複雜度，接著希望我提出最佳解，對於最佳解自己其實沒什麼把握，只感覺字串應該可以用prefix tree來處理，因此提出了自己想法，沒想到他回應這是正確的思路，因此接續的想就給出了最佳解，還算順利的完成這一關，難度大概是Medium。在第一關爆掉之後這關心情反而輕鬆許多，有一點隨他去的感覺，大概是因為心情放鬆不少，反而思緒比較清楚，果然緊張才是大魔王。

Behavior Interview

這一關是一個中國的姊姊面試，首先問了一些蠻常見的Behavior question像是團隊的合作以及如何溝通，詳細題目網路上有蠻詳細的資訊，比較特別的是面試官問了一題有點類似產品設計的題目，因為事前完全沒有預料到，只能憑想像回答，但感覺面試官似乎沒有很滿意，面試最後有給個feedback認為我回答的沒有很深入，但他覺得我可能缺少工作經驗，因此回答的不深入也算預料之內。整體來說回答的算尚可，至少都有給出個穩健中庸的答案。

Technical Interview #3

第三關開始就變成了用英文面試，面試官還是中國小哥，不得不說跟同樣母語是中文的人用英文溝通難度真的低很多，可能是因為背後的思考還卡在中文的框架下。面試官問了一個tree traverse然後output路徑的題目，高度相似於leetcode上某題Google高頻題，剛好前幾天刷題有寫到，幾乎是秒想出最佳解，當然看到原題還是很興奮的，大概花了15分鐘講解完以及寫完code之後面試官給了我一個follow up，表面上是上面這題的延伸，但實際上已經轉換成BFS尋找兩點最短路徑的題目，還算是有趣的Follow up，這個變化在leetcode上就找不到了，這題同樣也是medium難度。

Technical Interview #4

第四關是一個沒有什麼表情的中國小哥，問了一個類似blind 75 pacific atlantic water flow的題目，看完題目後第一反應就連想到blind 75這題，事後也證明用同一題的方法可以解決這題，大概花了20分鐘講解跟寫完code後面試官同樣也給了follow-up，不過這個follow-up就沒有前一關有趣，只是單純數量上的增加，用同一題的方法改一下code就解決了，這題難度大概Medium。結果後來反而是這關的面試官認為我寫的code有些微的瑕疵，果然看到熟悉的題目還是不能太大意啊。

後續

我面試的時間已經算是Google 2022Campus Hire的末端了，大部分的缺都已經招完了，所以後來就變成直接沒有Headcount可以進行Team match，因此那時就有心理準備可能會需要等到下一年度的campus hire在繼續。

後來就如同大家所見的，在美國升息的壓力下各大公司開始被迫精簡人力，台灣這邊的campus hire也延到11月才開始，而headcount也必須要等到明年初人力政策確定後才會比較確定，好在面試結果可以保留一年，就祈禱明年還有機會可以繼續進行面試流程。

雖然尚未成功的進入我的Dream company，但這一路上還是很感謝許多人提供的機會以及幫助，此外也感謝協助我的Google HR不厭其煩的提供招聘流程的各種資訊。

Google Interview Leetcode Question Challenge

Mon, 30 May 2022 11:41:18 +0800

Google Interview Challenge

https://www.1111.com.tw/1000w/fanshome/discussTopic.asp?cat=FANS&id=301667

https://www.gushiciku.cn/pl/gyQP/zh-tw

https://hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed

https://docs.google.com/spreadsheets/d/1yRCOJ8KysRVkq0O9IlDriT01tC6lzPapmFO4PCmDJQA/edit#gid=126913158 Google面試準備刷題類型

Arrays
Binary Search Tree
Binary Tree
Dynamic Programming
Greedy
Graph – BFS、DFS
Heap
LinkedList
Recursion
Searching – Binary Search、Quick Select
Stack
String
Sorting
Topological sorting
Trie

Google面試經典題目

coin change
coin change 2
Unique path
Unique path 2
Permutation
Permutation 2
subset
subset 2
search in rotated sorted array
search in rotated sorted array 2
word break
word break 2
jump game
jump game 2
word search
word search 2
combination
combination 2
meeting room
meeting room 2
number of islands
number of islands 2
number of distinct island
number of distinct island 2

BQ準備 Imagine you worked in a project or a team that had a problematic culture Tell about the leading experience of a group project Thinking about a time you were given a large amount of work to complete under the tight deadline Tell about a time you face a problem without having clear solution How do you solve the conflict that happen in the team

Array

Binary

Dynamic Programming

Graph

Clone Graph
Course Schedule
Pacific Atlantic Water Flow (M)
Number of Islands
Longest Consecutive Sequence (M)
Alien Dictionary (Leetcode Premium) (H) Key: directed graph + DFS or BFS
Graph Valid Tree (Leetcode Premium) (M) Key: Check edges number first and then check unconnected component (Graph theory), Union Find!
Number of Connected Components in an Undirected Graph (Leetcode Premium) (M)

Interval

Insert Interval
Merge Intervals
Non-overlapping Intervals (M) Key: greedy
Meeting Rooms (Leetcode Premium)
Meeting Rooms II (Leetcode Premium)

Linked List

Matrix

String

Longest Substring Without Repeating Characters
Longest Repeating Character Replacement
Minimum Window Substring (H) Key: Optimized Sliding Windows!
Valid Anagram
Group Anagrams
Valid Parentheses
Valid Palindrome
Longest Palindromic Substring Key: Manacher’s Algorithm
Palindromic Substrings (M) Key: Manacher’s Algorithm
Encode and Decode Strings (Leetcode Premium) (M)

Tree

Heap

Tips

https://hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed

Funny One

Count Unique Characters of All Substrings of a Given String Key: really special solution
Find the Duplicate Number
Find Leaves of Binary Tree
Split Array Largest Sum Key: Binary Search!!!
Trapping Rain Water
The Skyline Problem Key: Select the building with heapqueue
Largest Rectangle in Histogram Key: tricky Apply with stack!!!
Subtree of Another Tree Key: Markle Hash
Substring with Concatenation of All Words Key: Sliding Window
Longest Valid Parentheses key: Two pointer or DP or Stack
Best Time to Buy and Sell Stock IV Key: Tricky One pass solution (DP or O(k) space)
Design HashSet Key: Multiplicative hashing
Unique Binary Search Trees Key: Catalan number!
Shortest Path in a Grid with Obstacles Elimination Key: BFS + A*
Student Attendance Record II Key: hardhard DP
Guess the Word Key: Game theroy, compare with previous
Min Cost to Connect All Points Key: minmun spanning tree!! (Prim’s or )
Path With Minimum Effort Key: Binary search space
132 Pattern Key: stack+min array