然るエンジニア🙊の投稿 - Crieit

待てど暮らせど

2019-10-20T08:28:29+09:00

その昔日本で大学生をしていた時に同級生から聞いた話によると、新卒採用では受かっていると直ぐに電話がかかってくるが、落ちているとなかなか電話がかかってこないらしい。今もその通りなのかは分からないけれど、シリコンバレーでの僕の就職活動の経験（落とされた経験）はそれとは随分違っているように思う。落とすときの連絡は直ぐにくるし、プロセスが進めば進むほど、受かった時の会社側の対応が遅くなる。きっと日本の新卒では「決められた上限一杯になるべく良い人を探す」のが目的なので、面接の結果の良い人から順番に返答をしていくのだろう。一方で僕がやっている転職活動では、基本的に空いているポジションに合った人を探すのが目的なので、合わない人をどんどん切り捨てていく形になるのではないのだろうか？こちらでも (Newly Graduate) と書かれた新卒用のポジションを見ることがよくある（LinkedIn のレコメンデーションシステムがその辺を区別してくれないせいで）が、僕は縁がなかったので実際のところは分からない。昔こちらで面倒を見たインターンの学生が、「Google （のインターン）に受かったんだけど、面接の後のチームマッチングプロセスがクッソ時間かかったから、他に行くことにした」と言ってるのを聞いたことがある。チームマッチングプロセスがとても時間がかかる話はネットでも散見される。
話は逸れたが、Amazon のコーディングテスト + 抜き打ちインタビューから３日が経った頃、僕は不安になり始めた。「あれ、もう忘れられてるんじゃないの？」そう思ってメールで問い合わせをしてみた。返信が来たのはさらに３日が経った頃だった。リクルーターのアマンダにもまだ結果は分からないから、もう一週間ほど待ってみてとのことだった。この頃から長い間、僕はずっと慢性的な不安に苛まされ流ことになる。

結局、連絡が帰ってきたのは３週間も経った頃だった。３月になっていた。アマンダから電話がかかってきて次のステップに進むと言われた。次のステップからは違うリクルーターが話を進めるとのことだった。次のリクルーターはシアトルにいるマシューだった。例のごとくメールでの紹介が済んだあと、電話の予定を決めた。

番外編：最近のプライバシー関連の報道で思い起こされる話。

2019-09-07T10:54:08+09:00

最近のプライバシーに関する報道を見ていて、３月の中頃にこんなメールを LinkedIn 経由でもらったことを思い出した。

Job Opportunity at Apple!

Hi Taro, I came across your profile and wanted to see if you're open to new opportunities. I have an Japanese Language Engineer Position with Apple in Cupertino that you may be a great fit for. I am looking for someone who has experience with ML/NLP and can code in Java, Python, Shell, or equivalent. If interested in further discussion, please pick a time that works best for us to hop on a quick phone call! If you currently are not interested, but know someone within your network that may be, please feel free to forward them my information as we do offer a referral bonus for anyone you refer that is placed on the project. Looking forward to hearing from you!

クパチーノのアップル本社で日本語の機械学習・自然言語処理のできる「日本語エンジニア」を探しているという話だった。「日本語エンジニア」って肩書きはなんやねんとも思うのだが。

「え？何これ？こんなあつらえ向きの話あるの？」

メールを何度も読み返して自分の理解が間違ってないことを確認したら、急いで返信のメールを認めた。

（今改めて読み返してみると、「Java, Python, Shell もしくは同等の言語で実装の出来る」という表現は、Java と Python を同等とみなすのはよいとしても、Shell をそこに混ぜると何がなんだか分からなくなると思うのだが。）

このメールをくれたリクルーターの女性は電話で以下のようなことを言った。

アップルは機械学習の拡大に力を入れていて、英語以外の言語にもリソースを投入しようとしている。
仕事の内容は集まった Siri のデータの解析とそれを使用するエンジニアとの調整
採用プロセスはマネージャーとの電話のみ
労働時間は調整可能

「え、フルタイムじゃないんですか？」

「ええ、コントラクターになるの。」

コンタラクターか。。。それ以外の内容は申し分ないのに。

「コントラクターは、ビザ的に働けるか分からないですね。ちょっと。」

「うちで H1B ビザで働いている人は他にもいますよ。成果が認められて正社員にいなった人もいます。

労働条件は正社員と同じですよ。給与の支払い元と福祉条件だけが違います。

でも、うちもビザのサポートをしてますよ。」

「仮になんですけど、不況やらで人員調整の解雇になったらどうなりますか？」

「うちを通して他の派遣先を探しますよ。」

「ちょっとコントラクターという雇用条件が不明点が多いので、軽くリサーチをしてみますよ。」

「分かりました。ではまた追って連絡しますね。」

アップルのコントラクターについて軽く調べてみると、あまりいい話は出てこなかった。まあ部署によっても違うのだろうけれど。

アメリカでも日本でよく聞く（というか２ちゃんねるでよく見る）派遣・正社員論争とそう変わりないようだった。僕に取っていちばんの問題は LinkedIn に書けないということだった。それでは次の転職の際に苦労することになる。

そもそもアップルは正社員でも労働環境が良くないというのに、コントラクターでは中々の地獄を見るのではないだろうか？

（今のところシリコンバレーであった人々の中で日曜日も仕事をしているのは、アップルで働く日本人だけだ。）

ま、電話がかかってきたら丁寧にお断りするとしよう。そう思ったが、フォローアップの電話はかかってこなかった。

時は変わって、2019年も Q2 あたりになるとこの辺の話題のプライバシーに報道が敏感になってきた。

４月ごろには Amazon Alexa の会話を従業員が聞いているという報道があった。

Amazon reportedly employs thousands of people to listen to your Alexa conversations
アマゾンが Alexa の会話を聞くために数千人規模を雇用しているとの報道

このようなシステムのバックグラウンドに従事している者としてこのニュースを初めて聞いた時には、そこまで驚きはしなかった。僕自身も似たようなことを仕事柄することもあるからだ。ただしそれは合法的に、前もって明確な了解を得られた会話に限る話だが。まあ僕も、そんな仕事をしていなければ、驚いただろう。

そして７月、似たような注目が Apple の Siri にも飛び火した。

Apple contractors 'regularly hear confidential details' on Siri recordings
アップルの契約社員が Siri の録音を定期的に確認していることが判明

あれ、この契約社員の案件、前に来てたやつじゃん！と思って楽しく記事を読んだ。
案件の話を聞いている時はプライバシーの話は全くなかったことはないにしても、それでも大きな注目はなかったと認識している。世論は短い時間で大きく変わるものだなあ、と思っていると続報が入ってきた。

Apple suspends Siri response grading in response to privacy concerns
アップルはプライバシー上の懸念に応えてSiriの応答評価を停止中 [日本語]

これは少し僕には予想外だった。まあアップルは昨年の年次会議からプライバシー保護を前面に押し出しているいるので筋の通る話ではあるし、このリアクションこそがアップルが真剣にニュースを受け止めているという証拠だろう。幹部陣の中にもきっと報道を受けて初めてなぜ会話の解析を行う必要があるか説明を受けた人もいることだろう。

はて、じゃあ契約社員の人々はどうなったのだろう？やはり契約終了になったのだろうか？僕は雇用条件的にこの仕事に就くことはきっとなかっただろうが、中々他人事にも思えない話だった。

不意打ち

2019-09-03T07:37:31+09:00

>> 連載トップ > 前回のお話

Amazon のコーディングテストを受けてから数日後、オフィスについて車を降りたところでテキサスからの着信があることに気付いた。誰だろうと思って掛け直すと Amazon リクルーターのアマンダだった。

「ハイ、タロー。Amazon のアマンダです。コーディングテストの結果とその次のステップの話をしたくて電話しました。それで、結果なんですけど、」

こちらが相槌を打つ暇も与えずに、切羽詰まったかの様子でアマンダは話し続けた。

「あの、ちょっと今は時間がないので、折り返してもいいですか？えーっと、11時半はどうですか？」

「ええ。わかりました、それでは。」

リクルーターと電話で話をする際のストレスの一つは、こういった急にかかってくる電話だった。リクルーターにとっては候補者と話をすることは仕事の範疇内だが、候補者にとっては範疇外になる。オフィスで電話を取っても、話をするためにはプライバシーの確保できる場所まで移動しなければならないし、メモも取れない状況で様々な要件をまくし立てられても全部は聞き取れない。携帯電話のような低品質の音声で、相手が外国訛りならほとんど何をいっているか分からない。加えて、求職の身はどうしても遜った態度になりがちになる。電話する場合は緊急の場合を除いては前もって時間を指定するメールをしてほしいものだ。その方が話すべき内容も事前に準備できるのでより良いコミュニケーションになる。

そんな訳で、アマンダと話をするために昼前にまたまた例のスターバックスへやってきた。コーディングテストのフィードバックということで、特にヘマをやらかした覚えもないし、次のステップ（電話面接）の予定を決めるのだろうと思い、ある程度の日程に思いを巡らせてから電話に臨んだ。電話に出ると、アマンダは挨拶もそこそこに話始めた。

「それで、コーディングテストなんですけど、良い結果が返ってきました。それで次のステップに進んでもらおうと思っていて、それに関していくらか質問したいんです。」

「ええ、わかりました。」

僕は手元のカレンダーに目を落とした。

「ls と cd が何をするかご存知ですか？」

「・・・はぁ？」とほとんど声に出かかった反応が僕の頭の中では響いた。

「え? Linux のコマンドの話ですか？」

「ええ、そうです。ls と cd が何をするかご存知ですか？」

「こいつ何言ってんの？」と思いながら、僕は答えた

「ls は現在のディレクトリの中身を表示します。cd は引数にディレクトリをとれば、そのディレクトリに移動しますし、そうでなければ、ホームディレクトリに移動します。」

「なるほど、分かりました。ハッシュマップの利点と欠点を教えてもらえますか？」

「ハッシュマップっていうのはデータ構造の話ですよね？」

「ええ、そうです。」

「えーとまず、ハッシュマップはコンスタントタイムでのリトリーバルを実現しますね。欠点はバケットのサイズが固定なので、アイテムの数がバケットのサイズに比べて小さい場合にはメモリが無駄になるかと思います。」

ハッシュテーブルの話などここ数年していなかったので、ぱっと聞かれてまとまった答えを返すことは叶わなかった。後になって、欠点のメモリの話をする前提のバケットによるハッシュ関数の話をするのを忘れていたことに気付いた。今になって思うと、多分「通常の配列と違いインデックスによるリニアアクセスが出来ない」とかが期待されていた模範回答だった気がする。当たり前すぎるが。

「Post-Order Traversal とはなんですか？」

「木構造の Depth-first Seatch の話ですよね？」

木構造がインタビュー必出の話題とは言え、その前提を飛ばすとはなかなか不親切な聞き方をしてくれる。

アマンダは他にいくつかのアルゴリズムとデータ構造に関する質問をした。僕はたじろぎながらなんとか答えをひねり出していった。

「分かりました、ありがとう。以上で聞きたかったことは全部です。今日の結果を踏まえたフィードバックを提出しますので、また連絡しますね。」

「ええ、ありがとうございます。」

なんとも腑に落ちないモヤモヤした気持ちを抱えながら、僕は店を後にした。不意打ちの電話に加えて不意打ちのテストとは。

ただ、気になるのは、果たしてアマンダには僕の返答をきちんと理解する知識があったのだろうか？受け答えの感じからして彼女が前もって用意された質問リストから質問を選んでいるのは明らかだった。今日の問答は誰によってどうやって評価されるのだろうか？効率重視の Amazon のことだからおそらく彼女が電話越しに丸バツの判断を下しているのだろう。結果は果たして。。。

第十話に続く。

番外編：最近のプライバシー関連の報道で思い起こされる話。

コーディングテスト - 実践編

2019-08-12T11:29:32+09:00

>> 連載トップ > 前回のお話

コーディングテストであれ、次の面接の予定であれ、リクルーターは基本的にはこちらの予定を加味してアポを入れてくれる。毎度毎度予定を詰める段になると、「次のアポまでに予習と準備したいから二週間ぐらい空けるかな。」という発想である程度時間を開けるのだけれど、時間に余裕を持てば持つほどに、本番が近づいてきたときの緊張感とストレスもより一層大きくなる。

そんなこんなで、コーディングの練習は十日ほどで見切りをつけて、Amazon のコーディングテストを受けることにした。Leetcode.com の問題でだいたい Easy を１日３問で一週間。これでメインのトピック†を網羅した後、Medium を１日１問。それぐらいやると「もう十分だろう、もうやりたくない。」という気持ちで、テストから逃げるモチベーションから早くテストを終わらせたいモチベーションにシフトしていった。

コーディングテストではリクルーターが送ってくる専用のリンクにアクセスしてこれらの課題に取り組む。リンクは一週間で失効するので、自分の予定を加味してリクルーターにテストを発行してもらう。Amazon は myamcat.com というオンラインサービス††を使っている。テストを始める際にこのサイトは定期的にスクリーンショットをとる、タイピングを記録するなど、なかなか気持ち悪い要求をしてくる。これを許可しないとテストを受けられないのだがなんともスッキリしない。なんでも、こうしないと課題でズルをする人が後を絶たないからだそうだ。
テストは大体全部で２時間ほどで、コーディングの課題が二問と性格・行動適正診断がある。コーディングテストは全部で二問、合計で最大 90 分かけることが出来る。どちらの問題も「Amazon では、」と、一応問題をそれなりにカスタマイズしたような始まり方だった。一問目は以下のようなものだった。さて、これを読んでいるあなたは何が問われているかお分かりだろうか？

Amazon では、顧客第一をモットーの一つに掲げていて、商品を配達する際には最も早く商品が配達されなければなりません。出発地点、目標地点、通行不可能な道が与えられた場合に、最短経路を求めるプログラムを実装しなさい。経路情報は２次元配列として与えられます。

入力例
[
  ['s', '0', '0', '0'],
  ['0', '0', '1', '0'],
  ['0', '0', '1', 'g'],
]

出力
5

上の例では、s, g はそれぞれ出発地点、目的地点を表し、0 は通行可能な経路、1 は通行不可能な経路を表します。

問題の文章はもう少し説明が丁寧だったかもしれないが、まあ大筋は伝わるだろう。二次元のマップが与えられた場合の最短経路はどのようにして求められるだろうか？これを書いている僕の頭の中ではダイクストラ法という言葉が思い浮かんでいるが、それはこの問題にはオーバーキルだろう。この問題を実際に解いている際にはダイクストラ法のことなど思いもしなかったのだが、それはきっと事前練習のおかげで脳がよりコーディングチャレンジ仕様になっていたからかも知れない。では、どうすればよいかというと、模範解答は幅優先探索 (BFS) だろう。

木構造に関する知識、探索方法（幅優先(BFS)、深さ優先(DFS)）や、深さ優先探索の場合の処理の順番の違いなどは事前に習得していることが期待される知識だ。他にはリンクドリストや、ハッシュマップ、ハッシュテーブル等の特性、ソートアルゴリズムや再帰的な実装がよくテストされる。今回の課題では BFS を使って二次元配列の要素をどのように処理できるかを考える必要がある。

と、ここまで尤もらしいことを述べたが、実際には、この「２次元空間の最短距離」の問題は頻出問題の類なので、練習問題を多くこなした人なら大体みたことあるはずだし、課題に取り組む際にはそうであることが理想だと思う。そんな訳で実装の方法は例えばここで詳しく説明してあるので、ここでは割愛することにする。僕は見た瞬間に「あぁ BFS か。」と思ったので、どのようにしてそこにたどり着いたのかはうまく説明できない。きっと着想方法を説明したサイトも探せばあると思うので、それは読者の皆さんに委ねることにする。

二問目も同じような配送をテーマにした２次元配列を扱う問題だった。動的計画法を使うナップサック問題系の課題だったような気がするが、残念ながら忘れてしまった。

メインのコーディングが終わると、自身の解法に関する記述課題になる。要は自分の実装を評価するわけだが、ここで大切なのは時間とメモリに関する計算量をきちんと記述すること。O記法（ビッグオーノーテーション）を使って、入力のサイズが変わると、計算時間とメモリ消費量にどのような影響が出るのかを評価する。

例えば、上に挙げた最短経路の問題を BFS で解いた場合を考えると、目的地が見つかるまでノードを一つずつ処理していくので、計算にかかる時間は（最悪の場合で）与えられたマップのサイズに比例する。n, m をマップの辺の大きさとすると、O(n*m) となる。メモリ消費量は、辺の長さのうち、短い方に比例するので O(min(m, n)) となる。

頻出アルゴリズムの時間及びメモリ消費量の性質は覚えておくと、問題を解くときの判断の助けになる。忘れてしまった場合はさっと検索すればすぐに出てくる。

さて最後は性格診断である。これは選択問題形式で、日本の就活でよく見る SPI 等とよく似ている。「時間の余裕がない時でも落ち着いて対応できるか」などという実質一択問題がたくさんある。Amazon の場合はリーダーシップ理念というものを公に掲げているので、解答に困ったら、それに即したものを選べばよい。
全てに答えて、提出ボタンを押すとテスト完了となり、リクルーターに結果が送られる。リクルーターは結果を基に次のステップをアレンジする。

第八話「不意打ち」に続く。

脚注

トピック

Data Structure
- Array
- Tree Structure
  - Binary Tree Seach
  - Trie
- Stack / Queue
  - FIFO / FILO
  - Priority Queue
- Hash Table
  - Bucket Implementation
- Linked List
- Graph
  - Directed acyclic graph
  - Adjacency Matrix
  - Adjacency List
Algorithms
- Sort
  - Quick Sort
  - Merge Sort
- Iteration vs Recursion
- Dynamic Programming
- String Hashing
  - Palindrome Detection
Others
- Big O notation
- Stack vs Heap

UI

二年ほど前にもこのテストを受けたことがあるのだけれど、インターフェースが中々分かりにくくて、その時は次の課題に進むボタンだと思って押したボタンが提出ボタンだったことがある。その結果はお察し。

コーディングテスト - 練習編

2019-08-05T04:40:21+09:00

>> 連載トップ > 前回のお話

最初のヤマであるマネージャーとの電話は驚くほどつつがなく終わったので、その次の日曜日に、Amazon の最初のステップとなったコーディングテストを行った。

コーディングテストには、きちんと作動するコードが要求される。ブラウザーでテストサービスにアクセスし、専用のエディター上で要求されるコードを実装する。エディターにはテスト機能が付いていて、これを使うと前もって決められた入力パターンを試していき、正しい出力が得られるかどうかを確認する。要はユニットテストである。もしも正しい出力が得られない場合は、時間が許す限りコードを修正することができる。入力テストのパターンには大体エッジケース（特別な例外的な処理が要求される場合）や、入力データのサイズがとても大きい場合等が含まれていて（効率の悪い方法であれば時間内に処理が完了しないので不正解扱いになる）、これらを正しく処理できることが合格の要件になる。

このような課題はソフトウェアエンジニアの分野ではよくあるもので、インターネット上には練習に使えるサイトがたくさんある。リクルーターによってはそのようなサイトのリストと練習する際に気をつけることのリストなんかを一緒に送っくれて、受験者にどのように対策をすればいいか助言してくれる。というか、リクルーターの仕事はなるべく多くの採用者を出すことなので、大体のリクルーターがこのような対策用の資料を送ってくれる。例えば Facebook は専用ページで詳しい流れを説明してる。（Google は脚注参照）だからテストや面接が始まって予期していなかったということはまずない。

練習用サイトでよく名前が挙がる中†では leetcode.com が使いやすいと思う。日常的にコーディングを行なっている人は、練習する際には要求されていることが普段のエンジニアリングと違うということを意識するとよいだろう。エンジニアリングで重要なことは必ずしも課題を説く上では重要ではない。（メンテのしやすさとか。）僕は leetcode.com でまず Easy を解きながら、一通りのトピックをカバーして、その後 Medium を毎日一問一週間ほど続けた。この時、大事なのはコードを書き始める前にアルゴリズムの全体のプロセスをノートに書きだして整理しておくことだ。これは後のオンサイトインタビューの練習にも通じる。

例えば、38 Count and Say を見てみよう。

The count-and-say sequence is the sequence of integers with the first five terms as following:
1 is read off as "one 1" or 11.
11 is read off as "two 1s" or 21.
21 is read off as "one 2, then one 1" or 1211.
Given an integer n where 1 ≤ n ≤ 30, generate the nth term of the count-and-say sequence.

与えられた文字列を「何が」「何回」繰り返されるかによって書き直す。この処理を n 回繰り返したら得られる文字列を出力せよという問題だ。どのようにアプローチすればよいだろうか？

まず問題を分析して、必要なコンポーネントを洗い出そう。この問題は Easy なだけあって、全体の流れは簡単だ。まず処理する文字列を “1” で初期化し、与えられた n 回だけ書き換え処理を実行すれば良い。この処理はメインの関数とは別の補助の関数として実行すると良さそうだ。

では、どのようにして書き換え処理を実装すれば良いだろうか？まず、ルールを細かく見てコードに直して組み合わせでみよう。

まず、文字列全体の書き換えは、部分部分を独立に書き換える処理の組み合わせでできていることが分かる。

では、どうやって全体の文字列を個別の部分に分割すれば良いだろうか？しばらく図を眺めていると、これは単純に同じ文字の集合で分割すれば良いことがわかる。なるほど、与えられた文字列を前から順番に見ていき、次の文字が前と違っていればそこが分割箇所となるようだ。

ここの分割の部分がこの問題の中で最も複雑なので、先に取り出して実装してみよう。以下では Python の Generator 構文を使って分割を実装してみる。多分、普通に初見でこの問題を説く際には Generator を使わずに、全てを一つの関数で処理するだろう。実際僕もそうしたが、ここでは問題を細部まで分割して分析すること主眼におくのでこのような形をとった。関数を分けない場合の回答も後に述べる。

def _split(string):
    char, count = string[0], 1
    for c in string[1:]:
        if char == c:
            count += 1
        else:
            yield char, count
            char, count = c, 1
    yield char, count

この分割ではまず初めに、取り出す文字 char とその文字が連続して出現する回数 count を、与えられた文字列の最初の文字 string[0] と 1 で初期化する。そして、順番に残りの文字を確認していき、もし同じ文字が見つかったら回数を 1 増やし、違う文字が見つかった場合は、そこまでで分割が完了しているので、今保持している文字 char とその回数 count を放出する。分割ができれば、文字列変換のプロセスは簡単に以下のように書ける。

def _process(string):
    return_value = ''
    for char, count in _split(string):
        return_value += '%d%s' % (count, char)
    return return_value

分割された文字と回数をそのまま文字に変換して繋げるだけの簡単なロジックになる。あとはこれを課題の規定する入出力の形式に揃えるだけで良い。課題では入力は n すなわち変換処理を実行する回数で、文字列の初期値は ‘1’ なので、

def countAndSay(n):
    string = '1'
    for _ in range(n-1):
        string = _process(string)
    return string

となる。先述した通り、普通に課題に説く場合は Generator を使わないで、新しい文字列の生成と、それに必要な文字の分割、数え上げを一緒に実行するだろう。その場合の実装は以下のようになる。

def _process(string):
    return_value = ''
    char, count = string[0], 1
    for c in string[1:]:
        if char == c:
            count += 1
        else:
            return_value += '%d%s' % (count, char)
            char, count = c, 1
    return_value += '%d%s' % (count, char)
    return return_value

全体のコードをまとめると以下のようになる。

def _split(string):
    char, count = string[0], 1
    for c in string[1:]:
        if char == c:
            count += 1
        else:
            yield char, count
            char, count = c, 1
    yield char, count


def _process(string):
    return_value = ''
    for char, count in _split(string):
        return_value += '%d%s' % (count, char)
    return return_value


class Solution:
    def countAndSay(self, n: int) -> str:
        string = '1'
        for _ in range(n-1):
            string = _process(string)
        return string

このようにして、問題を分析し、1. なるべく簡単な基本要素を定義し、2. 基本要素を組み合わせてフロー全体を組み立てることが出来るとコーディングテストはうまくいく。練習初めは実装を行わなくても、よいだろう。問題を見て、一晩かけて解法を考えて翌日取り掛かってもいい。文法やデータ構造の知識も大切だが、練習する際に大事なのは分析することなのだ。

第七話「コーディングテスト - 実践編」に続く。

脚注

Google

Google は全部 YouTube ビデオになっている。

Prep Videos:
How to: Prepare for a Google Engineering Interview
How to: Work at Google — Example Coding/Engineering Interview
Interview tips from Google Software Engineers

More general about hiring at Google:
How to: Work at Google — How We Hire
Ask a Google Engineer — How to Work at Google: Prospective Employee Qualities

練習サイト

Google リクルーターが送ってくれたリンク集。

Websites recommended by Google Software Engineers:
Top Coder: https://www.topcoder.com/
(If you can handle the DIV I 250 level questions on TopCoder getting around 220+, then you are in good shape.)
HackerRank: https://www.hackerrank.com/
Project Euler: https://projecteuler.net/
LeetCode: https://leetcode.com
500 Data Structures and Algorithms practice problems/solutions: Quora
Competitive Programmer's Handbook: https://cses.fi/book/index.html

電話そして電話

2019-08-04T07:58:01+09:00

>> 連載トップ > 前回のお話

ジェームズ（ Apple のリクルーター）のアレンジで２月の中頃、Siri チームのマネージャーと電話することになった。

「もしもし、タローです。」

「タロー、ハーイ。Apple Siri チームのマネージャーのホセです。今日は時間をとってもらってありがとう。まず、あなたがどのような業務についているか聴かせてもらってもいいですか？」

「もちろん。

僕は SF ベイエリアにあるスタートアップでエンジニアとして働いています。この会社ではビジネス向けの自然言語処理ソリューションをウェブ上で提供しています。僕は、データ処理のパイプライン関連を主に担当しているんですが、モデルのトレーニングや評価も行うことがあります。

１０人にも満たないチームで、大学の研究室から始まったチームなので、エンジニアリングのレベルは高くないんですよ。だから、なんとかスケールするエンジニアリングを目指していましてね、開発からデプロイまでのプロセスを自動化したり、モデルの訓練をなるべく簡単にしようとしてるんです。そのために、チームメイトにコードレビューがなんたるか、CI がなんたるかという、まぁ基本ですよね、そういうのを教えたりすることもあるんですが、その分、僕も彼らから自然言語処理のあれこれについて教えてもらっています。モデルの訓練の際には GPU リソースの管理が難しくて。その辺は Apple のような大きな会社ではリソースとインフラが十分に構築されているかと思いますが。」

「そうですね、Apple はご存知の通り今機械学習に力を入れていてね、その内でも Siri は最重要チームの一つと言えるね。ただ、完全に内部インフラが整備されているかというとそうでもなくてね。そこらへんをスケールできるシステムを構築中しようとしているんですよ。」

「なるほど。僕はエンジニアなんですが、モデルのトレーニングなんかも出来たらいいなと考えているんですが、そういうキャリアパスはありますか？」

「問題ないですよ。僕のチームでもエンジニアから入ってトレーニングの方にシフトした人はいるから。」

「それは僕の理想ですね。どころでチームの所在地はどこに？」

「Siri の主だったチームはボストンとクパチーノになるね。僕は今はボストンから電話をかけてるよ。ボストンオフィス興味ある？」

「ええ。ありますよ。」

「分かりました。なかなか良さそうなバックグラウンドですね。この後のステップを手配しましょう。追ってリクルーターに連絡しますよ。」

「ありがとうございます。それでは、良い一日を。」

午後になり、ジョアンナ（ Google のリクルーター）から着信があった。ジョアンナの声はまだ若いのに年老いた皺だらけの魔女になろうとしているかのような声だった。話はいつもの流れになった。僕は自分の仕事について簡単に説明した。ジョアンナは、Google Brain はリサーチ系だから僕の履歴にはフィットしないが、機械学習を必要とするポジションはいくらでもあるので、そのようなポジションを見繕うといった。そして、その間採用のプロセスを進みたいかと訪ねた。僕はイエスと答えた。こうして Google とインタビュープロセスが始まった。

第六話へ続く。

pow(10, 100)

2019-07-27T10:06:44+09:00

>> 連載トップ > 前回のお話

「そんなわけで、Apple と Amazon でインタビューする流れになっだけど、Google にもレジュメ出すべきだと思う？」

「なんかやりたいプロジェクトでもあんの？」

「いや、特にないけど流れかなと。Siri, Alexa と来れば、Google のアシスタント。あれ、名前あったっけ？それに、LinkedIn の広告で Machine Learning Engineer ってやたら出てくるのよね。この会社。」

「出してみたらいいとは思うけど、去年、インタビューの予定が詰まったストレスで、Google のオンサイトインタビューキャンセルしなかった？」

「おっと、完全に忘れてた、それ。まぁあの時は気持ちの準備不足だったしね。」

「流れというなら、Facebook は？」

「Facebook は特にこれと言っては。音声アシスタントとかやってないし、AI 研究部門はすごいけど、エンジニアが入れるところじゃないし。それに、今はプライバシースキャンダルがすごいじゃない？」

「まあ、出すだけ出してみれば？」

「やってみるよ。」

シューカツの鉄則

アメリカで就職活動をする上での基本かつ重要なことは、なるべく多くの会社からオファー（内定）をもらうことだ。つまり、複数の会社を同時に受けることだ。

そんなの当たり前だと思われるかもしれないが、日本以上にこの違いは大きい。

複数の会社を同時に受けるとストレスが等比級数的に増加するが、その利点は、まず、新しい仕事が見つかる確率が上がること。次に、もし一社からオファーをもらっていると、他の会社の面接を余裕を持って受けられること。そして、最も大事なのが、複数のオファーを競合させて、より良い条件を引き出せるようになるのだ。

僕はあまり経験がないのだが、このオファーの交渉というステップはアメリカでは当たり前に行われていることで、オファーを出す会社側もそれを踏まえて、予算上限目一杯のオファーというものはいきなりは出さないようにしている。雇用条件を交渉できる状態にしておかないとそれだけで不利を被ってしまうのだ。ここでの交渉は、年収にして２〜３００万円程度なら比較的簡単に変わってしまうので恐ろしい。それで四年程働けば預金口座の額が5００万ほど変わることになる。（カリフォルニアでは大体税金で５０％取られる計算になる。）

Google に応募

さて、そんなこともあって、日曜日の夜、手持ち無沙汰から Google のジョブリスティングを覗いてみた。シリコンバレー界隈でソフトウェアエンジニアの仕事を検索すると、常に数百件の募集があるのに驚かされる。

機械学習、AI などで色々見て回った後、結局どれもしっくりくるものはなかったので、とりあえず、Google Brain の Research Software Engineer に出してみた。「とりあえず」で出すようなところでは無いのだが、どこもあまり希望を見出せなかったし、日曜日の夜「何かした」感をもってさっさと寝たかったのでやっつけの応募になった。

Google からの返信は意外と早く†、週が明けた月曜日にメールが届いた。メールをくれたこの女性、ジョアンナは署名欄で自分の役職を Machine Learning Sourcer†† としていた。メールには電話で僕のバックグラウンドの詳しい話を聞きたい旨と、彼女の Google Calendar へのリンクが貼ってあった。カレンダーには電話を受けられる時間の枠が候補として表示されていて、この枠のうち自分に都合のよいものをクリックして、名前と電話番号を入力すると電話の予定が確定となる仕組みだった。なるほど、多くの人とのやり取りを効率よく捌くために、アポイントメントなどの処理を自動化しているわけだ。

僕は彼女との電話を水曜日に設定した。ちょうど Apple のジェームズが設定したマネージャーとの電話が午前に入っていたので、その日の午後に設定して、この日は会社に出社せずに家から仕事をすることにした。これで煩わされずに電話ができるだろう。

さて。水曜日は緊張の日になる。

第五話へ続く。

脚注

スクリーニング

Google のような年間数万件にのぼる応募がある会社の場合、実際にはリクルーターから返信が来る確率はかなり低い。おそらく Google のことだから本当に見込みのない応募者は自動で弾いているだろうが、リクルーターも日々何十件という履歴書に目を通さなければならないので、各履歴書にかける時間は数秒、何か目を惹くキーワードを見つけるかどうかになる。この辺はこのトピックで著名な Gayle McDowell のページに解説がある。僕のレジュメはここまで簡潔ではないけれど、それでもとりあえずリクルーターには声をかけてもらえる。僕の予想ではその理由は二つ。一つ目は僕が機械学習の経験を持っていること。二つ目は僕が既に何度か（日本でのインターンの面接、ベイエリアでフルタイムの面接）受けていて、僕のメールアドレスが内部システムに登録されているからだろう。Google は生涯で三度まで面接が受けられて、再挑戦者はそれなりに新規挑戦者よりも連絡がもらえる確率が高いとされる。ちなみに、全くの新規で挑戦する場合は、知り合いなどを通じて内部推薦でリクルーターのスクリーニングをバイパスしないとまず連絡は来ないとも言われている。もし、これを読んでいる日本人の方で Google 本社で働きたい人は、まず Google Japan で働いている人と繋がりを持つことがスタート地点になるだろう。最近は就労ビザの取得も難しくなってきたので、Google Japan で働いて、本社転勤が現実的かと思われる。国際的に認知されている業績があればまた別だが。

Sourcer

Wikipedia によると Sourcer とは採用活動のうち、候補者を見つけ出し声をかける人のことだそうだ。

時勢

2019-07-13T15:31:56+09:00

>> 連載トップ > 前回のお話

二社目

Apple のリクルーターから初めて連絡をもらった二日後、Amazon のリクルーターからメッセージが来た。

「Amazon Alexa のチームが対話プラットフォームのエンジニアを探していますが、話を聞きませんか？」

Apple の Siri に Amazon の Alexa と立て続けにお誘いが来たのは時代の流れだろうか。この流れに乗ることができれば、何か面白いことに出会えるかもしれない。そう思って僕は二つ返事で電話の予定を入れた。

Apple のリクルーターとの短い電話があった数日後、僕は再びオフィス近くのスターバックスにやって来た。テーブル席が空いてなかったので、僕はドリンク提供カウンターのすぐ横の席に腰掛けた。すぐ隣で店員と客がやりとりをしているので、少し落ち着かなかった。電話は予定より10分遅れてかかって来た。

「タロー、ハーイ、Amazon リクルーターのアマンダです。お、遅れてごめんなさい、まだ時間は大丈夫？」

アマンダは少し疲れた声で、切羽詰まった様子だった。

「ハイ、アマンダ。大丈夫ですよ。」

「よかった。それじゃあ、まず、あなたのことについて聞かせてもらえる？」

「ええ、いいですよ。」

今度の会話は予期していた流れを辿った。僕は用意していたノートを見ながら話を始めた。

「僕は今、SF ベイエリアにあるスタートアップで働いています。このスタートアップは機械学習・ディープラーニングを使った会話データの処理サービスを行っていて、ビジネス向けに API を提供しています。

僕はその中で、データ処理のパイプライン周りを担当しています。顧客から集まるデータをデータセットにまとめるわけですね。それをチームのサイエンティストが利用して新しいモデルの訓練に使うわけです。

パイプライン自体はバックエンドなのですが、設計段階ではデータを提供してくれるパートナーとのすり合わせが必要になるので、ここら辺のコミュニケーションも行っています。

他にもこのデータを処理する際にデータの拡張という作業を行うのですが、このための内部ソフトウェアの開発も行っています。

それに加えて、僕は日本語が第一言語なので、日本語に関しては訓練されたモデルの評価を行ったり、僕自身がモデルを訓練したりしています。

サイエンティストとエンジニアの間を行ったり来たりすることが多い立場ですね。」

「なるほど。日常使いではどのような技術を使ってますか？」

「メインは Python になります。TensorFlow や PyTorch といった機械学習パッケージを使う場合や、API リクエストを実行する場合、あとは、Bash スクリプトをラッピングしてインターフェースを綺麗にする場合などが多いですね。あとはたまに C++ を使います。Amazon は Java と聞いてますけど、Java に関しては昔触った経験があるので、業務で使えるようになるのにそんなに時間はかからないと思います。」

「なるほど。どうして新しい仕事を探しているのですか？」

「この業界はここ数年で大きく変わっています。基本的な音声認識の精度はもはや向上の余地がないレベルになり、自然言語処理技術の向上によって、業界の注目は、これらの技術を基礎にしたアプリケーションの構築に向いています。今回そのような機会をもとに僕もキャリアのフォーカスをそちらにシフトしたいと思ったからです。」

この理由は後付けだった。リクルーターと何を話そうか考える中で、オフィスで聞く話や、ニュースで聞く動向、今回の案件の内容を組み合わせた内容だった。後々エンジニアと話をするには弱い内容だが、リクルーターと話すにはこれで十分だった。

「わかりました。では Alexa の話をしますね。今私は Palo Alto にある Amazon Alexa のチームに加わるエンジニアを探しています。Alexa はご存知ですか？」

「ええ。ただ、持ってはいないですけどね。はは。」

「Alexa にはたくさんのサブコンポーネントがあるんですけど、対話型インターフェースと言語理解が重要になるわけで、自然言語処理に携われる方を探しているんです。興味ありましか？」

「面白そうですね。ぜひ次のステップの話を聞かせてください。」

「分かりました。次のステップはコーディングテストになります。URL を送りますので所定の期限までに受けてもらえますか？」

「分かりました。ちょっと今週は忙しいので来週末まで待ってもらってもいいですか？」

「いいですよ、では都合がつきましたら連絡してください。」

「分かりました。ありがとうございます。」

電話を切ってから、僕は今後の流れを考えていた。ジェームズが繋いでくる Apple のマネージャーとの電話があるから、それに集中しよう。そして、時間を見つけてコーディングテストの練習をしなければならない。忙しくなりそうだ。

第四話へ続く。

はじまり

2019-07-01T05:10:57+09:00

>> 連載トップへ > 第一話

はじまり

２月の初め、件の Apple のリクルーターとの電話の為に、僕はお昼休みを使って会社の近くのスターバックスにやってきた。当然のことながら、就職活動は会社の同僚には隠し通さなければならないので、全て秘密裏に行わなければならない。大きな会社ならば会議室を予約してプライベートを確保できるかもしれないが、僕の会社は従業員が１０人もいない小さなオフィスなのでそれは叶わなかった。カフェラテとサンドイッチを注文して席に着き、プリントアウトしておいた自分の履歴書に目を通した。今にして思えば、同僚が早めに昼食を済まして食後のコーヒーに来る場合を考えれば、これはとてもリスキーだった。

典型的なリクルーターとの会話では、まず初めにリクルーターが候補者の詳細を尋ねて来る。一例を挙げると以下のようになる。

普段どのような業務に従事しいているのか。
- 会社はどのようなことをやっていて
- その中で、自分はどのようなことをやっているのか
  - どのような技術を利用しているのか
    - プログラミング言語
    - ソフトウェアスタック
  - どのような経験をしているのか
    - ソフトウェアの実装
    - ソリューションのアーキテクト
    - システムのデザイン
    - ジュニアメンバーのメンター
    - マネジメント
    - カスタマーサポート等
次の職に何を求めいているのか
- プロダクト
- 技術
  - ソフトウェア
  - 言語
  - スケール
- 経験
  - 開発
  - デザイン
  - マネジメント
- （オプション）
  - 待遇
  - 基本年収
  - ストック / RSU

年収や待遇に関することは面接が最終段階に進むあたりで聞かれることが多いが、予算が厳しい（小さな）会社では最初に聞いてくることもある。†

この時は基本的にこちらが一方的に話すことになるので、事前にリクルーターに共有してある履歴書の内容を踏まえながら、一本のストーリーを組み立てて、詳細を肉付けしておかなければならない。また、リクルーター以外の人（マネージャーや、配属先チームのメンバー等）と話すときも大体は同じようなことをはじめに聞かれるので、電話が始まる前に自分のレジュメを見ながらこれらの要点を確認しておくと心の準備も整うものだ。

これに答え終わると、今度はリクルーターが自分の持っている案件の話をする。リクルーターが自社の企業の為に人を探している場合は大抵すでに案件を持っていてその中身をここで教えてくれる。リクルーターが人材紹介会社のエージェントの場合はここから案件の選定が始まる。彼らがどのような会社からの案件を持っていて、その内のどれならよく適合しそうかをここで相談する。とは言え、どちらの場合にしてもリクルーターは技術職ではないので、案件の中身はそれほど具体的ではない。大きな会社の場合は雇用のプロセスは数ヶ月かかるので、あまり細かいことを先に決めることもできないと言う事情もあるだろう。

電話で初めての人と話すのは久しぶりのことだったので、僕は緊張していた。頭ではこの会話はプロセスをスタートするためのものであって、直接合否を決定するものではないと分かっていても、リラックスして電話を待つと言うのは難しかった。

予定の時刻になると電話が鳴った。

「もしもし、タローです。」

「やあタロー、Apple のジェームズだ。今 Siri 関連の言語処理チームが機械学習のエンジニアを探していてね、興味あるかな？」

「ええ。」

「じゃあ、追ってマネージャーと繋ぐよ。次の連絡を待ってて。」

そういって、ジェームズとの電話はすぐに終わってしまった。僕はあっけにとられた。ジェームズは僕について質問することもなかったし、僕も積極的に話すこともなかった。肩透かしを食らったようでもあったけれど、特に問題もなかったので気にしないことにした。食べかけのサンドイッチを終わらせると僕はスターバックスを後にした。

第三話へ続く。

脚注

年収の話

ちなみにカリフォルニアを始めとした幾つかの州ではリクルーターが現在の年収を聞くことは違法になっている。これは給与は仕事に見合った形で決定されるべきで、従業員のこれまでの給与を元に給与を決定することは不公平であるという理念に基づいていて、同じ職に就く人々の間で所得の格差、特に女性の男性との格差を是正するための働きかけとなっている。

きっかけ・シリコンバレーの雇用事情

2019-06-24T11:10:47+09:00

>> 連載トップへ

きっかけ

「音声アシスタント向けの自然言語処理チームで働きませんか？」

LinkedIn のメッセージボックスに Apple のリクルーターからメールが来たのは年が明けてまもない頃だった。その頃僕はシリコンバレーの小さな会社で働いていて、生産性の上がらないマネジメントスタイルに日々ストレスを感じていた。

「まあ、この先ここで働き続けて自分が幸せになれるとはとても思えないし、これはいい転機になるかもしれない。」

そう思って僕は早速返事を認めた。

「連絡ありがとうございます。面白そうな話ですね。もう少し詳しくお聞かせ願いますか？」

斯くして、リクルーターからのメッセージに後押しされる形で、僕は転職活動を始めた。

後になって、日本では GAFA† と呼ばれる四大テック企業全てとやりとりをすることになるとはまったく想像もしていなかった。

シリコンバレーの雇用事情

ここでシリコンバレー或いはアメリカの就職 / 採用活動事情をご存知ない方のために少し補足しておこう。

終身雇用制度が廃れて久しいアメリカでは人材が常時流動している。それはつまり、転職活動が年中盛ん††であり、それとともに企業の採用活動も年中盛んであるということである。企業の各部門は、新しい予算を獲得すると求人情報を更新し、人事部はそれに見合いそうな人材を探してコンタクトをとる。

LinkedIn は職業や雇用に関連する繋がりを提供する SNS で、リクルーターにとっては候補者を探す恰好の場所になっている。求職中であろうとそうでなくとも、LinkedIn にアカウントを持っていて、自身の職歴や技能を公開していると、このようなリクルーターからのメッセージがよく届くのだ。中には明らかに不特定多数に送信しているものや、聞いたこともない会社から送られてくるものなど、到底返信するに至らないようなものもあるけれど、稀に誰もが知っている大企業の、とても魅力的な案件が送られてくることもある。僕は実務経験数年の駆け出しエンジニアだけれど、リクルーターはなるべく多くの人に声をかけようとするので、僕のような新米にも機会はやってくるのだ。

リクルーターとメッセージのやりとりが始まると、次のステップは彼らと電話で会話することになる。ここでリクルーターは候補者がどのような技能を有していて、普段どのような業務に従事して、次の転職の機会に何を求めているのか（キャリアパスや携わりたい技術など）を聞き取り調査する。そして、自分がどのような求人情報を持っているかを説明する。ここでお互いの興味が一致すれば、リクルーターは候補者を面接のステップに進めるための手続きをする。

面接の流れは会社によって異なっているが、GAFA の場合、大枠は同じだ。まず、電話面接がある。これは候補者の基本的なコーディング技量を測るためで、面接官が課すプログラミングの課題を候補者がオンラインの共有テキストエディターに実装していくというスタイルだ。この時はコードを実際に走らせることもあるが、しないこともある。これは必ずしも正確なコードを書くことが目的ではなく、出された課題に対する分析能力、解答を提案する能力、それを面接官に伝えフィードバックを元に議論を展開するコミュニケーション能力を見るのが目的だからである。

正しいコードを要求する場合の課題は面接官を必要としない自己完結型のサービスを使う場合が多い。今回の僕の就職活動では Amazon がこれに該当した。この場合は課題の URL がリクルーターから送られてきて、自分の都合の良い時間にそれにアクセスして課題を解き、提出するというものだ。Amazon では電話面接の前にこれをこなす必要があった。

電話面接を突破すると、次は実施に会社に赴いての面接になる。オンサイトインタビューとよばれる。オンサイトインタビューはほぼ一日消費する。４５分から１時間の面接を最低５回、多い場合は７回行う。これらは３〜４種類の面接から構成される。

コーディング
人間性（Behavioral Interview, Leadership Interview などと呼ばれる。）
システムデザイン
専門性

それそれの面接官からのフィードバックはリクルーターに返され、リクルーターはこれを所定の手続きに回す。また、ここで見通しが良さそうな候補者で、まだ配属先の見当がついていない場合はチームマッチングが始まる。良いマッチングがあれば、それもフィードバックに加えられる。このフィードバックから合否の決定までのプロセスは会社によって違うとされる。ネット上に散見される情報やリクルーターとのやりとりから得られた情報をまとめると以下のようになる。

Google では採用委員会 (Hiring Committee, HC) と呼ばれる人々が独立した意思決定を下す。マッチングで決定した配属先のマネージャーは意思決定には関わることが出来ず、マネージャーが採用したいと思っても HC がノーと言うと不採用になる。もちろんフィードバックを提出した面接官はこのプロセスには関わらない。

Amazon ではオンサイトインタビューを行ったその日に、面接を行なった人々が集まって合否を決定する。ここでは各々の印象と他の面接官の意見を参考に、多数決投票が行われる。ただし投票には例外がある。面接官の中には特別な拒否権を持った人がいて、この人物がノーと言うと、残りの投票の結果に関わらず、不採用となる。この面接官は Bar Raiser と呼ばれる。恐ろしい名前だ。「Amazon に採用される人は常に現在のチームよりも良い仕事をする人でなければならない」という Amazon の理念の一つを実装するためにこのような特別な権限を与えられている。

Facebook のプロセスは Google に似ている。一般的に、Facebook ではチームのマッチングは採用前には行われない。採用後に Bootcamp という研修期間を経てチームをマッチングするからだ。しかし、もしチームが先に決まっている場合はチームのマネージャーの承諾も採用決定の一因となる。

Apple は他の３社と異なり、社内共通の採用プロセスがないとされる。各チームが独立して採用活動を行なっており、最終決定はマネージャーによって行われる。

以上がアメリカ（シリコンバレー）のテック企業の大まかな採用プロセスである。

今僕は、この転職活動を終えて、一連の出来事を思い出しながらこれを書いている。様々な人と電話や実際に会って話をしたが、最も強く思ったことは就職・採用活動はとても脆いプロセスだということだった。

LinkedIn や企業側の採用プロセス管理ツールやらコーディング課題のためのプラットフォームやら、どんなに優れたシステムで就職・採用活動を行いやすくしたとしても、究極的には会話という最も基本的な人と人とのコミュニケーションを介してプロセスが進んでいく。

また、このコミュニケーションも、同じ人ばかりではなく、プロセスが進むにつれて担当者が別の人に変わったり、マッチングのプロセスで様々なチームの人と話をしたり、そのどれもが失敗できない緊張の連続である。その上、多くの案件を同時にこなしていると必ずどこかで連絡が途絶えてしまう。舞い込んだ案件に最初のうちは丁寧に返信をしていたが、自分の忙しさとストレスのあまり途中で急に返信するのを辞めてしまった案件もあるし、逆にリクルーターが連絡するのを辞めてしまった案件もあった。職探しというプロセスはとても不安定なコミュニケーションを辿りながら、なんとか自分を認めさせるプロセスなのだ。

第二話へ続く。

脚注

GAFA

僕の経験では、シリコンバレーでソフトウェアエンジニアとして働いていて GAFA という言葉を使うことはまずない。業界そのものを分析している人は使うかもしれないけれど、ソフトウェアエンジニアとして働いていると、技術や動向なんかに関しては各社の違いの話をするのが主なので、一緒くたにして話すことはまずない。日本からやってきた人が「GAFA が云々」と言って、相手が「がーふぁって何？」と聞き返されるのを何度か見たことがある。ちなみに一度リクルーターからの案件で Subsidary of FAANG と言うのを見たことがある。 FAANG ってなんだ？と思って調べてそれが GAFA + Netflix だと理解するのに少し時間がかかった。多分アメリカではこちらの方が使われるように思える。どっちにせよ会話で使われることはない気がするし、ちょっと不親切な略語かなと個人的に思う。。結局 FAANG 傘下のとある会社という案件はスルーした。

雇用のタイミング

もちろん全ての企業活動には活動予算がつきものなので、採用活動の勢いは予算の具合によって変化する。この記事によると、年明けの予算が確定したタイミングが最も活発になり、（そう言われれば初めての仕事の時は、１月２日にメールがきたなぁ。）、従業員が休みを取る夏に一旦落ち着き、予算を使い切った頃の冬に終了するということだそうだ。確かに、昔とある大企業では１２月３日が年内の最終雇い始めの日で、その日をもってHR は正式に年内の仕事納めというケースを聞いたことがある。スタートアップなどは新たにファンドレイジングで予算を獲得するタイミングが最も採用活動が激しくなるということになる。ちなみに採用通知が来るのは火曜日が統計的に多いという話もある。へー。