ゆめみフロントエンド採用コーディング試験で確認しているポイントやよくある質問を公開
株式会社ゆめみのフロントエンドコーディング試験で確認しているポイントや、よくある質問を公開します！試験の課題内容はこちらの記事をご確認ください。
公開に至った背景
徹底的な透明性を大事にしている。
ゆめみのAndroid、iOS、サーバーサイドグループのコーディングテストを既に公開している。
弊社からの情報発信を通じて興味を持っていただく方が多い反面、応募するハードルが高いというフィードバックをいただく。
上記の理由からフロントエンドコーディング試験に関するより詳しい内容を公開することにしました。
可能な限り公開し、より多くの方に興味を持っていただくこと、選考フローにおいてミスマッチがなくなるきっかけになると幸いです。
よくある質問
実際に応募者からよくある質問をピックアップしてお答えします！
Q. ワイヤー通りに実装すればいいの？見た目は変えても良い？
A. 基本的な使い勝手さえ変わっていなければ見た目はぜひ個性を活かしたUIにしてください（かなり推奨）。デザイナーのチェックがあるわけではないので、センスは問われません（笑）見た目以外であっても条件に書いていないことは裁量自由です！解釈はお任せします。
Q. 完成していないとダメ？
A. ダメではないですが、マイナスポイントになってしまいます。しかしながら「気になるところは残してしまったものの見た目はお洒落にしてみました」などカバー要素があればフォロー可能です！
Q. 提出は早いほうがいいの？
A. 実装スピードが早いことは注目に値しますが、不要な変数やファイルが残っていたり、コミットメッセージが「とりあえず」のような内容だったりすると、マイナスポイントとなりますのでスピードよりもクオリティ重視のご提出をお勧めします。
Q. 提出するにあたり注意すべきところは？
A. 主に3点を提出前にご確認いただくと良いと思います。
① 必須要件を満たせているか
② チーム開発を意識してのGit/GitHubの活用ができているか
個人開発の感覚でついつい省きがちですが知識をアピールするチャンスでもあります。
また、Git/Githubを用いたチーム開発未経験の場合もしっかり考慮しますが、あまり気にしすぎる必要はありません。
③ 使用するAPIの特徴を考慮できているか
ブラウザの開発者ツールのネットワークタブで確認してみてください。
Q. リード・テックリードしか募集していないけど業務経験豊富なベテランしかダメ？
A. ゆめみでは即戦力ではなく成長率を重視しているので、他業種からの転職も歓迎です。
ポイント☝️：提出いただいた内容に対してかかった時間とこれまでの経験年数の関係は重要視しています。できたところ・できなかったところをREADMEに書いていただいたケースもあります（必須ではありません）。 ただ、できればチーム開発に必要なエッセンスだけは押さえておいていただきたいです（成熟している必要はありません）。
リードでの応募だとある程度の即戦力があるかを確認します。
高度な知識は不要だと思いますがモダンフレームワークでの「ステート管理が適切か」 「不要なレンダリングを防げているか」「ビルドまわりの設定が適切か」などが不足しているリード職の方は お見送りとなっている気がします。
Q. サーバーサイドもできてスクリプトも得意だが、マークアップはあまり自信がないかも。問題ない？
A. 現状のコーディング試験的にはマークアップよりロジック重視になっているものの、現在の業務では基本的にはどちらも大事ですので、マークアップもある程度できることが望ましいです。
Q. モダンなライブラリ(ReactやVue)はあまり触ったことがなくて、プリミティブなところを勉強しているのですが問題ない？
A. 即戦力は求めていないと前で回答していますが、React/Vue（できればNext/Nuxt）あたりの現代的なWeb知識は最低限必要（そのため試験も必須条件とさせていただいてます）。
Q. チェックする人って何人ぐらいいるの？評価ポイントは人によって変わる？
A. 2022年3月時点でアクティブなのは9名。4〜5名ずつ週2日チェックで応募者数が多い場合は2ペア、少ない場合は4名同時で確認します。2021年の10月頃から評価体制を整えておりチェックポイントや最終判断についても出来るだけ個人差による評価のブレがない環境で対応しています。
試験でよくみているポイント
次にレビュアーがよくみているポイントをいくつかご紹介します！
👀リンターやフォーマッターは導入されているか
要件であるESLintとPrettierがきちんと導入されているか、使用可能な状態になっているか、フォーマットされているかどうかを確認します。 extends する設定などは任意となります（リポジトリ全体でルールの統一がなされていれば OK ）。 ESLint と Prettier の両方がうまく機能するように注意してください。高度な設定をいただいても構いませんが、本質的なポイントではありませんのでバランスよく実装をお願いします。
👀 コンポーネント分割の粒度が適切か
コンポーネントが適切に分割できているか、ディレクトリ構成が適切かを確認しています。例えば Atomic Designを活用してコンポーネント分割がされていると Good ！
👀 ビューとロジックが分離できているか
上記とも関連していますが、コンポーネント内でビューとロジックが混ざってしまっていないかを確認します。なるべくコンポーネントはビューのみにし、ロジックは別ファイルに定義されているとGood！
⭕ セマンティクスなマークアップができているか
セマンティック要素を正しく使用できているか確認します。全て div で組むこともできますが、見出しに h1 を使用したり、セクションごとに section を使用したりと丁寧なマークアップができているのが好ましいです。
⭕ TypeScript を使っているか
中途の方は TypeScript が必須ですが、新卒の方でも TypeScript を使用していることが増えてきました。しかしany 型を使用していたり、 as を使用していたりするケースがあります。なるべく any 型や as は避けてコーディングするのが好ましいです。
❌ console.log が残っている、コメントアウトが残っていないか
不要な console.log やコメントアウトは無い方が好ましいです。（なるべく複雑なロジックを書かないようにするべきですが）複雑なロジックなど、コメントを記述する方が好ましい場合もあります。
❌ class でなく id 指定でスタイリングしていないか
同じidを複数個定義する事ができないため、思わぬ衝突が発生する可能性があるので控えるべきです。
👀 衝突の可能性が高い命名がされていないか
グローバルスコープにもかかわらず、 CSS 設計がされていなかったり、命名だけではなくリセット CSS 以外の場所で直接要素をスタイリングしていたりすると Next ポイントです。
👆 適切にテストが記述できているか
テストはさまざまな手法があるかと思いますが、最も効果的と思われる方法でデグレを防ぐようにしてみてください。ユニットテストの場合はカバレッジも確認します。
💯 全て成功するテストが記述できているか
記載いただいたテストが最新のリポジトリの状態でパスするかどうか実際に試しています。うっかり追加修正を入れた後、テストを修正し忘れてエラーになるケースがありますのでご注意ください。
🤖 CI を構築しているか
GitHub Actions などを活用して main（またはmaster）ブランチなど特定のブランチに変更があった場合に自動でデプロイやテストが走るような仕組みを導入している場合はGoodポイントとなります（が、こちらも実装の本質ではないので CI を高度に活用できていたとしても Web アプリケーションが機能していない場合は無意味となってしまいます）。
最後に
完成が難しかったとしても期間を有効活用して得意分野をアピールください。取り組み中に生じた質問等も受け付けています。1度きりのチャンスではなく何度でもリトライ可能となっています(※1)ので、皆さまからのご応募お待ちしてます！
※1 ご自身の状況に応じて一定期間の間を開けていただく必要があります。詳しくは採用面接FAQの「再選考について」をご確認ください。