HireRooのコーディングテスト対策：例題の練習と受験前の確認

HireRooのコーディングテスト対策は、デモで操作を確認し、今回指定された形式で「仕様を読む・実装する・検証する・提出する」流れを一度通すところから始められます。例題の答えを覚えるだけでは、言語の選択、テストの追加、提出状態の確認で迷う可能性があります。

この記事では公式ヘルプの操作案内と、独自に作ったログ集計の練習問題を分けて説明します。PythonとSQLで同じ結果を出し、重複、時間の境界、ゼロ件の利用者をどう扱うかを確認しましょう。関連する英語練習として ログの重複除去と順序付け も使えます。PracHubの問題はHireRooの公式デモや実際の試験問題ではありません。

HireRooで何が出るかは、会社の設定で変わる

公式情報：2026年10月6日に確認したHireRooのヘルプでは、コーディング、クイズ、AI協働、システムデザイン、実践の五形式を案内しています。企業は対象者や職種に応じて組み合わせられます。SQLはコーディング形式の範囲に含まれ、全受験者が五形式すべてを解くわけではありません。五つの問題形式

本記事の範囲はプラットフォームの使い方と独自練習です。特定企業・同一採用期の候補者報告を根拠にした記事ではなく、共通の問題数、制限時間、合格点は示しません。「HireRooを受けた」という別の人の体験だけでは、あなたに届いたテストの内容を決められません。

右列は準備上の提案であり、採用企業の配点表ではありません。まず自分の案内に含まれる形式を特定し、必要な行だけを練習に使ってください。

デモは操作確認、本番は選考の回答

公式のデモ案内では、受験開始画面の「今すぐテストまたはデモを受ける」から、ダイアログで「デモを確認」を選ぶと別タブでデモを開けます。デモには本番で使われる形式が選ばれ、繰り返し試せます。ただし同じ形式であることは、本番と同じ問題・難易度・採点結果であることを意味しません。デモ環境の公式説明

操作練習では、問題文を読む場所、言語の選択、実行結果の表示、問題間の移動を一度確かめます。使いたい言語が見当たらない場合、企業側が選択肢を制限している可能性があります。普段のIDEと同じ環境だと思い込まず、案内された選択肢で試してください。コーディング形式の操作

デモを開くつもりで本番を開始しないよう、開始ダイアログの選択を読み分けます。本番を始めると制限時間内に終了する必要があるため、試験概要と企業からのメッセージを先に確認し、中断せず取り組める時間を確保してください。操作への不安は、デモで一度提出まで試して減らせます。テスト全体の進め方

ここからの例題は自分の環境で解けます。会社の非公開問題を持ち出して共有する必要はありません。公式デモで操作を覚え、独自問題で仕様とテストを練習する、と目的を分けると復習しやすくなります。

独自例題：時間帯ごとの成功イベントを数える

利用者一覧 users とイベントログ events を受け取り、指定時間帯の成功イベント数を利用者ごとに返してください。利用者は重複のない大文字英字ID、イベントは (event_id, user_id, time, status) の四項目です。時刻は同じ基準の整数、statusは ok または fail とします。

独自に定めた契約は次のとおりです。開始時刻を含み、終了時刻を含まない [start, end) を集計します。同じevent_idで内容も同じログは一回だけ数えます。同じIDなのに内容が異なる場合と、未登録の利用者が含まれる場合はエラーにします。全利用者を結果に含め、件数の降順、同数ならIDの昇順で返します。入力項目の形式・型とstatusの値域は正しいものとし、空の利用者一覧も許可します。start < end が必要です。

「重複は無視」とだけ読んで実装すると、同じ利用者の別イベントまで消してしまうかもしれません。何を同一視するのかをIDで固定し、件数のゼロと利用者の不在も区別しましょう。

利用者一覧が A, B, C なら結果は [(A, 1), (B, 1), (C, 0)] です。Cのログがなくても、一覧にいるので出力します。AとBは同数なのでID順です。

Pythonで契約を実装する

def count_successes(users, events, start, end):
    if start >= end or len(set(users)) != len(users):
        raise ValueError("invalid contract")
    counts = dict.fromkeys(users, 0)
    seen = {}
    for event_id, user, time, status in events:
        if user not in counts:
            raise ValueError("unknown user")
        payload = (user, time, status)
        if event_id in seen:
            if seen[event_id] != payload:
                raise ValueError("conflicting event")
            continue
        seen[event_id] = payload
        if start <= time < end and status == "ok":
            counts[user] += 1
    return sorted(counts.items(), key=lambda row: (-row[1], row[0]))

利用者一覧から先にカウンターを作ることで、ログのない利用者も残せます。seen は利用者IDではなくイベントIDをキーにし、内容の衝突を検出するためpayloadも保存します。単に集合へIDを入れるだけでは、二回目の内容が変わっていることを見逃します。

この実装は、時間帯の外側にあるログについてもIDの整合性を確認します。契約が「入力全体で同一IDは同一内容」を要求しているためです。先に時間で絞ってしまうと、一方が範囲外にある矛盾を見逃せます。この順序を説明できると、「範囲外だから無視してよいのか」という仕様確認まで示せます。

イベント数をN、利用者数をUとすると、平均的な辞書操作を定数時間とみなした時間は O(N + U log U)、追加領域は O(N + U) です。計算量を説明するときは、最後の並べ替えも含めます。また、この版は全イベントIDを記憶するので、無限に続くストリーム向けではありません。

SQLでも同じ対象を数えられるか

同じ問題を、users(user_id) と events(event_id, user_id, occurred_at, status) の二表で考えます。ここでは利用者IDは一意、全列はNULLでなく、未登録利用者や同一IDの内容衝突が事前検証で除かれたデータを前提にします。SQL例はその不正入力検査まで代行しません。

WITH unique_events AS (
    SELECT DISTINCT event_id, user_id, occurred_at, status
    FROM events
)
SELECT u.user_id, COUNT(e.event_id) AS success_count
FROM users AS u
LEFT JOIN unique_events AS e
  ON e.user_id = u.user_id
 AND e.occurred_at >= 10
 AND e.occurred_at < 20
 AND e.status = 'ok'
GROUP BY u.user_id
ORDER BY success_count DESC, u.user_id ASC;

LEFT JOINで利用者を残し この問題を練習する、条件に合うイベントだけを結合します。条件を結合後のWHEREへ移すと、イベントのない利用者を落とす書き方になり得ます。また、この例では対応イベントのないCにも外部結合の一行が残るため、COUNT(*) だとCを一件と数えてしまいます。ここではNULLでないイベントIDを数えます。PostgreSQLの結合説明、集約関数の説明

これは今回の契約に合わせたSQLです。実際の問題が別の方言や日時型を指定する場合、文字列のまま時刻を比較せず、型とタイムゾーンを確認します。IDも日本語や大小文字混在であれば、Pythonとデータベースの照合順序が一致するとは限りません。本例は大文字英字に限定して、その論点を分離しています。

何を変えると答えが変わるか

まず、E4を二回追加してもBの件数は増えないはずです。次に、新しいIDでBの成功イベントを一件追加するとBが先頭になります。さらに終了時刻を20から21に変えると、時刻20のE2が対象に入ります。これらは、入力変更と期待する変化を結び付けるテストです。

同じE1の時刻だけを11に変えて追加した場合はエラーです。どちらかを勝手に最新値として採用する仕様ではありません。入力をシャッフルしても、有効なデータなら結果は変わらないことも確認してください。ログが時刻順で届くと書かれていない以上、順序への依存を入れるべきではありません。

ローカル検証では、固定シードで生成した200組の有効データについて、重複と並べ替えを加えたPython・SQLiteの結果を独立した集計と照合しました。空入力、時間境界の変更、五つの不正契約ケースも確認済みです。PostgreSQL上の実行やHireRooの採点を検証したわけではありません。サンプル一件が通ったことだけで、すべての仕様を実装できたとは判断しません。

例題から本番の検証へつなげる

公式の操作案内では、テストケースを実行でき、受験者自身でケースを追加できると説明されています。用意されたケースがすべての例外を網羅するとは限らないため、今回の例題なら「時刻20」「同じIDを二回」「ログなしC」を追加すると確認範囲が広がります。コーディング形式の公式ヘルプ

実行が失敗したら、まず入力の読み込み、計算、出力形式を分けて見ます。空白区切りなのかJSONなのか、返り値が必要なのか標準出力なのかは問題ごとに違います。関数自体が正しくても、指定された関数名や戻り値の形が違えば契約を満たしません。

改善するときは一度に一つの原因を変え、失敗した入力を再実行します。例えばCが消えたなら、集計の初期化や結合条件を見直すのが先です。並び順だけがおかしいのに、重複処理まで同時に書き換えると新しい不具合を見つけにくくなります。

説明欄が利用できる問題では、何を前提にし、どの境界を確認したかを短く残します。「たぶん正しい」より、「終了時刻は含めず、重複IDは一回、全利用者を返す」と書くほうが、コードとの対応を確認しやすくなります。未実装の条件を実装済みとして書かないことも重要です。

AI協働や実践形式を、普通のCodingと混同しない

公式情報：HireRooは、AIと一緒に課題へ取り組む専用のAI協働形式を提供しています。通常の回答画面にあるWeb検索やChatGPTも企業の許可設定に依存します。別形式にAI機能があることから、今回の試験でも自由に外部ツールを使えるとは判断できません。AI協働形式、検索・ChatGPTの利用条件

練習上の提案として、AI利用が許可された場合でも、最初に契約と受け入れ条件を整理し、生成された変更を自分で確認します この問題を練習する。ログ例題なら「ゼロ件のCを残す」「終了時刻は除く」を明示し、出力が条件を満たすか実行して確かめます。長いコードが出てきたこと自体は完成の証拠になりません。

公式の実践形式説明は、指定されたGitHubリポジトリを使い、実装をPRとして提出する流れを案内しています。その場合はコードだけでなく、変更理由、テスト方法、残っている制約をレビューできる形にまとめる練習が役立ちます。すべてのHireRooテストでPRを作るわけではありません。実践形式の説明

システムデザイン形式なら、同じログ集計を「どこで保存し、どこで重複を除き この問題を練習する、失敗時にどう再処理するか」という設計問題へ広げられます。ただし今回のインメモリ辞書だけで、無制限のデータや複数サーバーに対応したとは言えません。形式が変わると、提出すべき証拠も変わります。

終了前に、実行と提出を分けて確認する

公式ヘルプでは、コード提出後にも改善・再提出ができる一方、テスト全体を終了すると回答を変更できないと説明されています。実行ボタンで結果が出たことと、回答を提出したことは分けて確認してください。時間切れ時の扱いも含め、今回の画面と案内を先に読んでおきます。コード提出、テスト終了の操作

公式案内によれば、合否はHireRooからではなく選考企業側から連絡されます。終了画面や練習テストの結果から、通過を推測しすぎないようにしましょう。全体の進め方

以下の五つは英語の関連練習です。HireRooでの出題を保証するものではなく、今回のログ例題で見つかった弱点に合わせて選んでください。

次の一回は、同じ例題をただ速く書くより、契約を一つだけ変えて試してみてください。例えば時間帯を変える、ゼロ件利用者を除外する、同数時の順序を逆にする。どのコードとテストが変わるか説明できれば、仕様変更に合わせて実装を直す練習になります。練習結果は合格点や実際の出題を予測するものではありません。

Sources and Further Reading

• HireRoo：五つの問題形式
• HireRoo：デモ環境で試す
• HireRoo：テストの進め方
• HireRoo：コーディング形式の進め方
• HireRoo：解答中の操作とテスト終了
• HireRoo：Google検索・ChatGPTの利用条件
• HireRoo：AI協働形式
• HireRoo：実践形式
• PostgreSQL：結合とテーブル式
• PostgreSQL：集約関数