Linuxエンジニアとして初めての転職面接で玉砕した話｜SE時代に学んだ「書類のスキル」と「現場のスキル」の違い

「Linuxが使えるって書いてあるけど、Apacheが起動しない時どうやって切り分けますか？」

2004年、私の初めての転職面接で面接官に投げかけられた言葉です。Linuxを3年間使ってきた自信があったのに、この一言で頭が真っ白になりました。

「えっと……ログを見ます」
「どのログを？」
「……/var/log/httpd/error_logを……」
「それで原因が分からなかったら？」

そこで詰まりました。「それで原因が分からなかったら」という問いに対して、次の一手が言葉として出てこなかったのです。コマンドは知っていても、「障害の時に何をどの順番で確認するか」が体に染み付いていませんでした。

この記事では、20年以上Linuxサーバーを運用してきた経験から、私が転職活動で学んだ「書類上のスキル」と「現場で通用するスキル」の本質的な違いと、Linux転職を目指す方に伝えたいことを正直に話します。

Linuxが「使える」と思って転職活動を始めた頃の話

2004年春、私はSEとして3年間Linuxサーバーを扱ってきた自分なりの自信を持って、転職活動を始めました。当時の職歴には「Linuxサーバー構築・運用」と書き、CentOS、Apache、Postfix、Sambaといったキーワードを並べ、自分のスキルを証明しようとしていました。

書類選考は意外と通りました。「Linuxができる人」という需要はあったようです。問題は面接に入ってからでした。

最初の面接では、最初の15分は順調でした。「なぜ転職したいのか」「これまでどんなサーバーを担当してきたか」という定番の質問には答えられました。ところが技術的な質問に移った途端、私は言葉に詰まることが増えていきました。

「Sambaを設定したことあるそうですが、Windowsから接続できなくなった時はどうやって調査しますか？」

Sambaは使っていました。でも「接続できなくなった時の切り分け手順」を、言葉で論理的に説明できませんでした。「ログを見ます」という曖昧な答えを繰り返すうちに、面接官の顔が少しずつ険しくなっていきました。

後から振り返れば、私の「Linuxが使える」は「上手くいっているときにコマンドが打てる」というスキルでした。「上手くいかなかったときに何が起きているかを特定できる」スキルとは別物だったのです。

この違いに気づくのに、私は転職活動で3社落ちる経験が必要でした。

面接官に「実際の障害経験」を聞かれて詰まった日

最初の転職活動で3社落ちた後、私は何が足りないかを真剣に考えました。そして、あることに気づきました。

面接官たちは全員、私の「何ができるか」ではなく「何をどう解決したか」を聞いていたのです。

1. コマンドの「知識」と「経験」の差が現場では絶対的だった

受けた会社の面接官の一人が、帰り際にこう言ってくれました。「コマンドは知ってる。でも使ったかどうかが伝わらない。」

この言葉は私には衝撃でした。コマンドの知識を整理してスラスラ答えられるように練習してきたのに、「使ったかどうか」が伝わらない？

よく考えると分かりました。私が面接で話していたのは「こういうコマンドを使えばいい」という知識の話だったのです。面接官が聞きたかったのは「実際にそのコマンドを使って問題を解決した経験があるか」という話でした。

たとえば「サーバーがハングアップした時の対処を教えてください」という質問に、「topコマンドでCPU/メモリを確認して、psコマンドで怪しいプロセスを特定して……」と答えた場合。これは手順の暗記です。一方で「以前、深夜に監視アラートが来て確認したら、バックアップスクリプトが暴走していた。topで確認したらCPU99%が1プロセスだったので、psで親プロセスを確認してkillしました。再発防止のために……」という話は経験の語りです。

聞いている側には、この違いは歴然として伝わります。

2. 「再現してみせてください」と言われた瞬間に固まった

2社目の面接で忘れられない体験があります。面接の途中で、「ちょっと面白い話をしましょうか」と面接官が言って、ホワイトボードに走り書きをしました。

「このApacheの設定でエラーが出ます。原因を特定する手順を、実際にやるように説明してください。」

設定ファイルの一部を書き、Apacheが起動できない状況を作ったのです。私は考えながら話しました。「まずエラーログを確認して……/var/log/httpd/error_logを確認して……」

「それで見つからなかったら？」「journalctlで……」「journalctlの正確なコマンドは？」

この「journalctlの正確なコマンドは？」という問いで詰まりました。知識として知っていたつもりでしたが、正確なオプションが咄嗟に出てこなかったのです。

この面接も結果は不採用でした。

3. 落ちた後に気づいた「実務経験の証明方法」

3社目の面接を終えた帰り道、私はようやく本質に気づきました。「現場のスキル」は、コマンドの知識ではなく、「問題が起きたときに何をするか」という反射的な行動パターンです。それは頭で覚えるのではなく、実際に手を動かして失敗して解決することで身につきます。

当時、私が最も不足していたのは「自分で意図的にエラーを作り出して、解決した経験」でした。業務でサーバーが正常に動いているときしか触っていなかったのです。

「自宅のVMwareに検証環境を作って、わざとApacheの設定を壊してみる。journalctlで確認し、httpd -tで設定の構文チェックを行い、修正して再起動する。」

この訓練を3か月続けた後、私は4社目の面接を受けました。

面接で技術質問に「動かない」と詰まらなくなった経験

検証環境で意図的に様々なエラーを再現し、解決する練習を繰り返した後、面接での回答が変わりました。「Apacheが起動しない時どうするか」という問いに対して、次のような答えが自然に出るようになっていたのです。

まずsystemctl statusでサービスの状態とエラーの概要を確認します。
この出力から「設定ファイルの構文エラー」という原因の方向性が分かります。次に設定ファイルの構文チェックをhttpd -tで実行します。
246行目の「ProxyPreserveHos」というタイポが原因だと特定できました。「ProxyPreserveHost」の入力ミスです。修正してsystemctl restart httpdを実行すれば復旧できます。

この流れを淀みなく話せるようになった理由はシンプルです。検証環境で同じエラーを何度も自分で作り出し、自分で解決したからです。

1. 「想定外のエラー」への対応力が面接で差になる

検証練習の中で気づいたのは、「想定内のエラーへの対処」と「想定外のエラーへの対処」の訓練は別だということです。

私が練習したのは「Apacheの設定ミス」「ポートの競合」「SELinuxによるブロック」など、よく起きるエラーのパターンでした。4社目の面接では、面接官が「ログには何も出ていないのにApacheが起動しない場合は？」と聞いてきました。

今の私にはすぐ分かりました。「SELinuxまたはfirewalldのブロック、あるいはポートの競合を疑います。ss -tlnpでポートの競合を確認し、ausearch -m avcでSELinuxのブロックを確認します。」

面接官はうなずいて「それで全部じゃないですが、正しい方向性です」と言いました。この面接は通過しました。

2. 「なぜそのコマンドを使うか」を言えることが大切だと分かった

4社目の面接官に後日教えてもらったことがあります。「コマンドの名前を言える人は多い。でも『なぜそのコマンドを選んだか』を説明できる人は少ない。」

「httpd -tではなくjournalctlから確認しないのはなぜか？」という問いに対して、「journalctlは詳細なログを見るためのもので、設定ファイルのシンタックスエラーはhttpd -tの方が一目で分かるから」と答えられる——これが「現場のスキル」の証明です。

コマンドを知っている、ではなく、コマンドを選ぶ理由を言える。このレベルの答えは、実際に手を動かした経験なしには出てきません。

転職成功後に気づいた、現役講師として見てきたこと

4社目の面接を通過し、転職後のエンジニアとしてのキャリアは大きく変わりました。新しい会社では、障害対応の経験を積む機会が多く、入社後1年で私の「現場のスキル」は急速に伸びていきました。

そしてセミナーで3,100名以上を指導してきた今、Linux転職を目指す方々から定期的に相談を受けます。その中で気づいたことがあります。書類通過率と面接通過率の間に大きなギャップがある方の多くが、「正しい知識を持っているが、実機での失敗経験が少ない」という特徴を持っています。

「コマンドのオプションは暗記しているのに面接で落ちる」という方のほとんどは、知識の整理は十分できています。足りないのは「そのコマンドが動かなかった時の経験」です。

私が受講生に伝えることは一つです。「自宅にVMwareやVirtualBoxで検証環境を作り、わざとエラーを起こして解決してください。Apacheの設定ファイルを意図的に壊す。パーミッションを間違える。ポートを競合させる。SELinuxをenforcingにしてアクセスエラーを起こす。その経験が、面接で語れる『現場のスキル』になります。」

これは私自身が転職活動で3社落ちた後に実践した方法であり、その後の転職成功と、20年以上の現場エンジニア生活を支えてきた学習法でもあります。

まとめ

Linux転職を目指す方に伝えたいことを一言にすれば、「コマンドを覚えるより、エラーに慣れる」です。面接官は技術的な知識のリストを確認したいのではなく、「この人は現場で問題が起きた時に自力で対処できるか」を見ています。

私が転職活動で3社落ちて学んだことは、技術力の問題ではありませんでした。「経験として語れる言葉を持っているか」の問題でした。そしてその言葉は、実機を触り、エラーに直面し、解決する経験からしか生まれません。

自宅の検証環境で意図的に壊して直すサイクルを繰り返してください。その経験が面接の言葉になり、入社後の実力になります。

面接でよく聞かれる場面	書類上のスキル（不合格の答え）	現場のスキル（合格の答え）
サービスが起動しない	「ログを見ます」	「systemctl statusで状態確認→journalctlで詳細→設定ファイルの構文チェック」という順序で話せる
SSHで接続できない	「設定を確認します」	「ファイアウォール→SELinux→sshd起動状態→鍵/パーミッション」の切り分け順序を話せる
ディスクが満杯になった	「不要ファイルを削除します」	「df -hで全体確認→du -sh /*でディレクトリ別確認→ログローテートや圧縮の検討」の流れを話せる
Webサイトが遅い	「サーバーを調べます」	「topでCPU/メモリ→ss -stでコネクション数→journalctlでタイムアウトエラー確認」の観点を話せる
なぜこのコマンドを使うか	「よく使うコマンドだから」	「他のアプローチと比べてこの場面ではこのコマンドが適切な理由」を説明できる

関連記事も合わせて参考にしてください。
・ssコマンドでポート・ソケット情報を確認する方法｜LISTENポートの確認と障害切り分けへの活用
・systemctlコマンドの使い方｜サービスの起動・停止・状態確認と自動起動設定

---

• 前のページへ：LinuxのSSH多段接続（踏み台サーバー）をまともに理解せずに現場入りした日の話｜ProxyJumpを知って変わった本番接続の安全性
• この記事の属するカテゴリ：Linux学習ガイド・Linux転職へ戻る