【25卒】 私が メガベンSWE からオファーをもらうために学んだスキル (コーディングテスト編) 【IT就活】※上位層向け

---

※　注意点
今回この記事内で述べる内容は，あくまで個人の主観に基づくものであり，必ずしも万人に当てはまるとは限らないことにご留意ください．

また，各企業における選考過程に関する情報公開は禁止されているため，記事内において一部不鮮明な説明に止めざるを得ない箇所があることをご理解頂きながら読み進めていただますと幸いです．

---

0. はじめに

皆さん、こんにちは。おむらいすです。

今回の記事の内容は、筆者が 25 卒として就職活動を行い、その結果オファーをいただけた企業(群)のうち、他の企業と比較した際の「選考過程におけるプロセスの特殊性」や「IT業界内での会社の注目度」等を鑑みて、皆さんからの記事作成に関する要望が特に多いと思われる企業(群)の 1 つ、 メガベンチャーSWE(ソフトウェアエンジニア)職 の選考で求められるスキルに関するものとなります。

オファーをいただくまでに筆者が行なったこと、選考を通じて求められるスキルを身につける上にあたって役立つ書籍等に関して、個人の経験をもとに共有させていただけたらと思います。

なお、冒頭でも申し上げたように、選考過程に関する情報公開は禁止されているため、選考の具体的なプロセスやその内容に関して、本記事内で記載することはできかねること、ご了承ください。

本記事内で紹介する情報は、全てインターネット、書店等で販売されている書籍等を通じてパブリックにアクセスできるものとなっています。本記事を通じて得られる、これらの情報源を生かし自身のITスキルを高め、もし選考に臨まれる際には、個々人の能力を最大限発揮できるようなことに繋がれば幸いです。

この記事に対して良いフィードバックをいただけるようでしたら、筆者がオファーをいただいた他のIT企業に関しても同様の記事も作成しようと思うので、ぜひよろしくお願いします！

---

1. ITメガベンチャー業界における独自の選考プロセス「コーディングテスト」に求められる力

さて、皆さんは新卒時の就職活動におけるプロセスに関して、どのような理解をされているでしょうか？

ほとんどの方は、以下のようなフローに沿って選考プロセスが進むと認識されていると思います。

実際、この理解は概ね正しいです。一方で、独自の専門的な能力が求められる業界においては、選考過程の中で特殊な課題や選考プロセスを採用しているということも少なくありません。

例えば、コンサル業界における選考プロセス内では、「ケース面接」と呼ばれる、特定のビジネス課題に関する解決案を、何らかの論理的な根拠に基づいて面接官に提案する形式面接が行われることが多く、コンサル業界を希望する学生たちの間では、それに向けた独自の対策を行うことが常識となっています。

そして、IT業界に関しても同様に、いくつかの外資系IT企業における選考では、「コーディング面接」と呼ばれる、ある技術的な課題に対して、面接官とのディスカッション等を通じながら、プログラミングを用いた実装を行い、できるだけ品質の高い解決案を提供するといった形式の面接が有名です。

また、IT業界においては、他にもこれに類似した形式の選考プロセスとして「コーディングテスト」と呼ばれる、オンライン上で決められた実装課題に対して、プログラミング言語を用いた実装を行い、制限時間内に提出するという形式の選考プロセスが有名です。内容自体は先述の「コーディング面接」と似ていますが、面接官とのコミュニケーションが何を媒体として行われるか、すなわちそれが「会話」主体であるか、あるいは「提出されたコード内容」主体であるかという点で異なっています。

今回紹介するメルカリ, リクルート, サイバーエージェント, LINEヤフー, DeNA を始めとしたメガベンチャー企業における選考フローにおいても、ステップの一環に「コーディングテスト」が組み込まれています。

なお、その他に「コーディングテスト」を選考フローに組み込んでいる会社では、
Google, Amazon, Indeedを始めとした外資系IT企業が有名です。

いわゆる一般的な選考プロセスにおける「ES」「SPI」「GD」「個別面接」に関しては、ネットやSNSにいくらでも記事が挙がっていると思いますが、「コーディングテスト」に関しては、なかなか充実した情報がないというのが現状です。

そういった課題点も踏まえながら、本記事では、この独自の選考プロセス「コーディングテスト」で求められる能力に関して整理してゆきつつ、それに向けた対策方法についての有用な記事となることを目指してゆきたいと思います。

早速ですが、「コーディングテスト」において求められる能力はどのようなものでしょうか？筆者は「コーディングテスト」において求められる能力は、大きく分けて以下の 2 点の能力に分類されると考えます。

• アルゴリズム力

• 実装デザイン力

まず本セクションでは、それぞれの能力についての内容を紹介してゆきたいと思います。

1-1. アルゴリズム力って？

アルゴリズム力とは、与えられた問題に対して最適なアルゴリズムを選択し、実装する能力を指します。効率的なアルゴリズムを考え出すためには、問題の本質を理解し、適切なデータ構造やアルゴリズムを選択する能力が必要となってきます。

これに関しては、次に示す実装デザイン力と同様に一朝一夕に身につけることができるのではなく、多くの問題に取り組んで経験を積むことが大切です。

とはいっても、後述に示すように、対策に役立つサイト及びそのための方法はすでに確立されているため、それに沿って対策を行えば道筋は立てやすい方だと思います。

1-2. 実装デザイン力って？

実装デザイン力とは、アルゴリズムを実際のプログラムとして実装する際の設計力や技術力のことを指します。良い実装デザイン力があると、効率的で保守性の高いコードを書くことができます。具体的には、アルゴリズム以外の、変数や関数の命名、コードの構造化などについてが該当します。

これに関しても同様に、一朝一夕に身につくものではなく、加えて対策に役立つ方法も確立しているとは言い難いです。具体的にどうすれば能力が伸びる等は断言できないのですが、それに向けたグッドプラクティス等に関しては、後半のセクション内で紹介できたらなと思います。

1-3. まとめ

まとめると、

• アルゴリズム力＝問題を解決するためのアルゴリズムを考え出す能力

• 実装デザイン力＝アルゴリズムを実際のコードとして実装する際の設計力

ということですね。

アルゴリズム力は問題解決の土台を築き、実装デザイン力はその土台を使って実際にコードを書く力というように、両者は互いに補完関係にあるわけです。

それでは、次のセクションにおいて、これらの能力の重要性について具体例を通じて理解を深めてゆきましょう。

---

2. アルゴリズムだけでない！わかりやすいコードを書くことの大切さ

同じ内容を実装するコードであっても、初めてコードに目を通す第三者がその内容対して抱く心象は千差万別です。

たとえ、どんなに関数内部のアイデアが素晴らしくても、そのコードの実装が良くなければ、誰もその関数を使ったり、メンテナンスしたいとは思わないでしょう。

具体例を通じて考えてみましょう。

以下に示すコードは、0 より大きい整数に対する、約数のリストを返す関数をPythonを用いて実装したものになります。

【改善前のコード】

def f(n,flg):
    ret = []
    for i in range(1,n+1):
        if (temp:=i*i) > n:
            break
        elif temp==n:
            ret.append(i)
        elif n%i==0:
            ret.append(i)
            ret.append(n//i)
    if flg:
        ret.sort()
    return ret

上の実装をパッと見ただけでは、この関数が何をやっているのかだったり、それぞれの引数がどのような役目を果たすのか等、わかりませんね。

また、各オブジェクトの型が明示されていない以上、コードに修正を加えたりする際も、迂闊にコードをいじることができなさそうです。

これでは、誰もこの関数を使いたいとは思わなくなってしまいそうなので、もう少し上記のコードに改善を加えてみましょう。

【改善後のコード】

def calculate_divisors(num: int, sorted: bool = True) -> list[int]:
    """
    Calculate the list of divisors of 'num'.

    Time complexity: O(sqrt)

    Args:
        num (int): The number for which divisors are calculated.
        sorted (bool, optional): Whether to return the divisors in sorted order. Defaults to True.

    Returns:
        list[int]: List of divisors of 'num'.

    Raises:
        AssertionError: If 'num' is not greater than 0.

    Examples:
        >>> calculate_divisors(10)
        [1, 2, 5, 10]
        >>> calculate_divisors(15, sorted=False)
        [1, 15, 3, 5]
        >>> calculate_divisors(7)
        [1, 7]
    """
    assert num > 0

    divisors: list[int] = []

    for d in range(1, num + 1):
        # NOTE: Note that the divisors of num up to the smaller one are at most O(sqrt).
        if (sq := d * d) > num:
            break
        elif sq == num:
            divisors.append(d)
            break
        elif num % d == 0:
            divisors.append(d)
            divisors.append(num // d)

    if sorted:
        divisors.sort()

    return divisors

ということで、先ほどのコードに改善を加えたものが上のコードです。

変数の命名を修正 + 明示的に型を示し、コード内部に適切なdocstringを付け加えることで、何をやっているか第三者にわかりやすいコードになるようにしました。

本質的な実装の内部構造に関しては、何も変わっていません。
あくまで、コード内部の体裁のみに関する修正です。

しかしながら、「修正前のコード」と「修正後のコード」に対する第三者のコードに対して抱く心象は大きく異なると思います。

「修正前のコード」はともかく、「修正後のコード」だったら、「この関数なら使えそうだな、アレンジできそうだな」と思う方も多いのではないでしょうか。

次のセクションでは、この「修正前のコード」「修正後のコード」を比較対象に用いながら、コーディングテストの際に心象の良いコードを書くうえで意識すると良いポイントに関して、いくつか筆者の考えを共有したいと思います。