記事だけで判断しない！なんちゃってエンジニアはGitHubと面接で見抜く

はじめに

🧠「技術ブログ、めっちゃ書いてるし強そう！」
🦧「これだけの記事をかけているのなら技術力も高そう！」

そんな決めつけや思い込みで簡単に採用をしてはいけません…

この記事は「記事がそれっぽくても、GitHubと面接でちゃんと見ましょうね！」という注意喚起です！
攻撃したいわけではなく、ミスマッチを減らしてお互いハッピーになろうぜという話です✋

記事だけでは判断しない理由

• ✍️ 記事は“それっぽく”仕上げられる（AIもあるしね）
• 🔍 実務の力は「コード」「設計」「検証のやり方」「再現性の高さ」に表れる
• 🎯 だから「GitHub」と「面接の深掘り」が超大事！

実際の体験談（知人のケース）

• 技術ブログも書いていて一見よさそう。ただ、実務では「変数って何？」レベルの質問が出て、基礎未習得だと判明…🫠
• 業務委託だったのでダメージは限定的。もし正社員採用だったらオンボーディングや品質面でかなり苦労していたはず🤨
• だからこそ…採用が難しい今の時代は「審美眼」が重要。記事の見栄えよりも、GitHubと面接の深掘りで確かめましょう👓

GitHubでどんなコード書いている？（ここ見る！）

※ 個人開発が中心なら他者レビューがなくてもOK
※ PRテンプレやセルフレビュー、Issue/READMEで「意図・判断・影響」を書けているかをチェック

• 📦 リポジトリの再現性：README/構成/環境設定が揃ってる？
• 🔀 変更の伝え方（PR）：目的・背景・影響範囲・スクショ/GIF・テスト結果を添える（ソロはセルフレビューで補足OK）
• 🧪 テストの観点：失敗系・境界値・外部依存のモック。CIで自動実行できると尚良し
• 📝 コミットの粒度：1トピック1コミット。メッセージに「何を」「なぜ」を含める（例: feat/fix/chore）
• 🧵 Issueの運用：調査→仮説→検証→結論→次アクション/TODOを残す（箇条書きで十分）
• 📈 可観測性：ログレベルの使い分け、メトリクス、簡易ベンチ/プロファイル結果の添付
• 🔎 透明性（ソロ/チーム）：
  • ソロ: PRテンプレ/Issue/READMEに意図・選択理由・影響を明記
  • チーム: レビューで論点/代替案/合意をスレッドに残す

まずは全体をサッと眺めて、気になるPR/Issueにディープダイブ。二段構えが効きます。

面接で技術の深掘りは必須（ここ外さない）

• 🧑‍💻 直近のPRを一緒に読む：狙い/代替案/影響範囲/撤退条件を説明してもらう
• 🧠 設計のトレードオフ：採用しなかった案と理由、非機能要件の扱い
• 🐞 障害対応の再現：再現→仮説→計測→切り分け→修正→再検証の流れ
• 🔧 ミニ課題：既存コードの小修正やテスト追加で“手つき”を見る
• 🤖 AIの使い方：出典確認・ライセンス・再現性・レビュー方針の説明

面談で使える一言テンプレ（短め）

• 「採用しなかった技術の理由は？」
• 「性能改善の計測と検証の設計は？」
• 「障害対応のプロセスは？」
• 「AI利用時の品質担保と権利・機密配慮は？」

すぐ使えるチェックリスト

1. コード/PR/Issue/メトリクスへのリンクがある
2. 失敗と学びが書いてある（成功談だけじゃない）
3. トレードオフと却下案が語られている
4. 計測・検証の方法が明確（ベンチ/モニタリング/実験設計）
5. 再現手順と環境情報がある（依存/設定/バージョン）
6. テストやCI/CDへの言及がある
7. チーム文脈と影響範囲の説明がある

最低限の評価フロー例

1. 事前チェック：記事・プロフィールは“入口”として軽く確認
2. GitHubスクリーニング：PR/Issue/コミット/テストをざっと見る
3. 面接ディープダイブ：直近PRを素材に深掘り（設計/検証/トレードオフ）
4. ミニ課題：既存コードの小修正＋テスト追加で手つきを確認
5. フィードバック：学習志向で合否理由を明確化（次の成長に繋げる）

まとめ

発信はナイス。でも“それっぽさ”だけじゃなく、GitHubのコードと面接の深掘りでフェアに評価していきましょう。AI時代こそ「透明性」と「再現可能な成果」を大事に。ミスマッチを減らして、チームも本人もハッピーに🚀