ソフトウェア職への応募でやってはいけないこと
原文は Ben Hoyt により に公開されました。 このブログを購読する
私はたくさんの履歴書や筆記面接の回答に目を通していますが、その多くは文章がうまく書けていません。この記事では、ソフトウェアエンジニアの職に応募する際にやってはいけないことをいくつか紹介します。
私はCanonicalで働いています(採用プロセスについては末尾の補足をご覧ください)。ただ、ここで紹介するアドバイスは、どの会社に応募する際にも役立つはずです。
その大半は、履歴書やカバーレター、その他応募書類の文章を書く際に役立つライティングのアドバイスです。実際、その多くはあらゆるノンフィクションのライティングに通じるものだとさえ思っています。
まずは前提として、誰に向けて書いているのかを意識してください。相手は多忙な採用担当者や、あなたの応募書類(そして他にも何百通もの書類)に目を通すよう頼まれたエンジニアです。彼らは限られた情報から合否を判断しなければならず、印象に残る人、何かを作り上げてきた人、そしてうまくコミュニケーションが取れる人を採用したいと考えています。
ChatGPTを使うな
ただのツールなのはわかっています。でも、まずは話を聞いてください。当初は「ChatGPTを使うな」に「使うなら慎重に」という但し書きを付けていました。でも今は強くこう勧めます。とにかく使うな、と。少なくとも2023年9月時点では、ChatGPTを使ってもロボットのような文章になるだけです。
候補者が応募書類に(明らかに)AIを使い始めた当初、私はそれを「カンニング」とみなして不合格にしていました。それから考え方を変えて、今ではすべての提出物を人間が書いたものとして評価し、内容が悪ければ落とすようにしています。
ただ、はっきりとAIツールを使っているとわかる提出物は、どれもひどい出来です。文法は完璧かもしれませんが、退屈きわまりなく、候補者自身の経験がほとんど、あるいはまったく書かれていないのです。
私の会社が出している質問の一つに、かなり自由度の高いものがあります。「ソフトウェアの運用や本番環境でのサービス実行に関するあなたの経験を教えてください」という質問です。以下は、それに対する典型的なChatGPTの回答例です。
私はソフトウェアの運用と本番環境でのサービス管理において5年の経験があります。前職では、本番サービスのデプロイと保守において中心的な役割を担い、PythonやGolangをはじめとする多様な技術・ツールを活用してきました。デプロイやリリース管理のプロセスを統括し、システムの健全性を確保するための堅牢なモニタリングソリューションを導入、インシデント管理においては迅速な解決と根本原因の分析を重視して効果的に対応してきました。また、需要増加に対応するためのスケーラビリティへの取り組みや、システムパフォーマンスを向上させるための最適化にも携わってきました。
なぜこれがこれほどひどいのでしょうか。気取った、受動的で具体性のない文章だからです。面白みもなければ個人的な要素もなく、どんなソフトウェアエンジニアにも当てはまりそうな内容です。
それと比べて、こちらの個人的で引き込まれる回答を見てください。
私は叔父の自動車修理工場向けに、自動車部品を管理するウェブサイト(PHPとMySQL製)を作ったことでプログラミングを学びました。ウェブサイトに毎分pingを送り、エラーが起きたらメールが届くというシンプルなヘルスチェックの仕組みも追加しました。初めての仕事に就いてすぐ、AnsibleとPythonスクリプトを使ってオンコール対応の手順を数多く自動化しました。最近では、Terraformで管理されたEKSクラスタ上で動く3つのマイクロサービスを担当するチームに所属し、社内でDatadogによるロギングとモニタリングを構築し、DevOpsチームと共同のオンコールローテーションにも参加していました。
具体的で、引き込まれ、現実味があります!さらに良くするなら、例えばその自動化がチームにどう役立ったかを書くといいでしょう。「これによってデプロイ時間が2時間から15分に短縮されました」といった具合です。とはいえ、すでに最初のバージョンよりずっと良くなっています。
英語が母語でなくても問題ありません。完璧だけど中身のない文章より、たとえ多少不自然でも、あなたの経験が伝わる文章のほうがずっといいと思っています。
もっと良いプロンプトを使えばChatGPTの文章はもっと自然になるのか? はい、より良いプロンプトで言い回しは改善できます。しかし、あなたの個人的な経験に基づいた文章を魔法のように書いてくれるわけではありません。もちろん、書いた文章にスペルや文法のチェックツールをかけるのは構いません。ただ、それがあなた自身の文章であることは忘れないでください。
気取った文章を書くな
先ほどのような「PythonやGolangをはじめとする多様な技術・ツールを活用し」といった言い回しはやめましょう。伝えたいことが大げさな言葉の海に埋もれてしまいます。単に「PythonとGoを使いました」と書けばいいのです。そのほうが読む人は感謝するはずです。
別の例として、ある候補者は次のようなことを書いていました。彼らは
- Javaを深く極めている(彼らはジェームズ・ゴスリンではない)
- 彼らの旅は始まった(彼らはビルボ・バギンズではない)
- 巧みにプログラムを構築した(彼らはストラディバリではない)
- 専門知識を拡張した(専門家であるだけでなく、拡張された専門家ということらしい)
- Lambda関数を丹念に作り上げた(私は職人技の光るLambdaのほうが好みだが)
- Spring Bootを活用した(単に使っただけでは?)
- 迅速に適応した(もう飽きてきた)
- ドキュメントを綿密に読んだ(いいですね、校正者として採用しよう)
- オブジェクト指向プログラミングを受け入れた(90年代のみんなと同じように)
- そして堅牢な経験をもたらした(しかし、堅牢なForthの経験はあるのだろうか?)
ChatGPTを疑いましたが、確信はありません。単に類語辞典を使っただけかもしれません。いずれにせよ、副詞や形容詞のボリュームを最大まで上げないでください。
大げさな修飾語を取り除き、次のように書き直すことをおすすめします。
- Javaの経験があります
- 始めました
- 作りました
- 学びました
- Lambda関数を書きました
- Spring Bootを使いました
- 適応しました
- ドキュメントを読みました
- オブジェクト指向プログラミングを使っています(あるいは、この項目自体不要です)
- 経験を積みました
語るな、示せ!
これはシンプルです。読者にどう思うべきかを語るのではなく、あなたが何をやってきたかを示してください。上の悪い例は、ただ気取った文章なだけでなく、示すのではなく語っているのです。
「私は巧みにプログラムを構築しました」と言うのは、読者にあなたをどう評価すべきかを語っているだけです。一方で「500行のJavaでPOSIX Makeの高速なサブセットを作りました」と書くのは、あなたが何を作ったかを示しています。それがオープンソースで、GitHubリポジトリへのリンクを貼れるなら、なお良いでしょう。
相手は、あなたが具体的に何を成し遂げたかを見たいと思っている採用担当者だということを忘れないでください。
ありきたりなことを書くな
私たちの面接の質問の別の例は、「本番サービスの新機能をどのように設計・実装しますか?」というものです。
多くの候補者(これもAIツールの助けを借りているのかもしれません)が、実際にはこの質問に答えず、「教科書ではソフトウェア開発ライフサイクルをどう定義しているか」という問いに答えてしまいます。しかし私たちが聞きたいのは、技術的な詳細をあなた自身の言葉で語った、あなた自身の経験です。
次の段落は、あまりにもありきたりです。
新しいソフトウェアの設計と実装は、要件の収集、仕様書の作成、関係者からのフィードバックの取得、そして質の高い実装から始まります。実装後は、自動テストと手動のQAが重要です。その後、ソフトウェアをデプロイし、適切にモニタリングします。
代わりに、例えば次のように書いてみてください。
私は簡潔な仕様書と、事前のちょっとした計画が好きです。例えば新しい認証サービスを設計した際には、アーキテクチャ図とAPIエンドポイントの簡単な説明を含む3ページの仕様書を書きました。本番にデプロイする前には実際のサーバーで負荷テストを行うことが重要だと考え、ステージング環境を同様に構築して、同時リクエストをどれだけ捌けるかを計測しました。本番環境に入ってからはモニタリングが不可欠です。私はDatadogや、Prometheusのようなオープンソースツールを使って問題の検出や診断を行ってきました。
要するに、ありきたりなことを書かないでください。もちろん、パラメトリック多相について書いている場合は別ですが。(すみません、言わずにはいられませんでした。)
バズワード・ビンゴをするな
これは気取った文章やありきたりな内容と密接に関わっています。あまり意味のないビジネス用語は使わないようにしてください。今日も次のような文章を見かけました。
包括的なデータ解釈と分析を実施し、クライアントに価値をもたらす実行可能な洞察を導き出しました。
The Officeのパロディのように聞こえるだけでなく、この文章は基本的に何も言っていません。パソコンの前で働くほぼすべての人が「データを解釈・分析」し、できればクライアントに価値をもたらす「実行可能な洞察を導き出して」いるはずです。
バズワードを使うと賢く聞こえるかもしれませんが、実際には大したことを言っていないという事実を隠しているだけだと思います。
データサイエンティストとして働いているなら、代わりに次のように言ってみてください。
Sunnyville病院のデータサイエンティストとして、医療機器から得られる膨大なデータ(1日あたり数ギガバイト)をPythonとPandasを使って分析し、医師が手術室の手順を改善するのに役立つ異常を見つけています。
これはあなたの役割を説明するだけでなく、どの分野で働き、どのツールを使い、「クライアント」が誰で、彼らをどう助けているのかも示しています。
指示を無視するな
これは言うまでもないことだと思うかもしれませんが、指示に従うのが苦手な候補者もいるようです。
例えば、応募フォームに「偏りを減らすため、筆記面接は匿名で行ってください」と書かれているのに、冒頭にフルネームを書いてしまうのは、あまり良い兆候ではありません。誰でも間違いはするので、それだけで落とすことはありませんが、指示を無視することが有利に働くことはありません。
履歴書についてのヒント
上記のアドバイスはすべて、履歴書/職務経歴書に書くことにも当てはまります。ただ、履歴書に特化した追加のヒントをいくつか紹介します。
GitHubプロフィールを確認する
GitHubプロフィールへのリンクを貼るなら、そこにまともなプロジェクトがあることを確認してください。もしfork-of-popular-project-i-never-touchedやrandom-university-assignment、half-baked-data-science-scriptのようなプロジェクトばかりなら、プロフィールへのリンクは貼らないほうがいいでしょう。
ただ、誇れる、厳選されたプロジェクトが2つほどあるなら、ぜひプロフィールへのリンクを載せてください。
自分が作ったものを示す
GitHubプロフィールに関するアドバイスを一般化すると、自分が作ったものを示すということです。これはスタートアップが重視する最も強いシグナルの一つであり、大企業でも同様に有効です。
自分で作ったプロジェクトなら、そのウェブサイトやGitHubのプロジェクトページへのリンクを貼りましょう。有名なオープンソースプロジェクトへの大きな貢献があるなら、それを1、2文で説明し、プルリクエストへのリンクを貼ってください。
クローズドソースの会社で作ったものでも、プロダクトのどの部分を担当したかを明確かつ詳細に説明することで示すことができます。例えば次のように。
Shopifyでは、HTMLメールのテンプレートを再設計し、クリック率を15%から27%へとほぼ倍増させました。
英語(または求められる言語)で書く
応募フォームが英語なら、履歴書やカバーレターも英語で書くようにしてください。私たちの会社では英語でコミュニケーションを取っているため、誰もが読めるように応募書類もその言語で提出してもらう必要があります。
スキル:すべてを載せない
世の中のほぼすべてのプログラミング言語やフレームワークを並べたような「スキル」欄は載せないでください。
Skills: JavaScript, TypeScript, Node.js, React, Java, Kotlin, Python, Django, Flask, R, Rust, PHP, Perl, C/C++, Golang, C#, .NET, Bash, Powershell.
私には、それは何でもできるが何も極めていないという印象を与えます。むしろ次のような書き方のほうがずっといいと思います。
Pythonの深い経験があり、C#にも触れたことがあります。シェルスクリプトが得意で、必要に応じて新しい言語もすぐに習得できます。
私は30年近くプログラミングをしてきて、10数種類以上の言語を使ってきましたが、履歴書では主要なものに絞るようにしています。
Go、Python、C、SQL、そして英語が堪能です。また、JavaScript、HTML、C++、x86アセンブリもかなり書いてきました。
目立たせる
履歴書のPDFはプロフェッショナルに見えるようにしましょう。といっても、堅苦しい弁護士のような意味ではありません。ちょっとした良いデザインを加えてみてください。背景をピンクと緑にするという意味ではなく、レイアウトやフォントに少し気を配るということです。
友人の言葉を引用します。
Word文書のように見せないこと。文字の壁、黒枠のテーブル、ひどいフォント、余白なし、そんなものを見ると、すぐに「コミュニケーション能力が低そう」という印象を受けます。「resume template」でググれば、少ない労力でかなりまともなテンプレートが見つかります。
他にも紹介できる履歴書のヒントはたくさんあると思います。提案があれば、ぜひメールで教えてください。
補足
私はCanonicalで働いており、毎月何万通もの応募の中から最良の人材を選ばなければなりません。私たちの面接プロセスについてはオンラインでいろいろと言われており、そのすべてが好意的なものではありません。採用プロセスがもっと短ければいいのにと思いますが、筆記面接の部分(最も批判を集めている部分です)は、実際かなり有用だと感じています。
興味深いことに、この記事を書いている間に、Canonicalは応募フォームに次の文言を追加しました。
本応募プロセスにおいて、私は自分自身の言葉のみを使用することに同意します。盗用やAI、その他の生成コンテンツの使用は応募資格の剥奪につながることを理解しています。
ChatGPTを避けることはどんな応募でも改善につながると信じていますが、Canonicalでは現在、それを必須としています。応募者数の多い他の会社も追随するのではないかと思います。
Canonicalのドキュメント部門の責任者は、筆記面接がどのように面接プロセスにおける偏りを減らすかについて記事を書いています。
私たちは完全リモートの会社なので、文章によるコミュニケーションが重要です。言葉だけで自分の経験を語り、技術的なアイデアを伝えられるかを評価することは不可欠なのです。
そして、はい、私たちはいつでも採用しています。
記事をランダムに読む
コメント
ログインしてコメントする