[答疑]為什麼面試的時候不考核心域的知識
- 2019 年 10 月 6 日
- 筆記
織網的老男孩 2019-1-24 16:35:
潘老師的《軟體方法》強調主攻自己的核心域知識，而較為忽視非核心域知識—電腦基礎等，工作中確實用不到，但是現在工作面試中就喜歡關注這些平時用不到的非核心域，每逢面試，很多都需要臨時抱佛腳準備這些，用不上的東西又容易忘，各位怎麼看，怎麼應對的
。。。。:
我覺得潘老師的戰略是對的，核心域的知識是核心競爭力，必須重視，但是也不是說非核心域的基礎就不管了，非核心域的多體現在設計階段，是這個階段裡面能力的體現
織網的老男孩:
明明是搞java業務開發的，大家現在都揪著jvm的種種不放，對工作基本無益。 現在市面招聘感覺有點像高考選拔，考察的知識不一定有用，但是你要會，考察範圍基本默認圈定了。:
現在的說法不是"招聘造航母，入職擰螺絲"嗎？~~
大多都是這樣的。比如阿里。
現在業界java面試，jvm，各種鎖問題，是一大重頭戲，應用開發基本是用不到的，這些基本都是中間件解決了的。於是乎，大家都苦哈哈的研究jvm, 各種鎖。而甚至忽略了基本工作技能的修鍊、提高。
深切感受到人力學習資源的浪費或者說個人時間的浪費，都在做無用功。和高考應試很有點像了，面試結束找到工作了，突擊的知識點，長久不用，又容易生疏了。再要面試，再擼一遍，即使平時不斷學，用不上的東西，也比較難深入
UMLChina潘加宇:
@織網的老男孩 因為面試者本身就沒有掌握業務建模、需求、分析的技能，所以只好考一些自己懂的技能。如果我是面試者就不一樣了嘛，一道一道題都有講究。
織網的老男孩:
是的，我也這樣認為的，很多互聯網公司軟體開發這塊是沒有章法的。 但是，又得面對這種不學不行的局面。所謂的知識焦慮。
UMLChina潘加宇:
書里也有講
很多能夠帶來利潤的系統，它的核心域卻沒有那麼多人去研究。很少有類似這樣的書，把一家電廠的流程，各種概念之間的關係，用某種方式（UML的類圖、序列圖、活動圖，以前的數據流圖、E/R圖）表達得清清楚楚。
在這方面，不少媒體有誤導。媒體會訪問某些"知名程式設計師"對建模的看法，得到的回答可能是"對我來說不重要"。這裡面的原因是：基礎設施領域的程式設計師更容易得到媒體青睞成為"知名程式設計師"， "晶片"、"作業系統"、"編譯器"等辭彙上的光環更容易撩撥媒體從業人員的興奮點。
開發團隊A研發出了Aware，獲得市場的認可，開發團隊B利用Aware研發出Bware，也同樣獲得市場的認可。根據我們上面所說的，研發Aware和Bware各有各的複雜度。但是需要批評一種現象——開發團隊B里的某個開發人員在使用Aware的過程中產生了錯覺，以為研發Aware才是"技術"，把大量的精力用來思考Aware的核心域知識，卻對Bware的核心域知識不屑一顧。不客氣地說，媒體熱愛的一些"知名程式設計師"就是以上描述的實例。一邊拿著公司的薪水，卻不好好思考如何吃透公司的核心域做好公司的項目，把大量精力投入到自己的小愛好上，在網路上博得名聲。
某開發人員喜歡鑽研"底層"。明明本職工作是編寫一段計費的C#程式碼，他偏偏要花時間深入研究到編譯器、作業系統甚至硬體，而且確實也搞清楚了一些門道。雖然工作是耽擱了，但該開發人員卻獲得了"勤奮好鑽研"的名聲。其實還有另一個更值得鑽研的"底層"：怎樣才能使這段程式碼更容易維護和擴展？這段程式碼達到的功能和性能對涉眾意味著什麼？……
過分熱衷於鑽研"底層"，這樣的行為更像是偷懶而不是勤奮，畢竟比起離開電腦去搞清楚質管部和生產部之間有什麼利益上的衝突，研究MSIL的語法要容易得多，愉快得多。
所謂"底層"也只是另一個領域的知識，那個領域自有另外的人去研究。玩票式的鑽研，在真正專註研究這個領域的研究者看來，實在是不值一提。但是人性的弱點如此，正如錢鍾書所說："蝙蝠碰見鳥就充作鳥，碰見獸就充作獸。人比蝙蝠就聰明多了。他會把蝙蝠的方法反過來施用：在鳥類里偏要充獸，表示腳踏實地；在獸類里偏要充鳥，表示高超出世。向武人賣弄風雅，向文人裝作英雄；"[錢 1982]
織網的老男孩:
是的，就是看到書裡面相關內容了。
