アルゴリズムのせいで面接に落ちた

Original article:https://dev.to/raulfdm/i-failed-an-interview-because-of-an-algorithm-3f9k

以下はRaul Melo ( Twitter / GitHub / dev.to / Medium / Webサイト ) による記事、I failed an interview because of an algorithmの日本語訳です。

I failed an interview because of an algorithm

開発者の皆さん、こんにちは。

この数週間、私はとある大企業の採用プロセスに参加していました。
それは非常に刺激的な経験で、採用過程についての多くの知見、コーディングの課題、そして面接のためにどのような準備をする必要があるかと、多くのことを学びました。

タイトルでわかるとおり、私は合格できませんでしたが、全ての段階を経験しました。
なので、これから初めて仕事に就こうとしている人、転職を考えているけど数年は面接をしていないという人たちにとって、参考になるかもしれません。

これから採用プロセスの全段について、感想を交えつつ詳細に説明していきますが、主に伝えたいことは、なぜ最後のパートで失敗したということです。
私の経験が、あなたの役に立つことを祈っています。

Stage 1: Getting an interview

欠員を埋めるために、社員にインセンティブを出して人を紹介してもらうことは、一般的な企業でごく普通に行われています。
(ネット内外で、できるだけ良い人脈を作った方がよい理由のひとつです)

私の友人が、彼の会社で働くことを勧めてくれました。
給料もよく、組織もしっかりしていて、とても働きやすい職場だから、来てみないかい？

私は自分のオンライン履歴書を多少調整する必要がありましたが、その準備はすぐに終わりました。

Stage 2: Human Resources (aka HR)

会社の人事担当が、私のことを知りたいと電話をかけてきました。

私の職歴やこれまでの人生でやってきたこと、特定の知識(React、テスト、Reduxなど)を持っているかどうか、そして今働いている会社について尋ねてきました。
正直なところ、これらの質問は非常に基礎的で些細なことばかりだったので、単に履歴書で嘘を言っていないかフィルタしているだけのように思われました。

私は全ての質問に自信をもって答えたし、担当者も電話の最後にポジティブな言葉をくれました。
そして次に、こんどは技術リーダーとチームマネージャと面接を行うことになりました。

Stage 3: The managers

翌週、私はマネージャとWebカメラ越しに1時間の面接を行いました。

彼らのビジネスは、私のソフトウェアスキルについて知ることでした。
次のような質問を受けました。

・今までのキャリアで最も誇りに思った瞬間は何ですか？
・今までに行った技術的決断の中で最も悪かったものは何ですか？
・敵対者とどのように立ち回りますか
・トップダウンの意思決定にどう立ち向かいますか
・紛糾した議論をどう収めますか

そしてこれらの質問について、私が実際に考えたり問題に対処していたと証明できるように、幾つかの状況を例示するように求めてきました。

自分のキャリアの中でよかった時のことと悪かった時のことを思い出すことになり、プロとして人として成長できたと感じられました。

面接を終了したとき、私はその結果にとても自身がありました。

数日後、人事から電話がありました。
マネージャは私のことを気に入り、そして私の受け答えはとてもよかったと教えてくれました。
唯一のフィードバックは、"受動的になりすぎていた"ということでした。
彼らは私のことをリーダーではなくフォロアーであるように認識していました。
私はもうすぐ30になりますが、正直なところ技術的な好みやコードの書き方についての無意味な議論を続けるエネルギーを失ってしまいました。
個人的な意見は持っていますし、どうしてそう考えているかを主張することは今でもできますが、でも話が個人的嗜好の押し付けになってくると、諦めて人の好きにさせるだけです。

私にとって、最高のJSフレームワークは何か、最高の状態管理ライブラリは何か、reduceを使うべきかmap+filterを使うべきか、Jestでitを使うべきかtestを使うべきか、などといった話題はもはやどうでもいいです。

私が気にするのは、問題解決に最適なソリューション、適切なネーミング、テスト、可能なかぎりシンプルな解決策、製品出荷、そして今月の給与額です。

かつては何が一番良いか、何が最もよくないか、など終わりのないバトルに明け暮れていました。
今でもそういった話に参加することはありますが、話が進まなくなったらただただ同意して先に進むようにしています。

とはいえ、それらを馬鹿にしているわけではありません。
悪い判断がなされてしまったと確信し、そしてそれを証明できるならば、それを防ぐために何処までも戦います。
会社の立場からすると、最も価値のある選択を行うために長い議論をすることも必要かもしれません。

Stage 4: the HR (again)

その後また人事から電話があり、前回マネージャに聞かれた質問について再び聞かれました。

私のソフトウェアスキルについて、自分自身でも確認してみたかったようです。
特に嘘をついたりはしていなかったので、同じ回答をできました。
また、どうして私がフォロアー的体質だとマネージャが感じたかの理由について得心したようでした。

次のステップは、二人の開発者が私のハードウェアスキルをテストし、QAマネージャがその審査をするということでした。

Stage 5 (latest): The devs

このステージが最難関だったので、ここについては詳細に語ろうと思います。
わからないことがあれば、疑問に答える幾つかの記事をお勧めします。

最初にメールで、JavaScript、CSS、テスト、ステート管理、React、そしてHTTPなどのトピックについて質問するという概要が来ましたが、具体的にどのような話になるのかはまだわかりませんでした。

面談は1時間30分の予定でしたが、10分遅れて始まりました。

チャットルームに参加すると、まずどのように進行するかについてプレゼンを受けました。
・私が現在何をしているかを知るために20分～
・技術的コンセプトについて回答と解説に30分
・コードチャレンジに30分

About me

まずは再び、私が今の仕事で何をしているかを説明しなければなりませんでしたが、これまでよりぐっと技術的な話でした。
もっとも、Webエコシステム全体を担当しているのは私ともう一人だけだったので、プロダクトがどのように構成されているかは概ね把握していました。
プラットフォームは何か、私の責任担当は何か、日々のタスクはどのようなものか、チームをどのようにハンドリングしているか、などについて詳細に話しました。
幾つかのトピックについては深く掘り下げて質問されることもありましたが、特に問題になることもなく終了しました。

Technical questions

ここから話は技術的でトリッキーなものになり始めました。
ここでは詳細な解決策にまで言及することは避け、質問に対する私の印象、そしてそれらを解説する記事へのリンクを付けておきます。

JavaScript questions

Can you explain the difference between var, let, and const?

var/let/constの違いを説明できますか？

油断のならない質問です。
最近JSを始めた人は特に。

多くの人はこう答えると思います。
『基本的に常にconstを使い、再割り当てが必要な場合にのみletを使う』

幸い、私はvarからlet/constへの移行を目の当たりにしていたので、これがスコープについてのものであることをはっきりと覚えています。

constを使っていても再割り当てが行われることを示すため、彼らはふたつ目の質問を投げかけてきました。

Var, let and const- what's the difference?

How can you freeze an object?

オブジェクトの再割り当てを禁止する方法は？

ES6の学習中にこれを起因とするバグに遭遇していたので、この概念を知っていました。
オブジェクトが何故突然変異しているかを調べた結果、Object.freezeに辿り着きました。

これはわかりやすい機能です。
オブジェクトをfreezeさせると、その後値を変更しようとしても変化することはありません。
ただしfreezeはオブジェクトの1段階目にのみ有効であって、入れ子の奥にあるオブジェクトや配列はfreezeしないことに注意しましょう。

const 📦, seal 🤐, freeze ❄️ & immutability 🤓 in JS

Can you explain what DOM is?

DOMとはなんですか？

何の頭文字かは忘れましたが(Documment Object Model)、一番簡単な質問だったと思います。

DOM Tutorial

Can you explain how events propagate in the DOM?

DOMのイベントバブリングについて説明してください。

この質問に答えることができたのは、Reactを使い始める前に自分でJSフレームワークを作った経験があったからです。
至る所で発生するイベントをキャプチャしたり、バブリングの仕組みを学ぶことができたよい経験でした。

Event Propagation in Three Parts!

What's the advantage of using a single event to capture events?

イベントのキャプチャをひとつにまとめることの利点は？

この質問については、正直よくわかりませんでした。

かつてバニラJSでフォームを作ったときに、個々のinput全てにonChangeイベントを設定するのではなく、formに設定して内部で処理を分岐するように実装したことがありましたが、どうしてそのようにしたのかは忘れてしまいました。

私の予想はパフォーマンスでした。

回答はまさにその通りで、またそのことのとてもよい例を教えてくれました。
何千ものレコードを持つテーブルがあったとして、全ての行にイベントを設定すると、DOMは何千ものイベントを管理しなければならなくなるため、確実にパフォーマンスの問題が発生するでしょう。

この記事の例が気に入りました。

Event Delegation - What is it and why should I care?

Do you know what the Request animation frame API is and why we would use that?

Request Animation Frame APIを知っていますか？どうしてこれを使った方がいいですか？

この5年間でRequest Animation Frame APIは一度か二度くらいしか使ったことがなかったので、どうしてこのようなAPIが存在するのかわかりませんでした。
そのため、アニメーションのパフォーマンスを上昇させるためではないかと推測しました。

そのとおりだと教えてくれました。

Creating animations in Javascript using requestAnimationFrame

CSS questions

Do you know about the different displays?

displayの違いについてわかりますか？

この質問は初耳でした。
各displayプロパティについて説明すればいいのか、それとも単に「はい、知っています」と答えればいいのかよくわかりませんでした。
とりあえずinline、inline-block、block、grid、flexなどがありますと答えましたが、どうやらそれが彼らの求めていた答えのようでした。

CSS Display property

What's the difference between display inline and display inline-block?

inlineとinline-blockの違いは何ですか？

これは覚えていませんでした。
inlineとblockはCSSではよくある違いなので知っていましたが、inlineとinline-blockの違いまでは覚えていませんでした。

面接官が説明してくれましたが、inline-blockは要素にmarginやpaddingを定義できるのに対し、inlineにはできないということでした。

CSS Basics Layout Fundamentals: Block, Inline & Inline Block

How can I center something vertically?

どうやって中央に縦に並べますか？

他の似たようなトリッキーな質問が来るかもしれません。
なぜなら色々な方法があるからです。

私が知っているのはdisplay: flexを使って、justify-content: centerとalign-items: centerで並べるというものでした。

そして、それで十分な答えでした。

How to Vertically Align Anything with CSS

HTTP questions

Can you tell us what methods are available in HTTP?

HTTPで利用できるメソッドを教えてください。

Nodeでバックエンドを扱っていたので、さほど難しくないと感じました。

・GET
・POST
・DELETE
・PUT
・PATCH

するとPUTとPATCHの違いについて聞かれ、そして頭を抱えました。
片方はデータ全体を新しい内容に置き換え、もう片方は送信された内容のみを更新するものだったと思うのですが、どっちがどっちかを覚えていませんでした。
正解は教えてもらいました。

さらにOPTIONSのような他のメソッドを知っているかも聞かれましたが、正直全然知りませんでした。
時々ネットワークモニタでOPTIONSの文字を見ることはありましたが、それが何なのかを気にしたことはありませんでした。

Difference Between Those HTTP Requests

How the HTTP status codes are divided?

HTTPステータスコードはどのように分けられていますか？

これはHTTPの基礎です。
APIを使うアプリを作るようになってから、この意味を調べてhttps status dogsを見つけていたので、それを暗記していました。
これは素晴らしい覚え方です。

The HTTP Status Codes You Need to Know

Technical Challenge

小テストのような問題を想定していたので、技術的課題にはかなりの覚悟で臨んでいました。

30分あればきっと解けるに違いない

ひとつのJSファイルと共にCode Sandboxへのリンクが送られてきました。

// index.js
/*
We have lots of deployment dashboards where we have drop-down UI to select an application version to deploy. We want to ensure that software version numbers delivered to our UI from the back-end API are always ordered with the newest (highest) available version at the top.

Eg:
const input = [0.1.0, 3.2.1, 2.2.3, 0.1.1];
sortVersions(input) should return [3.2.1, 2.2.3, 0.1.1, 0.1.0];
*/

const sortVersions = (unsortedVersions) => {
  // code
};

export default sortVersions;

そして動作確認のテストファイルも。

// index.test.js
import sortVersions from './index';

it('should sort correctly numbered versions', () => {
  const versions = ['0.2.0', '3.1.2', '0.1.6', '5.0.0'];
  const output = ['5.0.0', '3.1.2', '0.2.0', '0.1.6'];
  expect(sortVersions(versions)).toEqual(output);
});

// Other assertions

課題のルールとして、GoogleでJSのAPIについて検索することは許可されていますが、具体的な解法の検索は禁止でした。

最初の問題はとても簡単でした。
回答もシンプルです。

const sortVersions = (unsortedVersions) => {
  // code
  return unsortedVersions.sort().reverse();
};

あっさり合格です。

さらに二つ目のアサーションファイルが送られてきたのですが、私はここで詰まってしまいました。

// index.js

it('should sort correctly numbered versions with different lengths', () => {
  const versions = [
    '1.3.0.9',
    '0.2.0',
    '3.1.2',
    '0.1.6',
    '5.0.0',
    '3.3.3.3',
    '3.3.3.3.3',
    '3.10',
    '0.2.0',
  ];

  const output = [
    '5.0.0',
    '3.10',
    '3.3.3.3.3',
    '3.3.3.3',
    '3.1.2',
    '1.3.0.9',
    '0.2.0',
    '0.2.0',
    '0.1.6',
  ];

  expect(sortVersions(versions)).toEqual(output);
});

先ほどの私の回答では、答えはこうなってしまいます。

[
  '5.0.0',
  '3.3.3.3.3',
  '3.3.3.3',
  '3.10',
  '3.1.2',
  '1.3.0.9',
  '0.2.0',
  '0.2.0',
  '0.1.6',
];

何故そうなるかというと、単純な文字列比較を使っているからです。
アルファベット順では3.3は3.10より後になります。
しかし、セマンティックバージョニングでは3.3より3.10のほうが大きくなります。

ソート方法をいじくって、全てのバージョン文字列を最も長いバージョンと同じ形式に揃える方法を思いつきました。
正直この時点でだいぶ緊張していたのですが、その『単純な』解法を思いつくことができず焦ってしまいました。
面接官が解法のヒントを教えてくれたのですが、理解することができませんでした。
正確に教えてくれなかったからというわけではなく、様々なことを同時に考えすぎていたため頭が追いつかなかったのです。

全てのバージョンを同じ長さにするコードを書いているうちに、時間切れになってしまいました。

もっと時間があったらどのように解決するか聞かれたので、このように全てのバージョンを同じ長さにしてブロックごとに比較すると答えました。

面接のために時間をとってくれたことに例を言い、我々は通話をオフにしました。

もしこの問題に興味があるならば、StackOverflowを覗いてみるとよいでしょう。
この回答は全てのテストをパスしました。

After the test

正直、通話を切った時点で駄目だったと確信していました。

過去5年間でもっと難しい問題もたくさん解いてきたというのに、ただのソート問題程度にやられてしまいました。
私はいったいどうしてしまったのでしょうか？

しかし、それ以前の全てのステップはうまくいった、技術的な質問もだ、きっと挽回できる。
必死に自分を慰めようとしました。

The last HR Call

一週間の煩悶ののち、人事担当から電話がかかってきました。

「残念ですが、ここでおしまいです。」

悔しさを抑えきれませんでした。
その理由と改善点について尋ねました。

開発者はあなたのコミュニケーション能力やエネルギー、しすてほとんどの技術的質問に正確に答えたことをとても気に入っています。
しかし、最後の問題の方針がよくなかったと考えています。

頷くしかありません。

この決定に異を唱えることもできたかもしれませんが、既に裁定は下されたのです。
結果を変えることはできないでしょう。

電話を切った後5分ほど立ち竦み、感情を消化し、このプロセスの全てについて顧みることにしました。

Thoughts about hiring X our skills

あなたがその人生で面接担当になったことがあるかはわかりませんが、私はあります。
それは簡単なことではありませんでした。
採用プロセスは、一般的に非常に難しい問題です。

我々は候補者を透明性や正確性を最大限に保ちながら評価する基準やステップを定義しなければなりませんが、いまだに完璧な方法は存在しません。
人々は互いに異なる方法で考え、学び、問題を解決し、コミュニケートしています。
我々は全員に共通するガイドやフィルタで他者を評価しようとしています。

すなわち、誰かがあなたの期待する基準に合わなかったとすれば、それはその人がこの仕事に向いていなかったという印かもしれません。
しかし、それはその人に才能がないことを表すのでしょうか。

私は決してそう思いません。

私は開発者として初めて仕事をしたときに、似たようなコードチャレンジを行い、そして突破した記憶があります。

当時の私と今の私では何が違うのでしょう。
そのころ、私はFreecodeCampでアルゴリズムの問題を解く練習をしていました。

就職してからは、私は優秀な社員であることを証明してきましたし、面接で聞かれた難しいアルゴリズムは、プロダクトには全く関係ないものだったと断言できます。
何故ならば、難しい問題を解決するために、他者がどのように解決しているかを調べるために、Googleを使わなくてよかった時間はほとんど無かったからです。

解決すべき難問はいくつも横たわっていましたが、それらを全て短時間で、あるいは長時間で、時には人の力を借りて、時には独力で乗り越えてきました。
今の仕事を得るために、公開APIを使うReactアプリを作り、E2Eテストを行い、無限スクロールやページ移動アニメーションを作りこみ、アプリをホストし、ソリューションを紹介し、そして幾つかの問題を解決するためにペアプログラミングに取り組みました。

そしてそれらは、今はお金を稼ぐために日々行っていることです。

アルゴリズムを解けないということは、開発者に向いていないということなのでしょうか。

そんなことはありません。
ある条件で問題を解くことに失敗したというだけのことです。
そしてそれが、ある人にとって他者の才能を評価する基準だったというだけのことです。

ここで言いたいのは、私が採用されなかったことに文句を言いたいということではありません。
面接に失敗したことが即ちプロとして失敗したという意味 ではない ということです。

Learnings

採用プロセスは深く自分のためになりました。

次の機会があれば、そのときはソフトウェアスキルの質問にも容易に答えられるように準備をして挑むことにします。
それにinlineとinline-blockの違い、OPTIONSメソッドとはなにか、PUTとPATCHの違いなどはもう忘れることはできないでしょう。

しかし最大の学びは、全てに対して備えなければならない、ということです。

ReactやVueやAngularを使ったアプリの実装をさせられるかもしれませんし、トリッキーなJSの問題を振られるかもしれません。
備えるために、手始めにCodewars、FreeCodeCamp Learn、そしてCodility等に一日数時間を消費し始めました。

また自分のWebサイトに新しい何らかを実装し、堅牢なフロントエンドアプリを実装するスキルをさらに磨いていくつもりです。

Conclusion

私の経験が、あなたが初めての仕事を得るために役立ち、採用プロセスに立ち向かう準備を行う心構えになることを願っています！

コメント欄

「だからこそ、多くの開発者がもっと現実的な採用プロセスを求めているのだ。10年コーディングしてるけどフィボナッチアルゴリズムを使ったことがないし、ググれば5分で答えがわかる。」
「実際にはほぼ使われてないような怪しげなソートアルゴリズムで評価するなんて役に立つものかね？」
「ドキュメントに書かれてることを質問する採用プロセスは下策。開発者は脳内にマニュアルを持ち歩く必要はない。」
「開発者が半日かけてやっていることは、Googleで調べることだ。」「マイナーなライブラリを使っていたら検索に全く引っかからず、自分でどうにかするか開発者に聞くしかなかったんだが。」「そんなこともあるかもしれないがレアケースだろう。」
「マイクロサービス、CI/CD、Docker等の台頭によって日々の業務は大きく様変わりしているのに、面接プロセスがその変化を見抜けていないことに困惑する。」
「理論計算機科学はWeb開発者にとって直接役に立つものではないかもしれないが、問題を解決するためのツールとして役立つので知識を維持しておく価値はある。」
「Raulが落とされた理由は次のどちらかでしょう。A:既にsortできない開発者がたくさんいるのでもういらなかった。B:Guru開発者しか欲しがらない会社だった。Bの会社はイノベーションに必要な"愚かな"質問をする開発者がいないので、最後には失敗するだろう。」
「採用は双方向だ。会社があなたを評価するのと同じくらい、あなたも会社を評価し、一緒に働けないと思ったら断るくらいでいいのだ。」
「Object.freezeやrequestAnimationFrameといった質問は、知っていることそれ自体より、知識の幅の広さを調べようとしたのではないかと思います。知っていれば便利だけど、毎日使うようなものではありません。」
「ドットで区切ってそれぞれ数値比較すればいいんじゃね。」「おそらくそれが期待された答えで、特別なアルゴリズムも不要だよね。」

「以下はIntl.collatorを使った答えです。」

const sortVersions = (unsortedVersions) => { 
  return unsortedVersions.sort(new Intl.Collator('en', {numeric: true, sensitivity: 'base'}).compare).reverse() 
}

「数値で比較すると2.1.0aが正しくならないよ。」

const sortVersions = (x, v = (s) => s.match(/(\d+)|[a-z]/g).map(c => c == ~~c ? String.fromCharCode(97 + c) : c)) => x.sort((a, b) =>v(b) < v(a) ? 1 : -1)

コメント欄で自説を滔々と開陳する人が多くて困惑する。
最後のコーディング問題そのものには、多くの人が面接で有用ではないだろうとコメントしていました。

感想

このくらいのスキルの人ならいとも簡単に解けそうな課題に見えるのですが、やっぱりこういう場では緊張してしまって実力が出せないなんてこともよくあるのでしょう。

面接でコーディングさせることについては私も懐疑的です。
なんかちょっとしたところで数時間引っかかって、解けるときは一瞬で解けるなんてことはこの仕事ではよくあることですからね。
コーディングそのものではなく、考え方を評価する手法は大いにありだと思います。
ただ、その点でいうとこの人の回答はあまり評価できるかんじではない気がしますね。

Qiitaでもよく転職系のエントリが上がりますが、なんというか根本的に採用プロセスが異なりますね。
面接にエンジニアが出てきてコードを重視する海外式、基本的にエンジニアが出ることはない日本式。
向こうも向こうで決して採用プロセスに満足しているわけではなく、色々と文句も出ているみたいですが、しかしどちらのほうがより優れているかといえば、海外式のほうが多少はよさそうではあります。
とはいえ、だったら日本の採用も全て海外式にするべきかと言われたら絶対に嫌ですね。
そういう企業があってもいいとは思いますし、あるべきだとも思いますが、全てがそうなるべきという意見には反対です。
何しろ私だったら一次面接で落とされる自信がある。

隙あらば自分語り

隙あらばってほど語った記憶は特にないけど、せっかくなので誰かの役に立つかもしれないし、自分の就職の話でもしておきますね。

国立大学を中退してコンビニバイトでぷらぷらやっていたのですが、当時の彼女に「就職もしてない人とは付き合えません」と言われたので仕方なくハロワに行きました。

当時の知識はというとプログラム=ゲームを作れるとかのレベルで、サーバ？なにそれおいしいの？
システムエンジニアとネットワークエンジニアの区別すらついていません。
ぶっちゃけ完全素人です。
そもそもプログラマになりたいとか何かを作りたいとか考えていたわけでもなく、社員になれればなんでもよかったので、事前に学習すらしていませんでした。

ハロワというとブラック求人ばかりとかクオリティ低いとか散々な言われようをされることが多いように思いますが、それまで書いたこともなかった職務経歴書の書き方(ほぼ空白)とか、面接の練習(問題点を死ぬほど突っ込まれた)とか色々を全て無料で教えてもらって、だいぶ人間に近づけたような気がするので今でも感謝しています。

そんなわけで就職活動を始めてからプログラミングの勉強を始めようとしたわけですが、ポートフォリオどころか参考書すら買う前に受けた2社目において、そこの面接官が何故か社長で、しかも何故か社長に気に入られてしまって速攻で正社員就職が決まりました。
面接の内容も、この記事のような技術的なものではなく、ほとんど世間話みたいなかんじで、せっかく教えてもらった付け焼刃の面接練習も役に立ったのかどうか微妙なところです。
技術的な話を振られたら間違いなく即死していたので、日本式採用プロセスには全面的に感謝しかありません。

まともに学習する前に採用されてしまったという結果でした。
そして現在もその会社で働いているので、実は転職経験もありません。
これで会社がアレだったら社畜乙ですが、ボナースは出るし有給も使い切ってるしここ数年は時間外平均10時間以下と、この業界にしては非常にゆるい環境だと思われるので、転出する気もあんまり起きないというか。
そのぶん額面はそこまでですが、でも激務だけど倍額出すぞと言われても今の方を選びますね。
10倍だったら悩むかも。
本当は今のままで倍額が、いや何もせずに10倍が一番いいんですけど。

せっかく思い返したのだけれど、誰の役にも立たないので書き起こす意味が全くなかったな自分語り。