題:
在一次採訪中，說您使用Stack Overflow查找代碼中的錯誤是否會自欺欺人？
Tms91
2019-11-12 15:03:56 UTC
view on stackexchange narkive permalink

讓我們假設在面試時他們問我“如果代碼不起作用，您會怎麼做？”。

我告訴他們，我閱讀了文檔以查找錯誤，然後隔離了無效的代碼段並嘗試對其進行更改以使其正常運行。但是最後如果我找不到我在Stack Overflow上問的答案。

這會自欺欺人嗎？

評論不作進一步討論；此對話已[移至聊天]（https://chat.stackexchange.com/rooms/101024/discussion-on-question-by-tms91-in-an-interview-is-it-self-defeating-to-說你）。
為什麼將有關標題編輯的評論作為擴展討論而刪除？它完全歪曲了問題。OP顯然不是要使用Stack來“發現”錯誤，而是要“理解”它們。“ *此代碼中的錯誤在哪裡？*”與“ *幫助我理解此代碼。*”本質上不同。
八 答案:
Julia Hayward
2019-11-12 15:27:00 UTC
view on stackexchange narkive permalink

他們正在尋找的是，除了簡單地盯著代碼之外，您還擁有一種合理的系統方法來定位和解決問題，並且可以使用各種熟悉的技術和資源。其中可能包括以下任何一項：

  • 編寫可表徵問題的測試
  • 添加日誌記錄/遙測功能，從而可以為您提供有關該問題的更多信息
  • 重構困難的代碼，可以更輕鬆地與同事進行
  • 配對/ mob編程
  • 向專家諮詢相關問題（包括Stack Overflow）

一個糟糕的答案可能只是四處亂竄，直到代碼神奇地起作用為止，或者將SO用作第一道防線。因此，SO只是工具箱中的一種工具，請證明您知道何時該使用該工具。

（順便說一句，如果他們出於看似隨意的原因不喜歡使用SO，請當心！ ）

我對此表示贊同，因為它暗示了面試官可能用來評估答案的基本標準。故障排除技術之間存在平衡。一方面，面試官不希望某人過分依賴外部幫助而無法自己思考。另一方面，他們也不想讓一個如此頑強和獨立的人浪費時間去努力自己解決所有問題，而其他人可能會迅速提供幫助。說您想在線尋求幫助並沒有錯，但是您需要將其放在上下文中。
在Stack或類似的設備上搜索解決方案很有意義，因為您通常可以找到同行評審的常見問題解決方案。但是，研究建議的解決方案以確保適當也很重要。您如何進行研究可能是答案的一部分。
當您遇到的問題是“此錯誤消息是什麼意思”時，搜索SO非常適合作為第一種選擇。有時在線答案會直接為您提供解決方案，有時它會為您提供足夠的信息以使您重新了解問題的發生。
我同意其中的絕大多數，但是我不確定我是否同意將SO作為首選會破壞交易。SO永遠不是我遇到困難時的第一步，但是它來得很早，而且我也不會指責其他確實從此開始的開發人員。我會遇到一個將其作為唯一資源的開發人員的問題。
-1
通常，隔離/格式化/解釋要提交給SO的問題會指出我的問題實際上是什麼，然後甚至可以在將其提交給SO之前，也可以解決該問題。
@Kat好的，我同意這一點。我將其表示為搜索SO。
作為前項目經理，我經常遇到的問題不是開發人員自己做的調試不夠，而是他們做的太多，可能浪費很多時間。如果您尋求幫助，通常可以更快地解決問題。話雖如此，自然而然地向SO尋求幫助絕不是第一件事，當然也不是唯一的事情。
@Arluin，如果只有每個人都在他們的SO問題上付出如此多的努力...
儘管這個答案很完整，但我認為最重要的方法還是錯過了，它是使用調試器進行的實際調試。我看到了太多的開發人員，尤其是在我的嵌入式設備領域，這些開發人員設置調試器並不容易，他們依賴日誌並詢問何時逐步執行代碼會帶來極大幫助。
Old_Lamplighter
2019-11-12 20:36:47 UTC
view on stackexchange narkive permalink

這取決於。如果您正在採訪像我這樣的人，那可能是對您不利的標誌，但是我一直追溯到互聯網是基於文本的時代，如果您想做任何事情，就必須通過telnet進入BBS。

如果我在採訪您，我可能會問一些後續問題，例如：

  • 您為什麼不問同事？
  • 您將如何問一個同事？不公開公司信息就提出疑問？
  • 為什麼您不能自己找到答案，而不是提出問題。
  • 好吧，您問一個關於SO的問題，然後有人給你答案。當代碼中斷時會發生什麼？

我會擔心您不會編寫自己的代碼，而是剪切並粘貼其他人的代碼片段，因此不知道如何維護該代碼。這些天，我越來越經常遇到這種情況。最糟糕的情況是，我們最終遇到了弗蘭肯斯坦（Frankenstein）笨拙的意大利麵條代碼怪物，沒人知道如何維護。

因此，更好的答案是：

我隔離一段無效的代碼，嘗試進行更改以使其正常工作，然後逐步執行代碼。如果到那時，它仍然不起作用，我將在線檢查是否可以找到討論該問題的文章。否則，我會請教同事，因為一雙新鮮的眼睛通常會幫助您

或類似的事情。

關鍵是您想展示自己的思想處理。這樣的回答將向我表明您具有解決問題的能力，並在外出尋找答案之前嘗試自己解決問題，然後作為最後的選擇與他人進行協商。

告訴我你們倆都是獨立的，但不要太驕傲。

評論不作進一步討論；此對話已[移至聊天]（https://chat.stackexchange.com/rooms/101025/discussion-on-answer-by-richard-says-reinstate-monica-in-an-interview-is-it-sel）。
切線，但我想說：在您詢問問題時，不太可能會粘貼您不理解的代碼。提出問題意味著將其分解成足夠多的陌生人可以理解，複製和回答的問題。通常，僅提出問題就會給您答案。問題更多在於現有問題/答案中的複制粘貼代碼
Sourav Ghosh
2019-11-12 15:15:29 UTC
view on stackexchange narkive permalink

在這種情況下沒有對與錯，這只是一個角度問題。

我看不到提到已知的在線社區是一個問題，但是，您可能希望保留它更具通用性（不要把自己描繪成沒有任何知識，並且完全依賴Stack Overflow或其他社區進行編碼，測試，調試或故障排除的人。）

不要直接說“我張貼/ on ask on site”，因為它涉及可能的數據/代碼洩漏的風險，因此您可以說

之類的話，“如果我遇到了我無法解決的障礙在我看來，在進行初步調試後似乎已經克服了。我尋找在線技術社區和論壇中可用的答案，例如Stack Overflow”。

gnasher729
2019-11-12 15:39:00 UTC
view on stackexchange narkive permalink

最好為stackoverflow編寫一個問題，以準確描述問題。那是因為準確地描述問題經常會直接帶您找到解決方案。顯然，您不會發布該問題。

當涉及到第三方代碼但您不理解並且記錄不佳，並且需要了解它的人的幫助時，這是個好主意。

要查找代碼中的錯誤？我會嚴重懷疑您作為軟件開發人員的素質。

以平易近人的方式提出問題的次數（例如好的SE問題或對我的代碼來龍去脈的同事提出的問題）提供了解決問題的方法（通常是通過強調疏忽））很高。這就是為什麼我在桌子上放一個[橡皮鴨]（http://wiki.c2.com/?RubberDucking）的原因。
固定。僅作者可以更改兩個字符的煩人功能。當只有兩個字符錯誤時。
davnicwil
2019-11-13 00:52:23 UTC
view on stackexchange narkive permalink

如果他們要面試的素質包括誠實和實用主義，那麼告訴他們這將對您有利。

您顯然必須衡量這是否是“ 您的實際工作流程是什麼工作”或“ 出於面試目的以某種人為的方式展示您的技能和知識”。

但是，如果這是前者，那是您真正要做的，那麼就告訴他們。

在採訪中，我發現對雙方最好都是誠實的。這意味著，如果您同意，那麼它很可能很合適。面試官也常常欣賞坦率和謙遜，因為在通常不會鼓勵他們的情況下，他們很少見到。

也從您的角度考慮一下-如果這是您的方式工作，但由於某種原因，他們認為這是不可接受的做法，您真的很高興嗎？

Hugo Rune
2019-11-14 16:18:47 UTC
view on stackexchange narkive permalink

根據我的經驗，在面試潛在候選人時，我總是提防那些不提Stackoverflow（或類似內容）的人。我傾向於僱用那些將SO放在問題解決方案列表末尾的人員，而不是那些將其放在第一位的人員。

正如其他人所述，SO是開發人員工具箱中的一種工具。它不應該是工具箱。但肯定應該存在。

作為高級開發人員，我每天至少要批評其他開發人員對SO的使用是虛偽的。對於我來說，一個相當尷尬的時刻是當我花了很長時間尋找解決方案的答案而只是找到答案時，這是我幾個月前在這裡寫的。

Karl Bielefeldt
2019-11-14 01:51:01 UTC
view on stackexchange narkive permalink

我希望看到您提出的一些問題，因為它們是公開記錄。在您的特定情況下，您的問題看起來結構合理且重點突出，而不是容易被谷歌搜索或同事必然知道的那種問題。我認為這樣的問題對您的工作申請是積極的（儘管我可能會有一些有關使用excel作為數據源的後續問題）。

但是，並非所有人都會付出努力，他們可能會不公平地將您在網站上看到的一些懶惰問題吸引您。另外，我想在您可以編寫StackOverflow問題之前，進一步了解您的故障排除過程。您如何縮小問題的範圍？您如何收集適當的上下文等。不要留下StackOverflow是您的第一個也是唯一手段的印象。

那！查看問題將對知識的一般水平以及研究/交流能力提供重要的見解。如果由於“我在得到答案後將其刪除”而無法顯示任何內容，這也說明了很多...
Basic
2019-11-15 21:06:31 UTC
view on stackexchange narkive permalink

在一次採訪中，我正在尋找可以利用任何可用資源來更有效地實現其目標的人。

如果您對我說“當我遇到例外時，有時我會將其發佈到堆棧溢出中以查看問題是什麼”，在沒有其他上下文的情況下，我將其視為否定因素。相反，如果您要說“我經常使用SO進行交叉引用或研究潛在的替代方案”，那是肯定的-它表明您我已經了解了這個問題，並正在評估解決方案的多種選擇。

我不想要的一件事就是願意不斷改造輪子的人。如果已經解決了這個問題（並且許可證合適），請使用它！您只是節省了幾天/幾週的時間，並幫助確保了項目按時且在預算之內。

此外。.如果您提到SO ...您為自己的問題/答案歷史感到驕傲嗎？如果是這樣，請考慮在簡歷中包括指向您的個人資料的鏈接。

作為雇主，了解某人如何解決問題（並接受反饋/批評）對於全面了解候選人有很大幫助

我們有一名員工在面試中被炸毀。確實沒有顯示我們正在尋找的任何技能，但是他的SO簡介很周到，詳細，並且顯示了廣泛的知識。因此，我們又給了他一張鏡頭（和一些書面作品），他給了他一張照片（我們對他感到非常高興）。

我不能說我們會把他一個人帶走，但這足以讓我們停下來看看兩次。



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