GitHub 提交紀錄害求職者落選?Reddit:最假的是公司竟然詳細回信

找找異變
閱讀功能說明

收聽會朗讀正文;速讀會依序顯示短語,速度可調。語言練習可對照現有的不同語言版本。收藏儲存在本瀏覽器中,可從播放器的收藏清單再次開啟。用打磚塊來讀會把正文的文字變成磚塊,邊打邊讀。

分享這篇文章
廣告
廣告

2026年10月28日查看的Reddit貼文「itDoBeLikeThatSometimes」,是一張初階軟體工程師因程式版本管理習慣而收到拒絕信的圖片。留言區卻認為,最不可思議的不是工程師的做法,而是公司竟然願意把不錄取的理由寫得清清楚楚。

原本的笑點是什麼?

貼文出現在r/ProgrammerHumor。圖片中的信件以修改紀錄管理不當為由,表示不錄用應徵者。GitHub會用提交紀錄保存程式變更,並搭配簡短說明,方便其他人理解修改內容。若說明含糊,日後追查問題就會比較辛苦。

目前沒有證據能證明這封信真的由某家公司寄出,留言也有人指出它是假的。因此本文將它視為虛構的求職迷因。圖片細小文字未逐字核對,不會假裝讀過完整信件並引用內容。

網友為何反過來檢查人資?

有留言開玩笑說,這位應徵者對初階職缺來說根本「資格太好」,應該去當中高階工程師。原本是扣分項目的混亂紀錄,突然成了資深工程師的勳章。

另一位網友說,能看出這封信是假的,也算面試的一部分。還有人認為,現實中求職者常常連回信都等不到,哪有這麼完整的落選理由?於是被審查的對象從求職者換成招聘方。

也有人把個人程式專案比作在家穿的衣服:拿辦公室服裝規範來評分,未必公平。這不代表版本紀錄毫無價值;GitHub官方文件確實說明,提交紀錄能保存並追蹤變更。只是私人練習與團隊專案的情境不同。

以下是原創短劇:人資最後一關

人資:「你的提交說明寫『應該修好了』。」應徵者:「沒確認的事,我不敢說死。」人資:「下一筆寫『這次真的好了』。」應徵者:「前一次只是初步結論。」人資:「我們會寄信詳細解釋不錄取的原因。」應徵者:「等等,貴公司真的會回信?你們是實體公司嗎?」這段對話為本文創作,並非真實留言。

為什麼這麼好笑?

一開始大家笑的是工程師的版本紀錄,最後笑的卻是過於貼心的招聘流程。程式碼也許亂七八糟,但這間虛構公司的拒絕信品質,已經領先現實一大截。

再深入一步: 怎麼拒絕別人才不會心力交瘁

廣告這個主題的書

  • 『Supercommunicators』 (英文版)

    Charles Duhigg / Random House Publishing Group / 2024

    關於本文所屬領域「對話」的書。

  • 『Crucial Conversations and Crucial Confrontations Value Pack by Kerry Patterson』 (英文版)

    Kerry Patterson, Joseph Grenny / McGraw-Hill

    關於本文所屬領域「對話」的書。

本文包含廣告(聯盟連結)。 關於廣告 As an Amazon Associate I earn from qualifying purchases.

如果這篇文章對你有幫助,可以支持本站。 支持本站

廣告
廣告
廣告

再來一篇?有沒有好玩的?

讀完順便看看:幾篇相近的,還有幾篇完全不同但很有意思的。

  1. 相近的話題為什麼「身為老公」「身為男友」「身為家人」總是吵起來
  2. 為什麼我這麼愛哭?淚腺發達不是玻璃心,工作一樣能做好
  3. 完全不同,但很有趣一次50萬日圓級的8天海外旅行,還是幾十次好吃體驗?YouTube時代的「卡比式旅行」
  4. 《惡之華》ED為何聽起來瘋狂?2001年的切碎人聲設計
  5. 為什麼小額決定不必開30分鐘會議?
  6. 人體也太不方便了為什麼沒有「體力+1」,肌力、耐力與心肺卻要分開練?

今天讀這篇

每一篇都回答讀完本文後常有的下一個問題。

瀏覽全部文章更多「表達方式」文章

尋找其他文章

所有文章

Mendoi-chan

本站經營者

Mendoi-chan

把工作與日常生活中的麻煩整理成清楚的結構與下一步行動。