theme: smartblue

前言

經常會被產品童鞋問到關於求職面試相關的問題，作為一隻從業經歷5年的B端產品汪，再回過頭來看待這些標準的面試問題，總是有些不同的感悟。

那麼今天就來分享下在產品求職面試中會被經常問到的幾個問題，供剛入職不久的產品萌新，或者想要轉崗的童鞋作為參考。

如有歧義，以你為準。

我們先來看看計算機是如何解決問題的，首先從具體的問題抽象出一個適當的數學模型，然後設計一個求解該數學模型的演算法，最後用某種計算機語言編寫實現該演算法的程式，除錯和執行程式，直至最終得到問題的解答。

產品經理的工作方式也類似，首先將具像化問題抽象出一個可以描述使用者痛點的使用者場景，然後設計一個最優的可以解決使用者場景中的痛點的產品方案，最後編寫詳細產品設計方案，經由開發實現、測試、交付直至最終解決使用者的痛點。

我們先來看看如何評價一個演算法的好壞：能正確地實現預定的功能，滿足具體問題的需要；易於閱讀、理解和交流，便於除錯、修改和擴充；即使輸入非法資料，演算法也能適當地做出反應或進行處理，不會產生預料不到的執行結果；應當考慮演算法的時間效能和空間效能。

一份優秀的需求文件參考維度也類似。

首先是正確性，需求文件需要正確地描述產品的功能及其滿足的使用者場景；

其次是易讀性，需求文件是面向於開發人員、測試人員，其書寫的邏輯結構必須容易理解並且可實現，而且產品功能不能固化寫死，需留出後期擴充套件的空間；

再次是健壯性，需求文件應該描述各種輸入內容下經由產品功能處理後的輸出結果，並且考慮到各種使用者輸入性錯誤處理和系統判斷規則處理，簡單的如非空判斷，格式錯誤，編碼不存在，編碼未啟用等；

最後是時空性，需求文件規劃的功能需要考慮其時間複雜度和空間複雜度，即時間效率和空間效率。

時間複雜度是產品功能邏輯所帶來的系統計算量，運算過程會消耗時間，示例：計算機讀取資料效率為1000條/秒，假設讀取的資料為組合結構，商品+顏色+尺碼，則500個商品，每個商品5個顏色，每個商品20個尺碼，資料量為5W，則讀取該資料需要50秒。當使用並行20個POD節點，則需要2.5秒即可完成。

空間複雜度則是在系統運算時所佔用的儲存空間，包含程式執行佔用的空間、輸入的資料佔用的空間，以及一些輔助運算的算法佔有的空間。示例：多人同時使用系統，所帶來的操作佔用了系統程序，後來的操作就需要排隊才能執行。

我們可以先來看看線性表的基本功能：初始化一張不包含資料元素的空表，求表長、讀取表中的元素、定位表中的元素、插入一個新資料元素、刪除表中的資料元素。

一個常規的列表應該包含增刪改查4項基本功能。

瞭解了基本功能後再考慮基本的互動邏輯，設想下使用者常用的操作場景，首先點選選單入口開啟一個列表頁面，檢視列表資料或是通過篩選條件檢視指定資料，找到某條資訊後修改或者刪除資料，若沒有符合的資料，則通過新增資料的方式插入資訊。

除了基本的增刪改查外，還可以引入批量操作的功能，對某些具有相同業務場景的資料進行批量修改。

另外，列表頁面可以有2種設計方式，一是展示一個預設圖，即空白列表，需要使用者輸入指定篩選條件才能查詢資料，常用於資料報表等列表設計。由於其資料量大，查詢效率低下且不具有一定業務查詢確定性，則可以讓使用者先提供條件，再根據條件進行查詢。

另一種則是頁面初始載入指定資料，系統已經按照使用者常用使用場景預設好一定的條件規則，並且在頁面開啟時便展示列表資料供使用者檢視。這一種列表設計方式常用於資料量少，且具有高頻業務場景使用的情況。

以上觀點僅為個人閒暇之餘對於一些面試題的思考。想起以前做面試官的時候，開場來來回回問的也就這些，也沒有什麼新意，後面問具體做過什麼專案以及專案細節才是核心。

在此寫下了並分享，算是有做了一次個人覆盤，對比以前的回答也有了些許的不同，這應該算得上是一種進步吧～

你在面試過程中遇到了哪些問題，不妨在評論區留言、討論～