Airbnb CodeSignal ICA 2027：4レベル・90分の形式と採点、その後の流れ

Airbnb から CodeSignal の招待が届いた場合、一般的なアルゴリズムのスクリーニングとは違う準備が必要になることがあります。動作するプログラムを、何段階もの追加要件に合わせて拡張していく形式です。公式には、CodeSignal の Industry Coding Assessment（ICA）は、4つのレベルが段階的に進む1つのプロジェクトで、上限は90分です。 Airbnb の候補者もこの形式だったと報告していますが、実際にどの試験を受けるかは招待状の内容で決まります。CodeSignal ICA rules

2027年に向けて準備する候補者にとって、2026年9月21日にこのガイドを確認した時点で入手できる根拠は、現行のプラットフォーム公式ドキュメントと2026年の候補者報告です。Airbnb の2027年の選考プロセスが全員に共通すると裏づけるものではありません。

まずは Airbnb Software Engineer questions on PracHub から始めましょう。以下の Airbnb タグ付き OA の問題5つは、状態を持つプログラムを発展させる力に焦点を当てています。その後に、後から加えた機能が以前の不変条件を壊す例を、実例として示します。

Airbnb の CodeSignal について、根拠が実際に裏づけること

候補者の報告： 2026年8月17日に投稿された Glassdoor のレビュー（7月の面接について）には、90分で4パートからなるタスク管理とスケジューリングの課題が挙げられています。8月5日の別のレビューには、クラウドストレージに関する4レベルの ICA が書かれています。いずれも特定の体験を匿名で語ったもので、Airbnb の試験仕様ではありません。Airbnb Software Engineer interview reports

Airbnb の面接に関する議論で、7月22日のコメント投稿者も、次のレベルに進む前にそのレベルのテストを通したと報告しています。このことから、段階的に実装する練習が有効だと言えます。ただし、レベルが解放される正確な挙動は、実際に受ける試験によって異なる可能性があります。Candidate discussion

練習の形式を選ぶ前に、試験の名称を確認してください。CodeSignal の General Coding Assessment（GCA） は別の製品で、70分で4問、最初からすべての問題に取り組めます。独立した問題のうちどれから解くかというアドバイスは、ICA のプロジェクトにそのまま当てはまるとは限りません。Official GCA structure

招待状に「CodeSignal」としか書かれていない場合は、試験の詳細を確認するか、リクルーターに形式を確かめてください。タイマー、使用できるツール、問題の構成を、プラットフォーム名だけから推測してはいけません。

4つのレベルで進め方はどう変わるか

段階的な試験では、要件が増えるたびに同じコードベースを拡張していきます。以前の動作は互換性の制約になります。新しい操作のために状態が増えてもかまいませんが、既存のコマンドは引き続き求められた結果を返さなければなりません。

CodeSignal が公開している Industry Coding のフレームワークは、基本的な実装とエッジケースから始まり、データ処理、高度な機能、さらなる拡張へと進みます。既存のコードに手を入れながら、以前の機能を保つ力が重視されています。これらは能力のカテゴリであり、すべてのレベル3にタイムスタンプが出る、すべてのレベル4にアカウントの統合が出る、という約束ではありません。Official Industry Coding framework

準備のアドバイス： 現在の仕様がはっきり表れるデータ構造を選びましょう。ファイルストアなら、名前とサイズを持つレコードにしておくほうが、互いにずれてしまいかねない複数の無関係なマップより、所有者を加える拡張がしやすくなります。抽象化は要件が明確になる場面で加えてください。将来の機能をすべて予想しようとするのは時間の無駄です。

拡張したら、コードを足す前に以前のテストを再実行します。対応している段階的ワークスペースでは、CodeSignal の「Level changes」ビューで、レベル間で追加・変更・削除されたファイルを確認できます。指示文やヘルパーファイルが変わっていないと決めつけず、この変更点を確認してください。Level-diff documentation

まず取り組みたい Airbnb の練習問題5つ

以下にリンクした PracHub の各問題は、Airbnb / Software Engineer / Online Assessment とラベルが付けられています。このカタログ上の分類があるので選ぶ価値がありますが、Airbnb がこれらの問題文の出題を保証するわけではなく、今後受ける試験をこれらの問題が再現しているわけでもありません。以下の練習の焦点とチェック項目は、編集部からの提案です。

分野ごとに、別々の正しさのチェックを使いましょう。ファイルストアでは、拒否されたサイズ変更が使用量と名前を保つ必要があります。勤務時間の記録では、昇格が完了済みの勤務を書き換えてはいけません。銀行システムでは、口座の統合後は残高だけでなく保留中の支払いも確認します。タスク管理では、各コマンドの前後の状態を明記します。レシピでは、編集がすべての該当する検索結果に反映されることを確かめます。こうしたチェックによって、企業の問題リストが、焦点の絞られた練習セッションになります。

具体的な容量の不変条件から入りたいなら、ファイルストアから始めてください。次に過去の状態を扱う勤務時間の記録、続いて相互に作用する遷移を扱う銀行システムに進みます。レシピ管理は、出力の決定性とインデックスの維持の練習になります。タスク管理は、自分のやり方が別の分野でも通用するかを確かめる題材になります。

勤務時間の記録では、進行中のセッションと完了したセッションを分けましょう。銀行では、口座の現在の残高と過去の残高、そして保留中の支払いを区別します。この区別をしておけば、後から要件が増えたときに、すでに捨てた情報を再構築せずに済みます。

各問題を開き、その問題自体の仕様に従ってください。問題の企業ラベルは参考になる情報ですが、別の銀行やストレージの問題で覚えたルールをそのまま持ち込むと、誤った答えになることがあります。

ファイルストアの実践例：容量の不変条件を守る

以下はオリジナルの練習例で、Airbnb のファイルストアの問題で問われる力をもとにしています。数値、操作の順序、簡略化したルールはあくまで例示であり、Airbnb が出題したと報告された問題文ではありません。

容量100ユニットのユーザーを定義します。ファイルはそのユーザーに属し、使用量は保存されているサイズの合計に等しくなります。圧縮するとファイルのサイズが半分になり、圧縮済みを示す接尾辞が名前に付きます。展開すると元のサイズと名前に戻りますが、それは容量内に収まり、名前の衝突が起きない場合に限ります。

拒否された後も、圧縮済みのファイルはサイズ30のまま、圧縮済みの名前を保っていなければなりません。使用量を増やし、ファイル名を変え、そのあとで初めて容量を確認する実装は、一部だけ変更された状態を残してしまいます。「失敗」を返しても、その状態は元に戻りません。

安全な実装パターンの1つは、先に変更後の状態を計算することです。

proposed_usage = current_usage - stored_size + restored_size
validate capacity and destination-name availability
if either check fails: return failure without mutation
otherwise: commit name, size, and usage together

次に、回帰チェックを加えます。拒否された展開の後でも、photo を検索すると50が返ることを確認します。そのうえで、有効な小さい操作を試してください。期待どおりのエラーを返しながら、カウンターやインデックスをひそかに壊している実装を、これで見つけられます。

2つ目の有用な練習は、決定的な検索です。同じサイズのファイルを2つ作り、挿入順と逆の順序になる名前を付けて、問題文のタイブレークのルールを適用します。圧縮でどちらかのサイズが変わった後にも、もう一度行ってください。並び順と、検索が現在のデータを読んでいるかの両方を確かめられます。

ここでの教訓は具体的です。ファイルサイズが容量、検索、圧縮に影響するようになると、1つの変更が複数の観測可能な結果を生みます。メソッドごとに正常系だけの独立したテストを書くのではなく、これらの結果をまとめてテストしましょう。

試験を、変化し続ける1つのプログラムとして練習する

編集部からのおすすめ： 練習セッションでは、要件を段階的に明かしていきます。まず基本操作を実装し、次に検索、クォータ、圧縮を加えます。プログラムとテストスイートは最後まで同じものを使い続けます。これは練習用に考えた手順であり、Airbnb の公式なレベル構成ではありません。

各段階のコードを書く前に、入力の仕様、戻り値、無効な操作の扱い、並び順のルールを確認します。成功するケースと拒否されるケースを1つずつ書き、その後の期待される状態も書いておきます。タイムスタンプ付きの問題では、時刻 t のイベントが、同じ t に実行予定の処理より前に起きるのか後に起きるのかを、はっきりさせておきましょう。

繰り返し出てくる判断には、小さなヘルパーを作ります。オブジェクトの特定、容量の確認、ソートキーの比較、期限が来たイベントの適用などです。同じルールを複数のハンドラーに散らさないようにしてください。要件が変わったときに確認すべき場所が1か所で済み、その効果を確かめる短い回帰テストもある、という状態にしておきたいところです。

模擬試験では公表されている制限時間を使いますが、各レベルに均等な時間を割り当てないでください。問題を読む、実装する、デバッグするのに実際にどれだけかかるかを記録します。最初の2段階で時間の大半を使ってしまうなら、別の難しい拡張を練習する前に、モデルを単純にしましょう。

振り返りでは、失敗を正確に言葉にすると役立ちます。たとえば「現在の時給を更新して、過去の時給を失った」「拒否された展開でファイル名が変わってしまった」などです。そうすれば次の練習の目標が決まります。「もっと速くコードを書かなければ」では目標になりません。

テストが失敗したら、不一致を自分の頭で説明できるまでコマンド列を絞り込みます。ファイルストアの練習なら、追加、圧縮、再度の追加、展開の4つがあれば容量のバグを再現できます。ランダムな100回の操作では、かえって見えにくくなります。絞り込んだ列は回帰テストとして残し、そのあと大きなテストスイートに戻してください。

最後に、記載された制約に照らして計算量を見直します。小さな課題ならすべてのファイルを走査してもかまいませんが、増え続けるコレクションを何度もソートする方法は、多数のコマンドに対しては別のインデックスが必要になるかもしれません。その判断は、与えられた上限と必要な並び順に基づいて行います。更新の仕組みを理解する前に高度なインデックスを足すと、正しく保つべき構造がもう1つ増えるだけです。

ICA のスコアをどう読むか

公式情報： CodeSignal は ICA の Coding Score の範囲を200〜600としており、スコアが高いほど完了した課題が多いとしています。また、与えられた時間内にすべてを完了することは必ずしも求められていない、とも述べています。ICA scoring and rules

この説明は、Airbnb の合格ラインや、各レベルの配点が均等であることを裏づけるものではありません。職種や採用時期を問わず当てはまる Airbnb の公開カットオフは見つかりませんでした。「500点なら次の選考に進める」といった主張は、リクルーターがそのルールを明示しない限り、根拠がないものとして扱ってください。

準備では、スコアだけでなく、完了した要件の数と回帰テストの失敗も記録しましょう。拡張によって動いていた機能が壊れたら、機能をさらに足す前に、変更した共有状態やヘルパーを調べます。これはエンジニアリング上の戦略であり、隠れた配点の重みについて述べているわけではありません。

CodeSignal は、認定されたアセスメントの結果がアカウントのどこに表示されるかを説明しています。また、採用企業がスコアを公開しないことを選べるカスタムアセスメントがあることも、ドキュメントに書かれています。そのためスコアが見えない場合は、結果を推測せず、アセスメントの種類を確認する必要があります。Finding your assessment result

開始前に：環境設定と使用できるツール

招待状に書かれた締め切り、試験名、対応言語、ルールを確認してください。本番の前に、プラットフォームの練習環境を使って、テストの実行やファイルの操作に慣れておきましょう。

公式情報： CodeSignal のアセスメントの中には、本人確認と、カメラ、マイク、画面へのアクセスを求めるものがあります。プロクタリングが必要かどうかは、試験の前にプラットフォーム上で示されます。求められた身分証明書と機器を用意し、その受験で表示されるルールに従ってください。CodeSignal proctoring

練習で使ったからといって、外部のエディタ、AI アシスタント、オンラインの資料が許可されていると思い込まないでください。環境のトラブルで先に進めない場合は、新しい受験を何度も始めるのではなく、具体的なエラーをプラットフォームかリクルーターに報告しましょう。

提出後はどうなるか

提出、確認、そして Airbnb の採用判断という3つの出来事を分けて考えましょう。公式情報： CodeSignal は、プロクタリング付きのアセスメントの確認プロセスに通常1〜3営業日かかると説明しています。これはプラットフォーム側の確認期間であり、Airbnb のリクルーターが3日以内に連絡するという約束ではありません。Proctored assessment timeline

提出の確認画面を保存し、表示されているステータスを確認しておきましょう。リクルーターが伝えた回答期間を過ぎたら、結果が届いているか、次のステップは何かを尋ねる簡潔なフォローアップを送ることができます。スコアだけでは、次の面接の形式はわかりません。

自分用の振り返りには、データモデル、難しかった境界条件、時間があればこう変えたいという点を記録しましょう。これは、守秘義務のある試験内容とは分けて書きます。後の面接で自分の考え方を聞かれたら、実際に下した判断を説明してください。

次の練習では、Airbnb Software Engineer question collection から1問選び、解説を読む前に実装して、拒否された操作が状態を保つことを証明するテストを追加しましょう。この練習は、タイマーのもとで動作するプログラムを拡張するという課題に直接つながります。

出典と参考資料

• CodeSignal: Industry Coding Assessment rules and scoring
• CodeSignal: Industry Coding Skills Evaluation Framework
• CodeSignal: General Coding Assessment structure
• Glassdoor: Airbnb Software Engineer candidate reports
• Reddit: Airbnb interview discussion with July 2026 candidate comments
• CodeSignal: Viewing changes between question levels
• CodeSignal: Finding your assessment result
• CodeSignal: Proctoring requirements
• CodeSignal: Proctored assessment verification timeline

2026年9月21日に調査・改訂。候補者の体験は、職種、勤務地、採用時期によって異なります。ご自身の招待状に従ってください。