軟體工程師如何應對面試的可怕「反烏託邦世界」?

2020-12-15 CSDN

作者 | Jared Nelsen

譯者 | 香檳超新星,責編 | 夕顏

以下為譯文:

那些嘗試

我的電話響了。

「你好,我是Jared。」

「嗨,你好,我是「某搜索和廣告行業巨頭」的人,來對你進行電話面試。」

「是的!我一直在等你們的電話!」

「好的。你可以寫出在二叉樹中找到第K個最大值的算法嗎?」

我頓了一下。大腦完全空白。我從來沒有經歷過這樣的情況。空白的Google doc仿佛在盯著我一樣,光標的閃爍就像被放慢了。我東拼西湊了個東西出來,作為第一次的嘗試。

「你能為這個算法寫個測試用例(test case)嗎?」

當然。如果我的思維沒有完全被迷霧環繞,且我的自尊心沒有在因為看著夢想消失在自己眼前而引發的無能狂怒下消弭,我是可以寫出那個測試的。過去幾個月以來所有的辛勤付出就得到了這樣的結果?19年1月左右我就決定要找一份新工作了,然後就仿佛是雲端之上的軟體工程之神對我賜福了一樣,一位來自「某搜索和廣告行業巨頭」的招聘人員在LinkedIn上聯繫了我,希望對我電話採訪。這太完美了!

這種情況不是第一次發生了。作為一名剛畢業,稚氣未退的天真的年輕工程師,我最近開始了自己的第一份工作,並且做得很好。但是後來我的世界天翻地覆。我遇到了一個非常磨人的bug,然後做了任何有自尊心的軟體工程師在嘗試自己動手解決問題之前都會先去做的事情:Google搜索。當我在搜索框中鍵入了圓潤的問號並按下Enter鍵後,屏漸漸黑了下去,然後我掉進了一個shell中。

您剛才用的是我們的語言......想接受一個挑戰嗎?

1.好的

2.不了,謝謝

溫熱的Costco咖啡剛入口,我差點一口噴出來。我幾乎就快要跳起來,尖叫著讓我的同事們來看看了。但是後來又突然擔心起來,是不是自己出現了幻覺,並意識到如果真的是幻覺那會很尷尬。我一邊擔心著自己即將經歷一次靈魂出鞘的體驗,一邊按下了1。

給定一個包含n + 1個整數的數組nums,其中每個整數都在1到n之間(包括1和n),你需要證明數組中至少存在一個重複的數字。如果只有一個重複的數字,請找出該數字。

您有24小時的時間!

我心臟病都快被嚇出來了。又一杯Costco咖啡下肚,我終於使自己稍稍振作,然後才意識到自己完全有能力解決這個問題。我腦子裡已經有了解決問題的計劃。然後我照計劃做了。當我點擊提交按鈕時,另一個需要解決的問題馬上又出現了。就這樣繼續了五個來回,每次的問題都變得越來越難。在提交終極問題後,我收到了另一條消息:

恭喜您!這段代碼很強大!現在有一個「某巨頭搜索和廣告公司」的面試機會,您想要嗎?

事情的經過就是這樣。就像這樣,我的整個職業生涯發生了變化。世界上最強大的組織之一進入了我22歲的大腦,並改寫了一個寄存器的內容。我從前所有的職業規劃都不做數了。在此之前,我很無知但也很幸福地認為這樣的頂級公司並不在我的選擇範圍之內。但是顯然,不知怎麼的,事實已經證明我是他們值得考慮的人選了。

電話採訪的過程很像我做的這個噩夢。我被要求在45分鐘內寫出Conway’s Game of Life。我其實發揮得很好。我寫出了整個程序並進行了測試,以證明它可以正常運行。但第二天我收到了拒絕的信息。我的內心既崩潰又困惑,自己到底做錯了什麼?我所做的所有算法題都沒用嗎?這家公司為什麼會要求我在這麼短的時間內寫出這麼難的算法?

鑑於我在這個級別的難度的面試中的初次經驗,我決定下次要加大自己的努力程度。下一次的面試在19年4月。我為自己建立了一個為期3個月的學習計劃,並盡力追趕。早上我起床以後做三道練習題,然後去上一整天的班,然後回家跑會兒步,吃點東西,再回到我的辦公室裡,為的是能在一個安靜的工作環境中做更多的練習。在三個月的時間裡,我總共做了114道練習題。涉及的主題包括數組,回溯,二叉搜索,二叉樹,廣度優先搜索,深度優先搜索,動態編程,圖,貪心算法,散列表,鍊表,概率,排序,棧和字典樹(trie, pl.tries)等等。做了這麼多準備工作,我沒理由不成功了吧?

苦難

在「某搜索和廣告巨頭」的面試化為灰燼了。我無法解決那個問題。但這僅僅是一整年裡瘋狂的起點。起初,我對於申請哪些公司很有策略性。我不僅僅是想要「一份工作」而已,我想要的是「對的那份工作」。

接下來面了一家自動駕駛公司。提交申請後我很快就得到了回復,並被安排了代碼面試。面試時,面試官怒氣衝衝地用很重的口音告訴我,讓我編寫一個非常複雜的圖像過濾算法。我寫完了,並要求對方給予反饋。他說:「看起來非常好!」結果第二天,我收到了一封官話版本的拒絕電子郵件。

然後是一家分析公司,讓我把一道題帶回家去做。題目只有三句話。我盡了最大的努力,並寫出了一個非常複雜的多線程圖像處理系統。後來招聘人員禮貌地拒絕了我,當我要求反饋時,對方告訴我代碼「效率太低」。

在那之後是一家付款處理公司。我與一個招聘人員有了一段很順利的電話交流,她稱讚我的簡歷與職位描述很相符。第二天,我收到了她的一封電子郵件,說公司裡找不到適合我技能的職位。

另一個例子是在「某社交媒體平臺巨頭」的面試。「Jared!感謝您的申請!我認為您將成為本司的重要成員!我已將您的申請直接發送給了您所在地區的招聘經理!」正在收到此電子郵件的八分鐘之後,我又收到了一封自動發送的拒絕郵件,說我的技能不適合該職位。

與我聯繫過的第三方招聘人員不計其數。但所有這些機會最後都沒有什麼結果。這裡面我最喜歡的大概是一個音頻處理公司。招聘人員聯繫了我,說團隊在看過我的簡歷後非常希望能與我談談,她將聯繫招聘經理安排電話面試的事宜。一個星期以後,我聯繫對方問問是什麼情況。招聘人員說,她已經與招聘經理取得了聯繫,經理認為我的技能與他們團隊不匹配。這對我來說是完全講得通,因此我就繼續去做自己的事情了……但是後來,抱著嘗試的心態,我向他們的另一個職位提交了簡歷,立即有另一名招聘人員聯繫我了。當他們馬上安排了電話面試時,我很驚訝。但是不得不承認,這場面試我只能說是表現平平。第二天我收到了官方的拒絕電子郵件。

然後,我終於得到了一個「某社交媒體巨頭公司」的現場面試機會。我在四場不同的面試中與許多人一起群面,歷經了一系列編程問題,並對所有問題都給出了正確且令人信服的回答。

一路上,我被問到一系列複雜而困難的「跟我聊聊……那時候的事情吧」這樣的問題。這令人耳目一新,因為這是我在找工作的過程中第一次遇到考察我作為一名工程師的經驗和聰明才智的情境。接著就是最後的系統設計面試。面試官及時地給了一個小的系統讓我設計。我開始談論自己的解決思路,面試官在每一步上相應地提出問題。最後,我們終於到了最後關頭,面試官說:「好吧,現在我們有個微服務架構……所以說您有能力設計嗎?」我馬上回答說,我在微服務方面沒有任何經驗。他不解地看著我,問道:「你沒有嗎?」我回答說,「是的,我沒有。我在簡歷中已經儘量說清楚了我在桌面,嵌入式系統和移動開發中的技能和背景。」他頓了一下,看起來就像意識到自己犯了一個錯誤一樣。呵呵,可真是棒棒噠!所以這個人傳達給我的信息就是,我花了整整4個月的時間為這個面試準備,工作之餘的每個醒著的時間段都花在了做練習題,以及排練如何在軟技能問題中表現我的技術背景上,但他連花10來分鐘瀏覽一遍我簡歷的耐心都沒有。

分析

對於在求職的艱辛過程中的那些令人失望透頂的經歷,我能說上一年。這種事情太多了。一直以來,我無論是在面對自己還是他人時都力求對自己的技術實力保持誠實和謙遜的態度。那種需要多年經驗(我不具備的),以及需要某種我不會的技能的工作,我都不會去申請。當然,我打算從嵌入式領域回到Web領域,但我是有兩年的Web工程師經驗的,更不用說我還有作為行動應用程式開發人員和機器學習算法研究人員的經驗呢。我完全承認,我在很多很多方面都還有成長空間,在職位上需要學習的東西也很多。但另一方面,我也非常有信心,我是有能力快速地開始從事一份新工作的。在我看來,軟體工程是一種由學習和新經驗提煉出來的一種藝術形式。沒有哪個軟體工程師會只追求在某方面達到「還算精通」,並在他或她職業生涯的全過程中一直都在那個水平上止步不前。至少我是不希望有這樣的軟體工程師的:這樣的人很快就會被別人落下,敗者食塵。那麼,我的面試到底是怎麼回事呢?在長時間經歷這種反烏託邦過程之後,我覺得有必要把各過程分開來分析一下我的觀察結果,然後再復盤,以獲得一個更清晰的全局觀。

1、我們被自己造的神話迷惑了——軟體工程師們往往都崇尚一種認知,尤其是在當今這個技術爆炸的世界中,大家都認為會有那麼一類獨來獨往,特立獨行的程式設計師,任何需求他們都可以輕鬆地用算法解決。這類原型軟體工程師們的人設是不參加任何社交,反對結構,且極度理想主義。他或她的人格是極度獨立的,不需要與任何人交流就能把工作搞定。因此,由於我們無意識地相信這種人設,我作為工程師必須先通過一個可以測試這些特徵的篩選,才有資格跟對這個職位有所了解的人進行交談。但是,其實用常識思考一下,就能明白這些特徵實際上並不能表明候選人的能力有多強。軟體公司是一個或多個軟體團隊的集合,而團隊又是多名個體的集合。

要在一個有著共同目標的團隊中取得成功,作為個人必須:與他人交流——團隊中只要有一位成員不了解目標,就會給整個團隊拖後腿。與其他工程師(非軟體方面的工程師)交流——不管有多少軟體工程師不喜歡這件事情,事實就是,要運營一個軟體公司不僅僅需要軟體方面的工程師。服從指令——關於產品的指令通常來自軟體團隊之外。這大概就是為組織工作的要點:你要去實現的並不是你自己的願景。相互學習——團隊中成員之間的知識面肯定是不平衡的,在產品和技術方面的知識都是如此。集體團隊的集體技術技能之間存在有權重的平衡。這就是為什麼公司內部會有按經驗劃分的等級制度和職責分配。這種平衡永遠不是,也永遠不該是靜態的。應該永遠都有人在學習,而且永遠都有人在教別人。到目前為止,總結一下就是:似乎促成了招聘流程結構的是「怎樣才算一名軟體工程師」的流行觀念,而不是軟體工程師身上真的能讓他們在工作中取得成功的特質。

2、我們都知道算法題只是人為設計出來的遊戲而已——由於多方面的原因,要闡明這一點比較難。

說到底,這些算法到底有多少價值?——這個問題眾說紛紜。不論我怎麼反駁,總是會有一些團體相信你無需了解算法的工作原理,甚至不需要知道數字計算機就可以成為一名非常優秀的軟體工程師了。我的相反意見是,飛機維修工和航空工程師之間是有差異的。哪一個更有價值,你又更願意成為哪一個呢?這個問題留給你自己思考吧。更好的問法是對於算法相關性的詢問。那麼算法又究竟有多相關呢?——儘管我十分相信,算法知識以及計算機內部的工作原理對於成為一名成功且有價值的軟體工程師來說非常重要,同時我也明白,而且所有其他人也都明白,這些知識很少能在工作中用到。「非我發明」(Not Invented Here,表示一種對外界解決方案的牴觸風氣)的思想無處不在,並被強加給團隊。對於大多數應用程式來說,這是一個好策略。如果已經有一個經過充分測試並能夠穩操勝券地滿足需求的庫了,那麼顯然用它來整合會比重新造輪子要更安全且更合適。就好比說,圓形的輪子已經很好了,為什麼非要用其他形狀的呢?因此,如果要考慮與此問題相關的算法題目,那就令人覺得奇怪,我們幹嘛非要問這些問題。如果行業中有那麼多人都認為算法題在軟體工程師的日常工作中沒有什麼價值,那麼為什麼我們要用這些題目來衡量軟體工程師的水平呢?算法題的陰暗面——對於生命中的許多哲學問題,這些有毒的算法題是有陰暗面的。事實是,有大量的人都在試圖湧入科技行業。在LinkedIn上發布了一個職位後,不到一天的時間,就會收到一百多名求職者的申請。幾乎沒有哪個公司有能力來面試他們所有人。真實情況是,這些算法題目是作為一種機制來篩掉那些不適合該職位的或沒有「基本」編程技能的應聘者的。問題在於,在這種情境下,大家似乎對「基本」一詞含義的理解都有所不同。我們不知道算法題的合適難度是什麼樣的——在過去7個月的面試過程中,我在面對算法題時遇到了各種各樣的困難。簡單的遇到過要求寫一個函數來倒置字符串,難的遇到過要求模仿一個社交網絡以及寫一個圖像過濾算法。曾經有一家公司要我進行了兩次單獨的代碼面試。第一場中我被要求寫一個簡單的排序算法,我輕鬆搞定了。第二場我被要求使用動態編程編寫一個遞歸置換生成器,這可不簡單。當時我完全被難住了。在面試結束時,我問面試官:「這個問題對於電話面試來說似乎有點難了。貴司的業務代碼經常用到遞歸算法嗎?」他回答道:「不是的,我們不用遞歸。」「那麼置換呢?你們用到過嗎?」他回答說:「我們的算法不需要用到置換。公司大多數工程師們的工作重心都在用戶界面和基礎架構上。」其實這一點我能理解。舉這兩個例子是想展示不同公司中對相似的技能水平職位的要求。那麼,為什麼這兩家公司選擇的面試題目難度不同呢?這種衡量方式比俄羅斯轉盤好點有限——假設你是一名面試者。在過去的幾個月中你一直在研究所有可能的與編程面試有關的問題。然後假如說你申請了A公司。A公司要求你寫一個二叉樹搜索算法。太棒了!上周你剛剛複習完了二叉樹!你順利通過了面試。然後再假設你申請了B公司。B公司要求你實現一個字典樹(trie樹)。啊啊啊不要啊!你忘了複習字典樹!因為你沒有複習到這個問題,所以最後沒能通過面試。現在顛倒順序,假如說B公司問你二叉樹算法,A公司問你字典樹算法:那麼顯然,能否被某家公司僱用純粹取決於你被問到哪個問題。時間限制是有害且帶歧視性的——通常在電話篩選中,對方給你解決代碼問題的時限是45分鐘。用這些時間來解決一個簡單問題綽綽有餘。但是,當對方要求你編寫一個複雜的算法時,45分鐘就顯然很荒謬了。當我被要求寫出Conway’s Game of Life時,我花了50分鐘才寫出能夠運行的代碼,然後我就幾乎沒有時間來進行測試了。當我被要求編寫圖像過濾算法時,光是理解題目我就花了15分鐘。最後我時間不夠了。如果是在現實世界中,編寫這樣一個複雜的算法,可能需要一周的實施時間以及一個月,甚至更長時間的實際測試才行。這是最起碼的。那麼為什麼我們會要求工程師們在面試中45分鐘就搞定呢?面試的過程催生了一種小作坊式的生意——所有這些算法題的亂象都始於像Google這樣的知名公司。有一些在這些受歡迎的科技公司工作的工程師,他們發現可以通過為應試者們提供些面試準備材料來賺點外快。有兩本這樣的書很有影響力:《破解編碼面試》(Cracking the Coding Interview)和《編程面試要素》(Elements of Programming Interviews)。這兩本書都旨在提供指導性的面試準備材料。問題在於,行業也接觸到了這些書籍,並根據書籍的內容制定面試計劃。然而,隨著越來越多的人都能夠通過這些書中列出的基本面試問題了,這些公司就會覺得他們選出來的候選人的技能是最低檔的。因此,他們就編寫了新的,更具挑戰性的算法問題,以與其他公司區分,並篩選出「所有看似合格的候選人中間那些更為合格的候選人」。有關某些公司現在的和以前的最高級工程師的軼事有很多,他們說現在的面試過程越來越難了,要讓他們現在去面試,肯定會被刷。我看過一個演講,裡面的故事很棒。在某「頂級」科技公司中,流程是當候選人進行面試時,他或她會產生一份包含面試表現的數據包。然後,數據包由一個委員會接手,這個委員會的工作就是公正地審查數據包,以決定是否僱用。直到有一天,委員會變得過於挑剔,以至於在連續的數月裡他們連一個候選人都沒接受。HR們聽說以後,決定進行一項實驗。他們向委員會發送了新一輪的數據包,而委員會也再次拒絕了所有候選人。HR們隨後召集他們參加會議,並解釋說,他們剛剛查看的數據包實際上就是委員會成員們在面試進入公司時所產生的。也就是說他們不知不覺中自己拒絕了自己!在這樣的標準下還有誰能通過面試呢?3、既然要衡量候選人的能力,那為什麼不花點時間了解一下他們呢?——幾周前,我看了一個某位在「頂級」公司進行過大量面試的面試官的演講。用他的話說,他的演講的目的就是精煉出一個能「在面試中提取信號」的策略。啥?!現在的人就不能好好了解一下他人嗎?這種態度完全就像是冷漠的機器人,而且說實話,很反烏託邦。以後又會變成什麼樣子?是否要掃描候選人的大腦來尋找和已知的高水平候選人之間的相似之處了?這種態度散發著自我主義和組織男子氣概恐怖地組合到一起之後的惡臭。在我看來,現在的公司更害怕招到糟糕的候選人,而不會為可能招到優秀的候選人而興奮。在公司們能再次對招聘感到興奮之前,對求職者來說,情況恐怕不會有改善了。最糟糕地方在於,現在求職者從招聘人員那裡得到的第一條信息就是,你看上去是個很好的候選人,但是一旦進入面試,你只會發現對方只會懷疑你名不副實。我認為,應以謹慎的樂觀態度而不是懷疑。

我很確定這個話題我還可以一直說下去。我的筆記中還有大約八點要寫。但是到現在,這篇文章看起來更像是一篇抨擊的長篇大論,而不像一篇博文了。我希望至少能夠表達一下在過去七個月裡自己遇到的一些困難。到了後來,我發現自己很矛盾。我現在的老闆剛剛解僱了我所在的整個團隊,然後我就失業了,只能獨自寫下自己這一肚子的苦水。我不確定是不是想要再次經歷一遍求職的過程。我想了很多,從自己的經歷裡總結出了一些簡單的結論:

我知道如何編寫軟體——兩年來我已經寫了大約85,000行Java生產代碼了,這些代碼對我正在開發的產品產生了非常積極且顯著的影響。我用Python寫過一些非常複雜的機器學習算法,同時也寫了許多腳本。我還為嵌入式圖形等等各種底層應用程式寫過嵌入式C和C ++。我自學了Flutter,發布過一些應用程式。我自學了Clojure,這個過程極大地打開了我的眼界。我參與過一些C#項目。我知道如何建立一個靜態網站。我擁有一個計算機科學學位。我不知道為什麼其他人不給我編寫軟體的機會——公眾們號稱的公司絕對渴望僱用軟體工程師的說法,與一名軟體工程求職者面對的殘酷現實之間完全是不相符的。這些「要麼做對要麼死」的高壓編程題似乎更像是一種模糊機制,而非有價值的評估工具。使用這種工具就像是在僱傭一名警察時,直接朝他開槍,卻並沒有先問他對法律有什麼了解。我不知道站在面試官的角度是什麼樣的——事實是,我所批評的流程可能是公司篩選好壞候選人的唯一方法。我從未參與過招聘流程,肯定有些事情是我所不知道的。我的結論是:

適者生存原則是真實存在的——不管我覺得自己多麼有資格得到一份知名科技公司的高薪職位,事實就是,還有很多其他人在與我競爭。就像生活中的其他一切事情一樣,資源是有限的,但人們的需求是很高的。每個人以及他的哥哥/弟弟都希望通過寫代碼獲得豐厚的報酬。我懷疑,業界之所以會設置如此兇殘的篩查標準的原因是,客觀地來說(不管這裡的客觀二字意味著什麼)技能水平較低的人所佔的比例要比那些有真才實學的人高得多。不幸的是,這意味著無論你經驗多麼豐富,都必須與大量的對手競爭。正如任何經歷過編程學習過程的人都能理解的那樣,即使只是最低限度地把基礎技能掌握熟練,學習曲線都是非常陡峭的。除此之外,勝任一份工作所需的核心能力的知識體系是非常廣泛的。而且,要熟練掌握一套特定的相關且可以市場化的技能是很難的,想做到遊刃有餘更是難上加難。無論一個人成為軟體工程師時走的是哪條路,很顯然的一點都是,競爭是生活中無可避免的事實,並且在這個行業中還相當激烈。等級結構是真實存在的——我對招聘啟事中軟體工程師的分級感到困惑。似乎只分為兩個等級:「非高級」以及「高級」。一般而言,招聘啟事中的高級職位往往要求5年的工作經驗。這種分級似乎不夠細。我們要如何稱呼擁有20年經驗的人呢?他們真的和5年經驗的人一樣嗎?就我自己而言,我們要如何稱呼具有4年經驗的人?我不算是剛畢業生的,我自己知道如何編寫軟體,我知道版本控制如何工作以及如何適應敏捷環境。根據不同的情況,我需要別人為我的工作設定方向。而問題的複雜性甚至不止如此,還存在著在具體的某項技術方面經驗年限的問題。如果一個人有5年的Java編程經驗,後來轉到了一個使用Python的團隊,並且團隊內沒有在Python方面超過兩年以上經驗的人,那麼這個人應該被定為初級人員嗎?這個問題令人困惑,光這一點就值得寫一整篇文章來討論,即使那樣,甚至都可能討論不出個所以然來。我想說的重點是,我是介於初級人員和高級人員之間的,而適合我經驗水平的選擇似乎很少。抱怨並沒有什麼用——或早或晚,我都將不得不去另謀一份差事。即使我不喜歡這種面試方式,也將不得不再次陷入這個循環。但暫時來說我已經受夠了。因為一遍又一遍地重複相同的過程似乎不可能有什麼結果。終有一天,我還是會坐上旋轉木馬,但目前,我還是先選擇讓自己保持理智的唯一方法吧:那就是先暫時退出這個循環。

原文連結:

https://www.jarednelsen.dev/posts/The-horrifically-dystopian-world-of-software-engineering-interviews

本文為CSDN翻譯文章,轉載請註明出處。

相關焦點

  • 如何應對軟體測試工程師面試
    隨著手機、電腦、平板等電子產品越做越好,人們在關注其硬體配置的同時,也越來越重視軟體的使用感。與此同時,隨著網際網路行業的高速發展,各類軟體層出不窮,軟體類公司越來越多,對於專業人才的需求量也越來越大,那麼對於想要進入軟體行業、成為一名測試工程師的求職者而言,應該如何應對軟體測試工程師面試呢?基礎知識要掌握軟體測試工程師是一個專業性比較強的崗位,在面試時,面試官會通過一些專業性的問題來判斷求職者的基礎知識水平。
  • 軟體工程師面試的十個問題
    許多軟體工程師的面試都著重於技術技能,例如對程式語言的了解。但是,一些企業面試官還會注意你的其它一些細節,接下看我們一起看一下十個非技術相關但也十分重要的問題。面試1.「為什麼要成為軟體工程師?」這是一個在面試中非常常見的問題,作為一名軟體工程師,建議通過強調開發熱情來回答這個問題。
  • 加拿大(北美)軟體工程師工作與面試
    對於剛畢業的學生、新移民要找到軟體工程師的職位可能是一個新的挑戰,今天我分享一下我個人關於如何在加拿大或北美尋找軟體工程師工作的經驗。 首先介紹一下IT行業的特點。這個行業最大的特點就是它的變化非常快,快速的變化給這個行業帶來了很多的機會,也給從業者提出了更高的要求。
  • 如何去面試軟體測試工程師?面試官教你怎麼回答!
    如何去面試軟體測試工程師?面試官教你怎麼回答!找工作,找更好的工作,永遠是職場人士特別是網際網路這個人才流動性巨大行業的永恆話題。提到找工作,則又離不開對於面試的探討。網上存在著諸多面試相關的文章攻略,不過站在面試官角度談面試的卻很少。本文就站在面試官的角度,談一談一個面試是怎麼組織的,有哪些技巧和思路。
  • 軍隊文職軟體助理工程師面試_福建軍隊人才網
    廣東軍隊人才網提供以下軍隊文職考試快訊信息:軍隊文職軟體助理工程師面試_福建軍隊人才網,更多關於文職面試,軍轉幹考試快訊的內容,請關注廣東軍轉幹考試網/廣東人事考試網!
  • 面試軟體工程師,這些準備工作你做了嗎?
    編者按:本文作者 Connor Leech 是在灣區工作的一名網頁開發人員,他在本文中面向那些正尋求找到一個軟體工程師崗位的求職者,探討了他們在面試環節可以採取的準備工作。雖然各個公司對於評估人才有自己不同的標準,但軟體工程崗位面試大致可分為兩類:特定領域知識面試和計算機科學基礎知識面試。求職者了解公司評估方式之後,也就可以有的放矢,分別採取相應的準備策略。
  • 一位軟體測試工程師兩個月的面試總結
    三、阿里&淘寶:兩個都是電話面試,對這種面試形式不太習慣,都在下班後來的電話,主要問測試技術相關知識,兩個電話面的都沒結果。  四、三維通信:上市公司,新大樓不錯。先是HR的面試,問的很多,聊的蠻久的,後面是技術面試,感覺他們不是做純粹軟體測試,因為他們的產品大體是基站的擴放器之類,測試側重點主要是看儀器。所以聊的不投機,也沒消息。
  • 軟體工程師生存指南
    本文涵蓋以下內容:如何在面試中脫穎而出如何在軟體工程師崗位上生存(並壯大)需要持續改進時,應當尋找何種資源在你的軟體工程師職業生涯開啟的那一刻,你不得不面對一個不爭的事實:面試真操蛋。面試對於身處其中的每個人都是夢魘。
  • 面向軟體工程師的面試準備–以Google為例的完整指南
    面試的難易程度取決於您在Google中應聘的軟體工程角色的水平。軟體工程師或SWE-II(3級)是入門級的全職軟體工程師。在這個級別上,有4或5個現場回合,L3和L4的風口浪尖(如下),他們可能會提出設計問題,但一般不會。SWE-III(4級)適用於博士學位等。在這個級別上,至少要進行4到5個現場回合,至少還要回答一個系統設計問題。
  • 軟體工程師生存指南:面試準備、工作經驗和實用工具
    但是如何才能拿到這份工作?又如何才能做好這份工作呢?擁有相關經驗的 Valeri Alexiev 提供了相關建議和工具。其中包括了如何準備面試、如何以軟體工程師的身份工作以及如何持續改進方面的經驗之談。我剛開始工作的頭幾年是緊張學習的時間。我得面對現實,成為軟體工程師需要有很多技能,這些我之前都不知道。回顧過去,顯然學會那些東西是很好的。
  • 軟體測試工程師面試經驗之談
    以下是一位從事軟體測試工作的朋友在招聘和面試的一些經驗與心得之談,希望對大家找工作能有所幫助。?我們這些測試人員,都是搞技術的IT人士,不能穿的象個新新人類,試想一下,你作為主考官,見一個身穿乞丐服、頭戴鴨舌帽的人進來應聘測試工程師,你會相信他的技術嗎。所以在面試時,一定要穿潔淨、整齊的職業裝或者夾克,或者適中的風衣。女士稍微畫一點淡妝,男式記得刮鬍子。頭髮都要梳的整齊。
  • 軟體工程師必讀的10本書,你讀了嗎?
    然而,在該領域也有一些書籍歷久彌新,比如那些探討元主題、設計模式或者一般思維模式的軟體工程類書籍。在下文筆者列出的書單中,就包括目前最熱門、最暢銷的軟體工程類書籍。下文所推薦的書目非常經典,至今依舊光彩熠熠,並且頗受高級軟體工程師們的推崇,因此常將其推薦給初級開發人員。
  • 經驗貼丨我是如何用五步招到軟體工程師的
    這篇文章比較長,所以我將它分成五個部分:關於招聘的問題我要找的技能我如何發現候選者我如何招聘工程師我犯過的錯註:如果你正在找一些書來幫助你成為軟體工程經理,這裡有一些我最喜歡的:https://在現實世界中,程式設計師在一個人的注視下用模糊的算法解決問題,沒有時間進行獨立研究,也無法獲得資源。如果那是我的日常工作,我絕不會做這份工作。考查程式設計師不需要掌握的東西,並期望了解他們在公司的工作方式,這是妄想。這類面試只會讓招聘團隊有優越感,並確保擁有傳統計算機科學背景的工程師可以獲得更好的結果。
  • 軟體工程師崗位面試技能解讀
    編輯的話:做為軟體工程師,在入職一個企業之前,技術面試是必不可少的一個環節。面試官通過對應聘者進行提問交流,考察應聘者的技術能力。但是往往技術面試問題考察的並不單是應聘者對問題技術本身的考察,更多的是基於對面試問題背後的學員的思考能力、設計能力、邏輯思維能力甚至團隊協作能力的考察。
  • 一位面試了20+家公司的測試工程師,發現了面試「絕殺四重技」!
    故將我的面試經驗分享給你們,希望每一個看過這篇文章的朋友都可以過五關斬六將,鎮定自若,信心滿滿地應對面試!【一】面試軟體測試,你需要知道哪些?常言道:知彼知己,百戰不殆。那麼對於面試軟體測試中,我們需要知道哪些方面,才是我們制勝的法寶。
  • 如何去面試一個測試工程師崗位?
    如何去面試一個測試工程師崗位???全手敲,少了些美觀,多了些乾貨,面試必備葵花寶典,覺得還不錯的,多多支持哦!做測試培訓不少年頭了,積累了一些面試的經驗和技巧,接下來幾期打算重點說一下如何去面試軟體測試崗位以及面試所遇到的問題,希望能夠幫到大家,也祝大家找到滿意的軟體測試工作。01 去外包還是直招的公司?
  • 如何寫一篇殺手級的軟體工程師簡歷
    —— Dale Carnegie,(《如何贏得朋友並影響他人》的作者)我們可以想到無法獲取面試的兩個解決方案:本篇文章將會著重講解前者,因為無論你最終採用那種方式來得到面試,實際上每家公司都是用你的簡歷來作為評估的基礎。因此,接下來我們一起仔細分析我的簡歷,並且著重學習如何寫一篇出色的簡歷。
  • 軍隊文職面試助理工程師軟體工程_軍隊人才
    廣東軍隊人才網提供以下軍隊文職考試快訊信息:軍隊文職面試助理工程師軟體工程_軍隊人才,更多關於軍隊文職面試,軍轉幹考試快訊的內容,請關注廣東軍轉幹考試網/廣東人事考試網!
  • 千鋒分享:軟體測試工程師常見面試題
    我們面對一場未知的軟體測試工程師面試能夠做的除了做好本質工作,還有就是一些基本的面試題也是需要了解的。正所謂,機會永遠是留給有準備的人的。如果你好好的面對面試,那你肯定收穫的會比沒有準備的多得多。下面是千鋒軟體測試培訓講師總結的一套關於軟體測試的面試題(節選),為你的求職增加一些成功的機率。01.
  • 即將到來的軟體世界末日,作為程式設計師該如何應對?
    隨著程式設計師熱切的將軟體運用到重要的系統中,他們會成為構建世界的主角,但是 Dijkstra 認為程式設計師們可能高估了自己。軟體工程師不理解,也並不關心他們正解決的問題什麼致使編程變得困難?編程需要程式設計師像電腦一樣思考。在計算的早期,代碼採用 1 和 0 來表示就更顯得奇怪了。