TypeScriptエンジニアのフリーランス面談でよく聞かれる質問と答え方

TypeScriptエンジニアのフリーランス面談でよく聞かれるのは、どの層（画面・サーバー・両方）で使ってきたか、anyや型の無視をどう扱ってきたか、型で防げない部分をどう守ったか、既存のコードをどう改善したかの4つです。面談官は型の文法の知識より、「この人がチームのコードに入ったとき、型を使って品質を上げてくれるか、逆に複雑にしないか」を確かめようとしています。

答えるときは、模範回答を覚えるより、自分の経験から「型で判断した場面」を3〜4つ選び、どの質問にもそこから答えられるように準備しておくのが近道です。面談全般の答え方は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではTypeScriptの面談に固有の質問に絞ります。

TypeScriptの面談で面談官が見ていること

TypeScriptの案件の面談に出てくるのは、テックリードや開発の責任者であることが多く、本人もTypeScriptを日常的に書いています。そのため、用語の正しさより、型を使う判断の理由と、その判断がチームにどう効いたかを聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. 合う層か：案件で触る画面・サーバー・基盤の経験があるか
2. 型の使い方の加減：型を厳しくしすぎてチームを止めないか、ゆるくしすぎて意味をなくさないか
3. チームとの相性：レビューで型の判断を言葉で説明できるか、既存のやり方を尊重して改善を進められるか

以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。

1. 「TypeScriptをどこで、どのくらいの規模で使ってきましたか」

確かめたいのは、案件に合う層かどうかです。「TypeScript歴◯年」ではなく、プロジェクトごとに画面かサーバーか、使ったフレームワークや実行環境、チームの人数、自分が触った範囲を短く伝えます。

架空の例：「直近は自社サービスの画面側で、ReactとTypeScriptを使っていました。開発者は6名ほどで、私は注文まわりの画面と、APIの応答の型の管理を担当していました。Node.jsのBFFも一部触っています」

2. 「anyはどんなときに使いますか。減らしたことはありますか」

最もよく聞かれる質問の一つです。「anyは使いません」と答えるより、使うことがある場面と、その代わりに使うもの、残すときの決まりを話すほうが信頼されます。たとえば、型の分からない外部のデータはunknownで受けて検証してから使う、移行の途中でやむを得ず残すときは理由をコメントに書いて後で数を追う、といった話です。減らした経験があれば、どう数を測り、開発を止めずにどの順番で減らしたかを添えます。

3. 「型では防げない不具合を、どう防ぎましたか」

型は実行時には消えるため、APIの応答やフォームの入力、外部サービスのデータは型の約束を守ってくれません。面談官は、型と実行時の検証の境目を理解しているかを見ています。どこで入力を検証し、検証の結果を型につなげたか、テストで何を補ったかを話します。具体的な不具合を1つ挙げ、原因と、同じことが起きないようにした仕組みまで話せると伝わります。

4. 「型エラーの多いコードや、JavaScriptのコードをどう改善しましたか」

既存のコードベースに入る案件では、ほぼ聞かれます。答えは次の順番で組み立てると伝わりやすくなります。

• どんな状態だったか（型エラーの数、型の無視の多さ、テストの有無）
• 何を基準に、どこから手をつけたか
• ほかの開発者の作業を止めないために何をしたか
• 結果として何が楽になったか、何が残ったか

「全部strictにしました」で終わると、判断の中身が見えません。一度にやらなかった理由まで話せると、現場での加減が伝わります。

5. 「tsconfigやビルドの設定に関わったことはありますか」

設定を自分で変えたことがあるかを確かめる質問です。最初からあった設定を使っていただけなら、そのとおりに話して構いません。変えた経験があれば、何を変え、なぜ変え、変えたときに出たエラーをどう片付けたかを話します。

2026年10月時点では、TypeScript 7.0（2026年7月8日公開、Microsoftの公式ブログによる）でstrictが初期設定で有効になり、一部の古い設定がエラーになったため、版上げへの考えを聞かれることもあります。触っていない場合は、無理に詳しいふりをせず、自分の現場なら何を確かめてから上げるかを話せば十分です。

6. 「型の設計で工夫したことを教えてください」

ジェネリクスや判別のできる共用体型など、書き方の名前を並べるより、どんな問題を、その型で防いだかを話します。たとえば、状態ごとに持つデータが違う画面で、ありえない組み合わせを型で表せないようにした、という話です。凝った型を書いた話をするときは、ほかの人が読めるようにどう工夫したかも添えると、チームとの相性が伝わります。

7. 「レビューで、型の付け方について意見が分かれたらどうしますか」

型の厳しさや書き方は好みが分かれやすく、チームでの振る舞いを見る質問です。自分の考えを押し通すより、チームの決まりがあればそれに合わせ、なければ根拠を示して決まりを作る提案をする、という順番を話すと安心されます。

8. 「生成AIのコード補完は使っていますか」

使っているかどうかより、出てきたコードの型をどう確かめているか、案件の決まりに従えるかを見ています。使う場合は、型チェックとテストで確かめてから出していること、使ってよいかは現場の決まりに合わせることを話します。

技術課題やコードを見せる場面の準備

面談の中で、画面を共有してコードの説明を求められたり、短い技術課題を出されたりすることがあります。TypeScriptの課題では、動くことに加えて、型の付け方や名前の付け方、エラーの扱いが見られます。課題全般の考え方は技術面談・コーディングテストへの備え方で解説しています。

公開リポジトリを見せる場合は、前の案件のコードや、取引先の情報が入ったものを使わないよう注意してください。

準備は「型で判断した場面」を3〜4つに絞る

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：anyを減らした、実行時の検証を入れた、移行を進めた、レビューで意見が分かれた、など性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状態、判断の基準、選ばなかった方法、ほかの人への影響、結果を書き出す
3. 層と規模をそろえる：画面かサーバーか、チームの人数、期間を、どの場面でも同じ言い方で話せるようにする
4. 1分版と3分版をつくる：まず短く話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いた型の取り組みと、話の内容が一致しているかを確かめる

スキルシートの書き方はTypeScriptのスキルシートの記事、冒頭の自己紹介の組み立て方は面談の自己紹介の記事で解説しています。

案件の層によって重心が変わる

画面の案件ではフレームワークの質問も多く出ます。Reactの面談の記事やNode.jsの面談の記事もあわせて準備に使ってください。

TypeScriptならではの逆質問

逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。TypeScriptの案件では、次の点を聞いておくと判断がしやすくなります。

• 画面・サーバー・基盤の仕事の割合と、主に触るリポジトリ
• strictなど型チェックの設定と、anyや型の無視の扱いの決まり
• TypeScriptの版と、版上げの予定があるか
• APIの型を画面とサーバーでどう共有しているか
• CIで型チェックとテストが回っているか

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。聞いた内容は契約前の確認にも使えます。案件選びの確認点はTypeScript案件の選び方で整理しています。

よくある質問

型の高度な書き方を聞かれて答えられなかったら、見送られますか？

それだけで決まることは多くありません。知らないことは知らないと伝え、自分ならどう調べて、チームが読める形にするかを話せば、受け止め方は変わります。知ったかぶりで答えて掘り下げられるほうが、評価を下げやすくなります。

JavaScriptの経験が長く、TypeScriptの実務が短い場合はどう話せばよいですか？

JavaScriptで起きた不具合のうち、型があれば防げたものと防げなかったものを分けて話すと、型への理解が伝わります。TypeScriptの実務は期間を正確に伝え、移行や型の追加に関わった場面があれば中心に据えましょう。

面談で見送られることが続くときは、何を見直せばよいですか？

層の伝え方と、答えの具体性を見直すのが先です。応募した案件の層と、話した経験の層がずれていないかを確かめてください。見送られやすい理由は面談で見送られる理由の記事で解説しています。