面試問答
修改code 讓代碼可運行、寫出 print int 出來的順序、考 reference & value type、寫出 MVC, MVVM, DVI 的差別、寫出一組 protocol
這些是紙本的題目，可...
在華山附近，公司有四層樓，工程師都在四樓工作，沒有電梯，不過整體環境都蠻明亮乾淨的，感覺是舒適的空間；
人資帶去小會議
室寫一個手寫的題目，時間半小時，特別說可以開書考，也是很特別；
之後會由部門同事跟主管一起面試，分別會問很多關於Objc的問題，這部分需要準備很齊；
最後主管會問你的期望薪資，以及想問的問題，就會結束面試。
如果符合條件還會有二面給ＣＴＯ，但我肯定是沒了。
不過我看去年有面試的前輩經驗，看來好像沒對到也沒差了，預算看起來只有60K。
面試問答
修改code 讓代碼可運行、寫出 print int 出來的順序、考 reference & value type、寫出 MVC, MVVM, DVI 的差別、寫出一組 protocol
這些是紙本的題目，可以開書考
如果要重構，會從哪裡開始？
遵循 「由外而內、由淺入深」 的策略：
建立 Bridging Header： 這是混編的第一步，讓 Swift 能調用現有的 OC 程式碼。
從「模型層 (Model)」與「工具類 (Utils)」開始： 這些類別通常不涉及 UI，邏輯較獨立且易於單元測試，適合優先轉譯。
新功能全面使用 Swift： 停止在 OC 中開發新功能，確保技術債不再累積。
ViewController 的漸進替換： 當 Model 層穩定後，再開始遷移 UI 層。
善用 @objc 與 NSCopying： 確保 Swift 的 API 在 OC 中仍能正常調用，保持相容性
Objc vs Swift 的差別
Google it
Objc 的 strong, copy, assign, weak 差別，為什麼 NSString 要用 copy
防止傳入的是 NSMutableString。如果用 strong，外部修改該字串時，你的屬性值也會跟著變，這會造成邏輯錯誤
第三方套件跟原生SPM的差別
CocoaPods:
優點： 歷史悠久、生態系最完整，支援 OC/Swift 混編非常成熟。
缺點： 會產生 .xcworkspace 並修改專案設定，編譯速度較慢，且需要額外安裝 Ruby 環境。
Swift Package Manager (SPM):
優點： Apple 原生整合在 Xcode 中，不需第三方工具，設定簡單，編譯效率高，Git 版控乾淨。
缺點： 對於非常老舊的 OC 套件支援度有時不如 CocoaPods。
未來有新增套件需求會用哪個？原因？
首選：Swift Package Manager (SPM)。
原因：
原生整合： 不再需要處理 Podfile 或執行 pod install，直接在 Xcode 介面輸入 URL 即可。
專案維護： SPM 直接整合在 .xcodeproj 中，不會像 CocoaPods 那樣產生複雜的層級結構。
未來趨勢： 這是 Apple 官方推廣的標準，絕大多數主流套件（如 Alamofire, Kingfisher）都已完美支援。
注意：除非遇到僅支援 CocoaPods 的老舊私有庫，否則新專案應全面擁抱 SPM。
Delegate 的限制有什麼？
Delegate 是 iOS 開發最常用的模式，但它有以下幾個主要限制：
一對一限制： 這是它最大的特點也是限制。一個 Delegate 只能對應一個 Receiver（接收者），無法像 Notification 或 Combine 輕鬆達成「一對多」廣播。
強引用循環 (Retain Cycle) 風險： 如果忘記將 delegate 宣告為 weak，很容易導致 ViewController 無法釋放（Memory Leak）。
代碼分散： 當一個 ViewController 實作太多 Protocol 時，代碼會變得很長且分散，不易閱讀。
耦合度： 雖然定義了介面，但委派方與受派方之間仍存在一定的依賴關係
面試建議
不曉得為何跟之前面試過的前輩問題差蠻多的，都沒問我 universal link。
這裡就是接案公司，客戶就是他們官網有提到的那些，專案主要都是 OC and Swift，所以很看重你的OC能力。想錄取的人務必準備好相關問題。感覺沒機會用到新技術，要思考一下。
ummm 我承認我準備的不夠周全，有些問題答不出來，但感覺主管已經覺得不太耐煩，不過他也是努力撐著讓自己表現得有耐心。
時不時覺得我問的問題都很淺，結尾常問我「這樣有回答到你的問題嗎？」
也聽說二面的技術長，是一位大媽，然後他們預算只有60K，供參。
