題:
我目前的工作遵循“最壞的做法”。如何在不放紅燈的情況下談論我在面試中的經歷?
user107107
2019-07-22 08:49:27 UTC
view on stackexchange narkive permalink

在我的工作中,絕對沒有代碼審查,沒有測試,沒有版本控制,沒有軟件體系結構,沒有“測試與生產服務器”的概念,沒有代碼註釋。實際上,所有這些都被明確禁止,並且我經常因為編寫註釋或使用小的模塊化功能而遇到麻煩–我的PM說這不值得使用磁盤空間。

每當我在其他地方進行採訪時, ,通常會問我如何工作以及如何進行測試或驗證/驗證。我覺得如果我是面試官,並且候選人應徵者沒有發生這種情況,那將是一個很大的危險信號,而我只是丟棄他們的申請。我應該如何在面試中討論這個問題?

@DarthFennec也許小的模塊化功能僅用於自我說明。(我曾經將1,000行* while *循環劃分為許多較小的功能-感謝神靈,這是綠色條形折疊紙時代,我可以將其打印出來放在飯廳桌子上!-而且沒有新功能已被其他任何東西重用。
你在找誰?你自己還是公司?
1979年,我們發表了很多評論。在彙編程序的每一行上發表有意義的評論被認為是好的做法。
您能澄清一下您當前的工作是否在其代碼方面遇到任何問題?我使用有限的最佳實踐來描述代碼庫,但這些方法仍然有效。是的,如果您必須接管別人的舊代碼,這是很大的負擔,但可以管理。我們所做的唯一測試是使用電子探頭和信號分析儀對盒裝系統進行測試,以檢查結果。沒有人進行過任何測試嗎?您能否提供有關目標設備的更多背景知識?
@WesleyLong-我認為您和其他所有人都在誤解此處的含義。這個傢伙不是說磁盤空間很昂貴,而是說註釋毫無價值。諸如“這本書不值得寫這本書”之類的東西。這並不意味著紙張昂貴,而是意味著書很爛。
相關文章:[當您只是咕Gr咕Get咕Things咕咕咕咕咕咕咕咕咕咕咕,開始做事–軟件上的喬爾](https://www.joelonsoftware.com/2001/12/25/getting-things-done-when-youre-only-a-grunt/)
如果沒有代碼審查流程,那麼公司中的其他任何人如何知道您是否遵循他們的其他不良做法?
讓我們[繼續聊天中的討論](https://chat.stackexchange.com/rooms/96598/discussion-between-phresnel-and-aron)。
十 答案:
Jayce444
2019-07-22 09:03:43 UTC
view on stackexchange narkive permalink

關於如何準備面試,最好的辦法是親自研究這些主題,並從事使用它們的個人項目。

例如,我的第一份軟件工作是類似的,我們沒有採取任何良好做法,因此很難實施。因此,我從事私人項目,在那裡我可以做自己想做的事情並有時間。在那些項目中,我會適當地計劃事情,正確設置src控件,測試所有代碼,註釋代碼並嘗試使其易於理解,可重用和可伸縮等。因此,當需要在面試中談論這些最佳實踐時,即使我在實際工作中沒有接觸過這些最佳實踐,我也對它們有一定的了解和經驗。

我傾向於發現面試官不希望從您當前的工作中獲得這些做法的具體示例,他們只是想知道您知道這些做法及其所涉及的內容。在工作中,您可能不願與他們接觸,但是沒有什麼可以阻止您在這些時間之外進行研究和使用它們的。在職業上明智的做法絕對值得。展現出這些最佳實踐的個人項目即使對於很小的項目也非常適合您。

如果他們絕對為當前的工作實例而努力,那麼我個人只會說您當前的工作並沒有真正做到這一點,因此您需要自己努力學習/練習。這表明了自己的主動性,並可能為他們提供更多關於您為什麼在其他地方尋找東西的背景信息。

好答案。此外,我還將嘗試查找正在遵循的“不良做法”的示例,以及為糾正這些不良做法所採取的步驟(例如,切換到x以減少構建時間y因子,改進測試自動化框架等)。)
這可能會成為一個“克服障礙”的問題。“在實踐中學習這些東西的障礙是上一份工作的老闆。因此,我採取了獨立學習並在個人項目中進行實踐的步驟。”
最佳答案。我想補充一點,您應該在gitlab或github或sourceforge或其他地方至少有一個或兩個展示項目可用,如果他們想更詳細地了解您的工作方式,可以向人們指出。
我傾向於說我在哪裡使用或學習過什麼,而不是我沒有在哪裡使用。如果面試官選擇沒有提及的當前職位並詢問原因,只需說明該公司不使用該職位,並強調您有興趣與擁有該職位的公司合作。這不是在說你的老闆不好,而是事實。發表關於不使用某東西有多糟糕的意見,這是對雇主的不好評價,因此請以非判斷性的方式堅持事實。
這就是答案,但我認為也要說沒有明智的面試官僅僅因為他們被迫遵循不良作法而拒絕候選人,這一點也很重要。如果您可以說出良好實踐的原因,那麼您將不會因此而失敗。
好答案。要對此進行擴展,請不要將其保留為“我們不做任何事情”,而應利用它作為命名和簡要描述貴公司未遵循的最佳實踐的機會。
@computercarguy V不錯的方法/態度。這對您來說很容易嗎?對於糟糕的先前雇主/情況,我要保持客觀性頗有挑戰:我會為第一次“通過”做得很好。但是,如果另一方(採訪者或其他方式)對此問題施加壓力,就會產生困難。然後,開始對這個話題進行阻撓幾乎是不禮貌的。需要較高的外交水平。
@javadba,不,這並非自然而然。我跌倒了一下,然後對跌倒變得自覺。它需要練習來對單詞進行預過濾,並且並不總是有效,但是通過練習,它變得更加容易。面試官按這個話題確實很困難。有時這是一次沒有經驗的面試,有時是一種測試,以了解您是否會口口相傳,這通常也對面試官不利。嘗試“保持高水平”,但是如果您滑倒也不要太難過,只需盡量減少對其餘面試的影響。
...並且您有一些良好的示例代碼,在法律上您可以共享。
“我現在的雇主有點過時,不使用X或Y。現在我發現X,Y和Z著迷,因為我上了這門課,所以我真的很想這樣做。您的公司做到了,這就是為什麼我想為您工作。”
老實說,面試官無權知道現任雇主的工作方式。他們問,OP提供的信息甚至可能上升到工業間諜活動的程度,具體取決於提供的詳細程度。無論競爭對手絕對不應該要求還是給予專有信息。因此,這是關注*您*做事的另一個原因(在這種情況下,這是您擁有完整的代理人後如何編寫代碼),而不是*當前公司*做事的方式。
因此,您的建議是推遲面試,直到他們完成足夠的個人項目以獲取面試經驗為止?
FrenchFigaro
2019-07-22 12:54:26 UTC
view on stackexchange narkive permalink

我最近一直處於這種情況。在我之前的工作中,我們使用了非常舊的代碼庫(某些與Java 1.2 / 1.3兼容的代碼);代碼中充滿了魔術數字和魔術字符串,這些魔術數字和魔術字符串用於訪問 Vector Object 引用,然後對其進行轉換;沒有單元測試,幾乎沒有任何集成測試,沒有一個是自動化的;幾乎沒有時間分配給重構舊代碼;沒有代碼審查;自然界中深奧的評論...

當我覺得是時候該進行更綠色的牧場了時,有人問我這個問題,我繼續說我想如何工作以及這種缺乏我對個人工作道德的滿意度是我在別處尋找的部分原因。

我解釋了代碼質量對我來說有什麼特點(徹底的自動化測試的穩健性,變量和函數命名的易讀性,代碼的劃分)放入盡可能小的函數,而不是重複行代碼的1000個行的長塊等),然後我找到了當​​前的演出。

正如@Sascha在他們的答案中指出的那樣,您不必責怪您當前的演出/前雇主。這是因為對最佳實踐的看法相互矛盾,導致您無法在工作中找到滿意的結果。

這個。我總是將我當前的工作環境描述為我們不做這些事情的環境,以及我想做什麼,因為我可以看到正在出現的問題,例如錯誤或其他更改在電子郵件中丟失或變得不可讀以及無法維護的代碼,或者因錯字誤使Production崩潰,以及我如何花了兩年的大部分時間來嘗試引入更好的實踐。我從未以這些言論責怪任何人,這些言論都是事實(有些是我的錯!)。
Java 1.2 / 1.3?20年前的代碼聽起來...大約正確。我必須半定期維護大約這個年齡或更老的代碼。有時,我想像一個用大理石雕刻並固定在底座上的舊程序之一,上面貼著謹慎的黃銅標籤,上面寫著:“在Memoriae ANSI C之前的版本中,1972-1989:唯恐我們忘記了” :-)(或發表一首詩:“在地下室中,罌粟長成一團/在磁盤驅動器中,一排又一排……”-我曾經在一家分時度假公司工作,該公司的房間很大,除了洗衣機大小的大型機磁盤外一無所有,不斷呼......)
-1
@FrenchFigaro:管理不想被打擾。當您告訴他們事情時,他們會感到沮喪。因此,管理層不希望被告知。
davnicwil
2019-07-23 00:44:22 UTC
view on stackexchange narkive permalink

您正在以錯誤的方式製定和處理此問題。

您已經掌握了不良做法的實際經驗及其對他們的危害,這是好事 。您已經看過,從中學到了東西,並且比跳過“ 放慢腳步”和“ 阻止您完成工作”的所有這些實踐更好地了解

而且,在您自己的時間裡,您已經接觸並閱讀了有關這些實踐的所有信息,並在輔助項目中實施了它們,並且可以進行交談,直到人們無聊地傾聽他們對他們的所有益處為止。 >將帶入任何項目,並且帶入您當前特定的工作場所的項目-對嗎?

現在被暴露在中不良做法(不是您的選擇,而是重要的-不是跟隨他們的-因為不是您的選擇),您會了解到經驗,並且您了解更好的做法及其作為您已經得到的東西的價值從該經驗中學到。

這不僅不會給面試官帶來任何危險信號,而且比起那些只擁有良好實踐經驗但只是理所當然並且可能沒有什麼特別有趣的東西的人,它的遭遇可能更好說說他們(什麼?那是的,那是每個人都正確的事情嗎?)。

無法同意這一點。儘管處在令人沮喪的環境中,但我總是對一個了解正確做法的人印象深刻。這表明他/她有積極性,好奇心和熱情。這些人只是在令人鼓舞的環境中蓬勃發展。
我會同意,作為一名面試官,如果應聘者告訴我他對當前工作中的軟件工藝方式不滿意,我會感到很滿意。您只需要確保人們看到了您對它的熱情,就不會把它當作挑剔的或愚昧的。
是的,對這樣的問題的回答絕對是:“我如何以積極的方式來構架”?
user
2019-07-23 14:19:18 UTC
view on stackexchange narkive permalink

我一直處在這種情況下,並提出了許多更好的做法,卻沒有被允許實施這些做法,這就是我要繼續前進的部分原因。

對問題及其解決方案的意識,以及對更高標準工作的渴望。

+1,我實際上認為這是最好的總結。這樣,您就可以表明自己已意識到該問題,並已嘗試解決此問題,但現在您無法將其視為有效工作的障礙。
我同意這是最好的方法。
Sascha
2019-07-22 11:25:47 UTC
view on stackexchange narkive permalink

將其設為“為什麼我要跟我面試的公司比現在的工作場所更好而且更好”。

每當我在其他地方面試時,我都會通常會詢問我的工作方式以及如何進行測試或驗證/確認。聲明明顯地生產合理質量的軟件是對時間和培訓的投資,由於公司背景和項目類型的原因,有時有時這並不合理,但是您希望在與專業軟件相關的事物已執行的環境和項目中工作。如果是這樣,請告訴您這就是您面試的公司的聲譽。

我覺得,如果我是面試官,而候選人卻提出沒有任何事情發生,那將是一個很大的危險信號,而我只會丟棄他們的申請。我該如何在面試中討論這個問題?

  • 不要責怪您以前的雇主或同事那裡出了什麼問題
  • 提出期望
  • 直接詢問時,請直截了當地說,項目經理認為不執行此類措施是合理的,並且您執行了項目經理要求的工作。如果您這樣做了,也可以說是您通知了PM。
Issel
2019-07-23 02:30:03 UTC
view on stackexchange narkive permalink

不要顯示您當前的工作環境。

當面試官問這些問題時,他們在詢問您的思維過程,您了解概念並已經實踐過,這與您在所採訪的地方工作無關。 。我會說“通常,我喜歡做X,Y和Z”,更不用說您當前的工作環境不做這些事情。

如果面試官真的推動您的工作做事,我會說:“好吧,我喜歡這樣,但是我當前的工作環境沒​​有採用最佳實踐,這就是其中之一。我正在尋找新作品的主要原因。”

“我更喜歡<良好實踐>”是一種表達您喜歡良好實踐的完全合理的方式。除非您引起注意(例如強調“偏好”),否則訪調員可能只會繼續討論下一個問題。
Dmitry Grigoryev
2019-07-23 11:48:09 UTC
view on stackexchange narkive permalink

通常會問我如何工作以及如何進行測試或驗證/確認

描述你當前的工作習慣確實會引起危險。事實是,您確實缺乏大多數公司正在尋找的技能。了解TDD / Git / Whatever並在業餘時間使用它來構建玩具項目是一回事。

實際上,您應該嘗試使用TDD / Git /您在過去X年中從事的任何工作。

實際上,您應該嘗試在一家擁有希望擁有健全工作實踐的公司下找到一份新工作。 在船上,在那裡積累了兩年的經驗,然後在您想在其工作的公司申請

您可以嘗試在以下方面發展一些技能您可以在業餘時間通過自己的OSS項目來完成自己的工作,但是請記住,這些工作必須非常好。許多開發人員會在工作中使用良好的編碼習慣 ,並且如今在Github上有一些東西,而您在申請時必須與這些人競爭。

WGroleau
2019-07-22 19:38:50 UTC
view on stackexchange narkive permalink

嘗試在之前表達這樣的問題,即您想從危險的環境轉向擁有更有效實踐的公司。

您可以表達出對更有效地使用這些實踐的興趣,而不必擔心當前組織實際存在的不良情況。
Lawnmower Man
2019-07-25 08:06:11 UTC
view on stackexchange narkive permalink

如果您想實踐您認為是至高無上的原則,以便從中獲得經驗,那麼我強烈建議您找到一個使您感興趣並做出貢獻的開源項目。您不僅可以練習更好的工程實踐並親眼目睹其優越性,還可以在面試環節中指出一些要點。

當然,私人項目也可以很好地工作,但是缺乏與其他提供反饋和不同觀點的工程師組成團隊的好處。

Smiling Shadow
2019-07-25 21:36:00 UTC
view on stackexchange narkive permalink

一個花了20年時間設計和實現VLS工業軟件系統的人的誠實答案,該系統具有數十萬到幾百萬行代碼以及1000平方英尺的UML圖和幾萬頁的文檔,包括測試用例是否遵循嚴格的FDA製藥行業準則來創建9×9 UHA(超高可用性)軟件系統(預計可靠運行時間為99.9999999%)?

除非您正在申請軟件項目管理位置-無關緊要。只要向我展示您是一位優秀的軟件工程師,他就能編寫出良好的工作代碼,並且足夠聰明,可以快速學習我們的“最佳實踐”,那麼您就很好了。

設計和編寫軟件的真正才能真正獨特的-官僚機構和公司結構(包括溝通和文檔標準)在一家公司之間是不同的,而且並不難學。尤其是您不會被雇用去實現或領導該結構,而只是為了遵循它。

Post Scriptum

現代代碼中的註釋是浪費時間。您應該編寫自我註釋代碼,例如

public CapsuleOrder GetOrderByPoNumber(String PoNumber){}

其他所有內容都應在ACTUAL文檔系統中。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...