Goエンジニアのフリーランス面談でよく聞かれる質問と答え方
公開 2026-11-04 監修:株式会社エージェントベスト
フリーランスのGoエンジニアの面談でよく聞かれるのは、Goで何をどこまで担ったか、Goの考え方に沿ってエラーや並行処理を扱えるか、本番で問題が起きたときにどう動いたかの3つです。面談官は、言語の知識の量より「この人が書いたコードをチームで保守できるか、障害の場で任せられるか」を確かめようとしています。
答えるときは、模範解答を覚えるより、自分の経験から「設計や不具合の場面」を3〜4つ選び、どの質問にもそこから答えられるように準備しておくのが近道です。面談全般の答え方の型は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではGoの面談に固有の質問に絞ります。
Goの面談で面談官が見ていること
Go案件の面談に出てくるのは、発注元の技術リードやバックエンドの責任者であることが多く、本人もGoを書いています。そのため、用語を知っているかより、話の中に出てくる判断の理由と、起きたことへの向き合い方を聞いています。
面談官が知りたいのは、おおむね次の3点です。
- Goの経験の中身:Goで書いたのはどの部分か。ほかの言語の経験とどう分かれるか
- チームで保守できる書き方か:エラー処理、パッケージの分け方、テストが、チームの決まりに合わせられるか
- 本番での動き方:障害や性能の問題に、どう気づき、どう切り分け、どう直したか
以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。
よく聞かれる質問と答え方の考え方
ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。
1. 「Goでの実務は何年で、どの部分を書いてきましたか」
確かめたいのは、Goの経験の中身です。バックエンド全体の年数とGoの年数を分け、Goで書いたのがAPIか、サービス間の通信か、バッチやツールかを短く伝えます。スキルシートの年数とずれないようにしておくことが大切です。
架空の例:「バックエンドの経験は7年で、そのうちGoは3年です。決済まわりのAPIをGoで新しく作り、本番の運用まで担いました。それ以前はJavaで業務システムを作っていました」
2. 「エラーはどう扱っていますか」
Goの面談でよく出る質問です。エラーを値として返す書き方を知っているかより、どこで包み、どこでログに残し、どこで利用者向けの応答に変えるかというチームの方針を持っているかを見ています。前の現場の決まりと、その決まりにした理由を話せると伝わりやすくなります。
3. 「goroutineやチャネルを使って、困ったことはありますか」
並行処理の経験を、成功談ではなく問題が起きた場面で確かめる質問です。goroutineが終わらずに残った、データの競合が起きた、同時に動かす数を絞らずに外部のサービスに負荷をかけた、などの場面を、気づいたきっかけ、原因、直し方、再発を防いだ工夫の順に話します。並行処理を使わない判断をした経験も、立派な答えになります。
4. 「contextはどう使っていますか」
タイムアウトや取り消しを、呼び出しの連鎖の中でどう伝えているかを確かめる質問です。外部のAPIやデータベースを呼ぶときにどこで期限を決めたか、期限が切れたときに何を返したかを、具体的な処理の流れで説明します。
5. 「パッケージの分け方やinterfaceの置き方で、気をつけていることは何ですか」
チームで保守しやすい構造を作れるかを見ています。「最初から細かく分けすぎない」「interfaceは使う側に置く」のような自分の考え方と、それで困った経験や、レビューで方針を合わせた経験を話します。特定の設計の型の名前を並べるより、その現場の大きさに合わせてどう判断したかが大切です。
6. 「本番の障害で、どう原因を切り分けましたか」
本番での動き方を確かめる質問です。アラートやログ、メトリクスのどれから気づいたか、暫定の対処と恒久の対処をどう分けたか、誰にいつ報告したか、振り返りで何を変えたかを順に話します。修正を急ぐより、影響の範囲と原因の切り分けを先にしたことが伝わると、任せやすい印象になります。
7. 「性能の改善は、どう測って進めましたか」
速くなった結果より、測り方を見ています。プロファイルやベンチマークで遅い箇所を特定した流れ、改善の前後で何の数値を比べたかを話します。数値を出せない事情があるときは、「応答時間の上位の遅い部分を半分ほどに減らした」のように、守秘に触れない範囲の表し方を用意しておきます。
8. 「ほかの言語からGoに移って、書き方で変えたことはありますか」
ほかの言語の経験が長い人によく聞かれます。前の言語の書き方を持ち込まずに、Goの考え方に合わせられるかを確かめる質問です。例外に頼らないエラー処理、継承を使わない構造、シンプルさを優先する書き方などで、自分が意識して変えた点を話します。
9. 「テストはどこまで書いていましたか」
テストの方針と、変更しやすい状態を保つ工夫を見ています。表の形でまとめて多くの入力を確かめる書き方、外部への依存をどう差し替えたか、テストに時間をかけすぎない線引きをどうしたかを話します。
準備は「設計や不具合の場面」を3〜4つに絞る
- 場面を選ぶ:設計の判断、並行処理の不具合、本番の障害、性能の改善など、性質の違う場面を3〜4つ選ぶ
- 場面ごとにメモをつくる:状況、気づいたきっかけ、選択肢、選んだ理由、結果、次に生かしたことを書き出す
- 規模をそろえる:チームの人数、サービスの数、扱う処理の量の表し方を、どの場面でも同じにする
- コードで説明できるようにする:画面共有でコードを見せたり、簡単な図を描いたりして説明を求められることがある
- スキルシートと照らし合わせる:シートに書いた担当範囲と、話の内容が一致しているかを確かめる
面談の中で、その場でコードを書いたり、事前の課題を出されたりすることもあります。進め方や注意点は技術テストの記事で解説しています。スキルシートの書き方はGoエンジニアのスキルシートの記事、冒頭の自己紹介は面談の自己紹介の記事をご覧ください。
面談の相手によって重心が変わる
| 面談の相手 | 重く見られやすい点 |
|---|---|
| 技術リード・バックエンドの責任者 | エラー処理や並行処理の考え方、レビューでの振る舞い |
| SREやインフラの責任者 | 障害の切り分け、監視とログの扱い、コンテナやクラウドの理解 |
| プロダクトの責任者 | 仕様のすり合わせ方、見積もりの出し方、報告の仕方 |
複数の人と面談する場合は、相手に合わせて同じ経験の中のどの部分を厚く話すかを変えると、限られた時間を有効に使えます。
Goの案件ならではの逆質問
逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。Goの案件では、次の点を聞いておくと判断がしやすくなります。
- 新しく作る機能と、既存システムの置き換えや保守の比重
- Goの版と、依存するモジュールの更新の進め方
- コードの決まりやレビューの流れ(誰が承認するか、何人のレビューが要るか)
- 障害対応の待機の有無と、呼び出されたときの扱い
- 自分が担う範囲がAPIまでか、デプロイや監視まで含むか
一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。聞いた内容は契約前の確認にもそのまま使えます。案件を選ぶときの確認点はGo案件の選び方で整理しています。
よくある質問
Goの実務が1年ほどです。面談でどう話せばよいですか?
Goの年数を正直に伝えたうえで、その1年で担った範囲と、ほかの言語で積んだ設計や運用の経験を分けて話します。Goで書いた部分について、エラー処理や並行処理で意識したことを具体的に話せれば、年数の短さを補いやすくなります。
並行処理をほとんど使ってこなかった場合、不利になりますか?
並行処理を使わない判断も一つの経験です。なぜ使わなかったか、使うならどこで同時に動かす数を絞るかを説明できれば、考え方は伝わります。並行処理の経験を重く見る案件かどうかは、案件票や面談の前の情報で確かめておきましょう。
面談で見送られたとき、理由を知ることはできますか?
理由が伝えられる場合とそうでない場合があります。見送られやすい理由の傾向は面談で見送られる理由の記事で整理しているので、次の面談の準備に生かしてください。オンラインでの面談の進め方はオンライン面談の記事をご覧ください。