ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

日本→シンガポール→ベルリンへと流れ着いたソフトウェアエンジニアのブログ

ITエンジニアの海外転職を成功させるちょっとしたテクニック集

移転しました。

ITエンジニアが英語圏の会社へ海外転職する際、それを成功に導くちょっとしたテクニック集。これは<成功への王道!>とかではない。あくまでもちょっとしたテクニックになる。

こういうのが意外と重要。シンガポールからヨーロッパのIT企業に転職することになった。オファーをもらうまでの過程ではっきりしたのはシンガポール在住日本人の私と比較すると「EU圏内に住むヨーロッパ人」の方がかなり有利であることだった。

それは当然だ。シンガポールのITスタートアップで働いている時も人材募集をすれば世界各国から履歴書が送られてきたが、基本的に応募者がシンガポール在住者の方がなにかと話が早いしオファーも速攻で出しやすかった。応募者が国内在住者だと「じゃあ**月**日にオフィスに来て技術面談をしましょう」「それでは*月*日から一緒に働いてもらえますか?」と、こうした会話がカンタンにできた。

もしこれが国外在住者だとこうはいかない。さらにヨーロッパの会社にEU圏外の応募者が応募するとビザや在住資格の取得、住居の手配、家族がいればその他の手続きが伴ってしまうため、もうひとことで言えば「ただ入社してくるだけでも面倒くさい人」になってしまう。

ほぼ同じ技術レベルのEU圏内の候補者が居れば当然そちらを採るだろう。したがって日本人として海外の企業に転職応募するなら、その面倒な手続き分を相殺できるぐらいには採用するメリットを示さなければならない。「日本人で入社手続きとかちょっと面倒だけど、その代わり**がありますよ」と。

凄腕スーパーエンジニアなら、**に相当する部分が「スーパーな技術」のひとことでOkなのだろう。だが私は残念ながら超スーパーエンジニアではない。この記事をお読みの海外転職をお考えの方でかつ超スーパーエンジニアでなければ、これから述べる「ちょっとしたテクニック」に気を使った方がいい。

もちろん技術を高めるべきことは言うまでもない。ただ技術に関しては恒常的に気にかけておくべきことであって、「さー転職するぞ」となって今さら「技術力を高めよう」となっても遅い。一夜にしてなんとかなる技術なんて大したことないし。その代わりちょっとしたテクニックがあるのと無いのとでは、転職の成功確率がずいぶん違う。

これを実感したのはシンガポールのスタートアップで働いている際に採用担当者として多くの応募者を書類選考して面接官として技術面談に対応した経験から。「なんでこの応募者はこんなこと言うんだろ?」「あともうちょっとなんとかならんのかな?」という感じで、少しのことで採用を見送った経験が山ほどある。それらの「あとちょっと」というボーダーライン上にすごい数の転職希望者が立っていたのだ。そのラインから採用側に転がるのも不採用側に転がるのも、ちょっとしたことの連続だった。

エンジニアとして技術力に変化はなくても、それらの「ちょっとしたこと」を重ねることで転職成功確率が格段に上げることができる。

応募書類は会社のノリに合わせて、絶対に他の候補者が使わない言葉を入れてしまう

私が転職先として狙う会社はだいたいコンシューマー向けのウェブサービスとアプリを提供している会社だ。オフィスの雰囲気もノリもアメリカ風のよくあるITスタートアップだ。大企業的な文化を忌み嫌うカルチャーであることは応募する前からウェブサイトから感じ取れる。そういう会社のノリに合わせるのは大切。

どこでも転職の際に出す応募書類にはヘッドラインやレジュメの題名を書く。ググったらヘッドラインの例が出ていて、それらはだいたいこんな感じ。

  • 10 years of experience in full life cycle of software development
  • Certified in C+, ASP and LAN Administration
  • Proven ability to manage online marketing campaigns effectively

これらは全てググってヒットしたヘッドライン例。転職コンサルタントの先生が書いたのだろう。まー完結で1行読んだだけで、どんな候補者なのかだいたいの想像はつく。しかし採用側の経験からこれと似たようなヘッドラインの書類を今まで嫌と言うほど見てきた。悪くはないが差別化はできない。

私が書いたヘッドラインにはSAMURAI(サムライ)とかNINJYA(忍者)というEU圏内の候補者達が入れなさそうな言葉を入れた。例えばSAMURAI Software Engineer with ...とか。

こうしておけば書類を見た採用担当のエンジニア達が「あのサムライとか書いてる日本人、一回面談に呼んでみない?」「あーあのサムライな。いいよ」という会話が成立すると思う。

だいたいコンシューマー向けのサービスを提供する海外の会社で働くエンジニアが真面目くさって「御社に入社させていただいた際にわ~」とかやってもノリが合わない。賭けてもいいが、「忍者」や「サムライ」と書いたぐらいで書類選考で落としてくるノリの悪いITスタートアップは無い。あったとしたら政府系や大企業、銀行などのお硬い業種だけだ。それと国ごとの印象というのがあって、なんの根拠も無いのだが「イタリア人=ナンパ師」「フランス人=オシャレ」とかなっている。残念なことに「日本人=真面目すぎておもろない」の印象を持たれてしまっているようだ。コンシューマー向けのノリノリなITスタートアップに応募する際にはその「日本人=真面目」のデメリット部分を翻すために多少はノリのいい用語を使ってもいいのだ。

要は会社のノリに合わせて転職コンサルタントの先生が書かない用語、EU圏内の候補者が書かない用語をヘッドラインに散りばめて差別化を図るべし、と。

パフォーマンス・チューニングのアピールはいつでも伝家の宝刀

「この会社は条件も仕事の内容もバッチリだ」となった第一候補の会社には必ず「私が入社したらパフォーマンス・チューニングをしてやるぜ!」と書いた。なぜならパフォーマンス・チューニングは伝家の宝刀だからだ。

「もしアンタの会社に私が入ったら。。。」に続く言葉は慎重に選ばなければならない。「生産性を上げてやる」と言ってもなんか曖昧で生産性をどう定義するのか、から始める必要がある。「バグを全部キレイにしてやる」と言ってもコードが公開されてないから、バグってどれ?現在GitHubにIssueがいくつあるのか知らんだろ?となってしまう。

その点パフォーマンス・チューニングに関しては万能だ。まず外から誰でもそのパフォーマンスを測ることができる。その会社の提供しているウェブサービスなり公開しているAPIをめがけてパフォーマンス測定をする。もしヨーロッパの会社やサーバを使っていたら、あえてアジアからのアクセスにして、その会社があまり力を入れてなさそうな箇所をめがけて測定する。だいたい2,3個のいまいちレスポンスの悪い箇所が見つかる。そこで応募書類に「私が測定したところ、御社の**のレスポンスはアジアからのアクセスだと3500msかかってますな。私が入ったらそれを200ms以下にしてやるぜ!」と書けばOk。

どんな会社でもパフォーマンス・チューニングの必要性は分かってはいるけど後回しにしてしまいがちなことになっている。バグの撲滅の方に優先順位を高く置いてしまうのだ。

バグ=正しく動作しない=>治す必要がある(優先順位高い)
レスポンスの悪さ=正しく動作するが遅い=>パフォーマンス・チューニングが必要(でも優先順位低い)

となりがち。それなりにキャリアのある技術者でもパフォーマンス・チューニングの経験が乏しい人も多く居る。なので私は現職においても常にパフォーマンス・チューニングの必要性を訴え、自身でシステムをチューニングしてナンmsにこだわっていた。個人的にも遅いもっさりしたウェブサービスやアプリが大嫌いなのもある。サクサク動いてなんぼのアプリだと思っている。ただ一番の理由は「高度なパフォーマンス・チューニングができると転職にとっても有利であること」を知っていたからだ。

こんなにカンタンに外からダメな箇所を指摘できて「入ればオレ様が改善してやるぜ」と主張できる項目は他には無いからだ。
普段から注力していたパフォーマンス・チューニングなので面談の際に話題に出てきても、こちらとしてはいくらでも話す材料はあった。

技術面談でとびきりトリッキーな問題を出してきたら言うこと

技術面談においてとにかく変な問題を出してくる奴が居る。私が出会った問題でちょっと変だったのは、すごい複雑なRubyのコードを画面に出して、この出力結果を言い当ててみろ、というのだった。
includeしてextendして、また破壊メソッド、参照渡し、値渡しが組み合わさっていて、1行1行考えていかないとその結果が言い当てられない問題だった。で、結果として私の答えは間違いだった。なんとなくどこかの行で間違っていそうな予感がしていたから、1行1行どうなるかの考えを説明していたので、各要素に対してまったく分かってない奴ではないことは伝えられたと思う。それでも心の中では「なんじゃこの微妙な問題。。。」の気持ちがふつふつとあった。

そういう変な問題を出して来た奴に言うことがある。あからさまに「問題が変なんだよ!」とか言うと角が立つので、そこはあくまで丁寧に接するべき。物腰柔らかにいつもこう言っている。
「難しい問題だねー。ところで君の会社でのコーディングスタイルってこんな感じなの?だいたいこういう要素を使ってコード書いたりしてるの?」
これをあくまで真面目に本当に興味ありそうに聞く。そしてその答えはきまって「No」だ。すると、たたみかけて「え?今『No』って言った?あーそう、こういう書き方はしないのか。じゃあなんて問題に出したんだろ?**の知識を測りたかったとか?」

と釘を挿しておけばOk。つまり変な問題を出す人には「それは変な問題であって、実際の業務には役立つ訳じゃない。本来なら**の知識を問う問題にすべき」との認識をもってもらう。
往々にして答えが間違っていたり、解けなかったりするが必ずしも応募者のスキルが足らない訳でもない。そもそも問題が悪いことが多いのだ。そういうのに出会ったら「君の会社でのコーディングスタイルってこんな感じなの?」が有効。これを言わずに「分からなかった。すみません。」という終わり方では、まるでこちらの技術力の低さが原因という印象になってしまう。

以上、ITエンジニアが海外転職を成功させるためのちょっとしたテクニックでした。

全部読んで「ちょこっとしたことばっかりだな」と思われた方へ。趣旨としてはちょこっとしたことの積み重ねが大事ということでして、本来はご自身の持っている技術が最重要なのは言うまでもなく、ということです。
 
 
tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com