2022 年有意義的Java面試題 – Galovics

關於 2022 年或前幾年的 Java 面試問題有很多內容。在本文中，我將向您展示我在 2022 年的幾個 Java 面試問題以及我的觀點。

從Cassandra遷移到PostgreSQL

問題是這樣的。有一個專案執行了幾個月，有30個人在做這個專案，這個應用是用Cassandra作為資料儲存的。該產品還沒有投入生產。客戶來了，說我們需要在兩個月內投入生產。你的反應是，嗯，這是可行的，我們已經準備好了。我們需要做一些事情，但它肯定會符合2個月的時間表。然後客戶說，是的，但是我們在一個雲供應商那裡得到了一個很好的交易，它沒有Cassandra，但是它支援PostgreSQL。你是工程師，要決定下一步該怎麼做。你會怎麼做？

這就是問題所在。這就是問題所在。看到它有多開放了嗎？我至少問過100多次這個問題，我從來沒有得到過相同的答案。

你可以專注於很多事情，比如。

你到底要如何按時重寫整個資料訪問層到PostgreSQL？

如果重寫工作不知不覺地完成了，你到底要如何確保所有的工作都能正常進行呢？

如果你會要求客戶尋找其他支援C*的雲端計算解決方案

C*和PostgreSQL之間的差異；以及為什麼重寫會有困難

而這些只是更廣泛討論的起點。無論候選人提出什麼，我都會深入瞭解。如果他們開始談論技術方面的問題，例如最初在Cassandra層使用Spring Data，那麼切換到Spring Data JPA就像是對程式碼的最小改動。我們會越來越深入，問更多的問題。

如果他們開始談論測試，我們就深入討論測試。他們想象中的測試過程是怎樣的，他們會在哪裡劃定測試覆蓋率足夠或不夠的界限，諸如此類的問題。

如果他們很會說話，他們可能會開始討論如何讓客戶改變使用的雲供應商的策略。展示一個關於做遷移與只是去另一個雲供應商的成本評估。

不管是什麼，我都會深入挖掘，並提出其他開放式的問題，引導整個討論，看他們的思維過程。

我經常改變這個問題，不問Cassandra/PostgreSQL，而是問他們用什麼NoSQL/SQL DB，並比較這兩個。比如MongoDB和MySQL。

你將如何開始一個全新的專案？

這是一個多層次的問題。您可以完全專注於您組織的實踐，但我想看看如果候選人是選擇該技術的人，他們將如何從頭開始一個全新的專案。

例如，這裡的常見答案是 Java + Spring Boot + Hibernate 組合。然後我通常會問他們為什麼會選擇那個。這只是我們開始的另一個問題。我們可以討論為什麼候選人認為 Spring Boot 是一個很好的專案啟動器。他們可以談論框架本身，他們可以談論該框架在行業中的大規模採用，他們可以談論這樣一個事實：在這種情況下，未來招聘可能比選擇一個外來的框架更容易，無論如何。這會帶來越來越多的問題，你只需要在候選答案中找到它們。

休眠也是一樣。我個人是 JPA 和 Hibernate 的忠實信徒，但我知道它有它的位置。而且我根本不會為大多數專案選擇它，因為如果開發人員不小心，很容易導致嚴重的效能問題。但這是您可以詢問的另一個方面，即候選人在使用 Hibernate 時是否有任何效能問題。

你如何除錯一個效能問題？

問題是這樣的。你有一個網頁使用者介面，一個後臺和一個用於儲存資料的資料庫。產品負責人在JIRA中建立了一個新的bug ticket，說如果他點選頁面上的一個按鈕，需要5秒鐘才能收到操作成功的通知資訊。你會如何除錯這個問題呢？

這又是一個非常開放的問題，有多個焦點。

有人開始談論JIRA票據的質量問題

有人開始分析從前臺到後臺的問題

有人會談論缺乏測試，以及這個問題是由使用者而不是由自動測試發現的事實

有人開始討論可用的監控和跟蹤工具

如果候選人談到了JIRA票據，讓我們討論一下一個好的bug報告應該是什麼樣的，其中應該有什麼樣的資訊。如果這一點已經確定，你將如何強制要求錯誤報告具有一定的質量要求。

如果他們開始分析問題，我們經常討論他們把問題分解成可操作的部分的過程。比如如何檢查前臺，那裡是否很慢。然後如何檢查後端，哪些部分慢。如何分析/檢查資料庫的查詢，如果它們很慢，等等。

如果他們談到了測試，那我們就來討論測試。這也是非常有趣的一點，因為效能測試不像單元測試那樣黑白分明，有很多問題需要討論。

如何處理程式碼審查中的個人衝突？

這個問題是建立在兩個開發人員之間在程式碼審查中出現分歧的想法上的。比方說，一個開發者提交了一個PR，另一個需要檢查。另一個開發者在那裡發表了一些評論，而作者並不同意這個評論，並認為這是個人行為。你會如何處理？在這個問題上，我通常關注兩個不同的角色，要麼你是一個高階開發者，需要幫助在兩個開發者之間達成協議，要麼你是對PR發表評論的那個開發者。顯然，這個角色取決於我面試候選人的工作。

這又是一個非常開放的問題，沒有完美的解決方案。但是，要處理這種情況，肯定需要一個好的溝通者。

您會根據哪些屬性來選擇資料訪問框架？

你會選擇 JPA + Hibernate 嗎？你會選擇 jOOQ 嗎？你會選擇 MyBatis 嗎？你會使用 Spring Data JPA 嗎？您會編寫自定義資料訪問層嗎？

這些選項可能會引發很多問題。基本上，如果有人快速說“X”，我問的第一個問題是“為什麼是 X？”？

您需要考慮很多屬性：

• 表現
• 可維護性
• 靈活性
• 文件
• 安全
• 行業採用，也就是僱傭具有這種技能的人是多麼容易
• 工裝
• 可測試性

以及更多。但接下來我要問的是“你說的 Z 是什麼意思？” （Z 是屬性之一）。

你什麼時候會在專案中使用微服務？

儘管我對何時應該將微服務應用於某個問題有我個人的看法，但我願意聽取其他人的想法。對於這個問題，它主要是一個聽力遊戲。

如果候選人提出了有趣的觀點，請提出後續問題。這裡沒有完美的答案，我不希望任何人嘗試重複微服務有希望的所有花哨屬性（在紙上），而是分享關於問題空間的真實想法。

他們可以談論：

• 擴充套件應用程式和團隊
• 組織困難——時間緊迫、管理不稱職等。
• 他們以前如何以及為什麼使用微服務
• 他們會選擇的技術堆疊
• 服務間通訊的潛在困難

以及更多。