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
これらは全てググってヒットしたヘッドライン例。転職コンサルタントの先生が書いたのだろう。まー完結で１行読んだだけで、どんな候補者なのかだいたいの想像はつく。しかし採用側の経験からこれと似たようなヘッドラインの書類を今まで嫌と言うほど見てきた。悪くはないが差別化はできない。
私が書いたヘッドラインにはSAMURAI（サムライ）とかNINJYA（忍者）というEU圏内の候補者達が入れなさそうな言葉を入れた。例えばSAMURAI Software Engineer with ...とか。
こうしておけば書類を見た採用担当のエンジニア達が「あのサムライとか書いてる日本人、一回面談に呼んでみない？」「あーあのサムライな。いいよ」という会話が成立すると思う。
だいたいコンシューマー向けのサービスを提供する海外の会社で働くエンジニアが真面目くさって「御社に入社させていただいた際にわ～」とかやってもノリが合わない。賭けてもいいが、「忍者」や「サムライ」と書いたぐらいで書類選考で落としてくるノリの悪いITスタートアップは無い。あったとしたら政府系や大企業、銀行などのお硬い業種だけだ。それと国ごとの印象というのがあって、なんの根拠も無いのだが「イタリア人＝ナンパ師」「フランス人＝オシャレ」とかなっている。残念なことに「日本人＝真面目すぎておもろない」の印象を持たれてしまっているようだ。コンシューマー向けのノリノリなITスタートアップに応募する際にはその「日本人＝真面目」のデメリット部分を翻すために多少はノリのいい用語を使ってもいいのだ。
要は会社のノリに合わせて転職コンサルタントの先生が書かない用語、EU圏内の候補者が書かない用語をヘッドラインに散りばめて差別化を図るべし、と。
パフォーマンス・チューニングのアピールはいつでも伝家の宝刀
「この会社は条件も仕事の内容もバッチリだ」となった第一候補の会社には必ず「私が入社したらパフォーマンス・チューニングをしてやるぜ！」と書いた。なぜならパフォーマンス・チューニングは伝家の宝刀だからだ。
「もしアンタの会社に私が入ったら。。。」に続く言葉は慎重に選ばなければならない。「生産性を上げてやる」と言ってもなんか曖昧で生産性をどう定義するのか、から始める必要がある。「バグを全部キレイにしてやる」と言ってもコードが公開されてないから、バグってどれ？現在GitHubにIssueがいくつあるのか知らんだろ？となってしまう。
その点パフォーマンス・チューニングに関しては万能だ。まず外から誰でもそのパフォーマンスを測ることができる。その会社の提供しているウェブサービスなり公開しているAPIをめがけてパフォーマンス測定をする。もしヨーロッパの会社やサーバを使っていたら、あえてアジアからのアクセスにして、その会社があまり力を入れてなさそうな箇所をめがけて測定する。だいたい２，３個のいまいちレスポンスの悪い箇所が見つかる。そこで応募書類に「私が測定したところ、御社の＊＊のレスポンスはアジアからのアクセスだと3500msかかってますな。私が入ったらそれを200ms以下にしてやるぜ！」と書けばOk。
どんな会社でもパフォーマンス・チューニングの必要性は分かってはいるけど後回しにしてしまいがちなことになっている。バグの撲滅の方に優先順位を高く置いてしまうのだ。
バグ＝正しく動作しない＝＞治す必要がある（優先順位高い）
レスポンスの悪さ＝正しく動作するが遅い＝＞パフォーマンス・チューニングが必要（でも優先順位低い）
となりがち。それなりにキャリアのある技術者でもパフォーマンス・チューニングの経験が乏しい人も多く居る。なので私は現職においても常にパフォーマンス・チューニングの必要性を訴え、自身でシステムをチューニングしてナンmsにこだわっていた。個人的にも遅いもっさりしたウェブサービスやアプリが大嫌いなのもある。サクサク動いてなんぼのアプリだと思っている。ただ一番の理由は「高度なパフォーマンス・チューニングができると転職にとっても有利であること」を知っていたからだ。
こんなにカンタンに外からダメな箇所を指摘できて「入ればオレ様が改善してやるぜ」と主張できる項目は他には無いからだ。
普段から注力していたパフォーマンス・チューニングなので面談の際に話題に出てきても、こちらとしてはいくらでも話す材料はあった。
技術面談でとびきりトリッキーな問題を出してきたら言うこと
技術面談においてとにかく変な問題を出してくる奴が居る。私が出会った問題でちょっと変だったのは、すごい複雑なRubyのコードを画面に出して、この出力結果を言い当ててみろ、というのだった。
includeしてextendして、また破壊メソッド、参照渡し、値渡しが組み合わさっていて、１行１行考えていかないとその結果が言い当てられない問題だった。で、結果として私の答えは間違いだった。なんとなくどこかの行で間違っていそうな予感がしていたから、１行１行どうなるかの考えを説明していたので、各要素に対してまったく分かってない奴ではないことは伝えられたと思う。それでも心の中では「なんじゃこの微妙な問題。。。」の気持ちがふつふつとあった。
そういう変な問題を出して来た奴に言うことがある。あからさまに「問題が変なんだよ！」とか言うと角が立つので、そこはあくまで丁寧に接するべき。物腰柔らかにいつもこう言っている。
「難しい問題だねー。ところで君の会社でのコーディングスタイルってこんな感じなの？だいたいこういう要素を使ってコード書いたりしてるの？」
これをあくまで真面目に本当に興味ありそうに聞く。そしてその答えはきまって「No」だ。すると、たたみかけて「え？今『No』って言った？あーそう、こういう書き方はしないのか。じゃあなんて問題に出したんだろ？＊＊の知識を測りたかったとか？」
と釘を挿しておけばOk。つまり変な問題を出す人には「それは変な問題であって、実際の業務には役立つ訳じゃない。本来なら＊＊の知識を問う問題にすべき」との認識をもってもらう。
往々にして答えが間違っていたり、解けなかったりするが必ずしも応募者のスキルが足らない訳でもない。そもそも問題が悪いことが多いのだ。そういうのに出会ったら「君の会社でのコーディングスタイルってこんな感じなの？」が有効。これを言わずに「分からなかった。すみません。」という終わり方では、まるでこちらの技術力の低さが原因という印象になってしまう。
以上、ITエンジニアが海外転職を成功させるためのちょっとしたテクニックでした。
全部読んで「ちょこっとしたことばっかりだな」と思われた方へ。趣旨としてはちょこっとしたことの積み重ねが大事ということでして、本来はご自身の持っている技術が最重要なのは言うまでもなく、ということです。
tango-ruby.hatenablog.com
ITエンジニアの海外転職で出された技術問題をそのままここに貼り付ける - その１
エンジニアが海外転職をする際に必ず出されるのが技術問題で、それらは本当に玉石混交。いい問題もあれば、なんかしっくりこないクソ問題もある。私が現職で応募者に技術問題を出す際にはいつも「外部のネットに書いたり、人に問題の内容を教えたりしないでね」と一言付け加えている。ただ全ての会社がそんなこと言ってる訳でもない。特に注意が無かった会社の技術問題はちょっとぐらい外に出しても文句を言われる筋合いは無い、と解釈してここに少しずつさらすことにした。きっと日本から海外転職をお考えのエンジニアにとっては参考になると思う。
出題した会社：ロンドンのITスタートアップ
応募職の求める技術：Ruby、Rails、サーバーサイドのメンテナンス、その他いろいろ
問題の形式：画面を共有して応募者がコードを書く様子をモニタリングして、出題する。本問題に特に制限時間は無し。Google検索は不可。「なるべく考えてることを話しながら（英語）コード書いてね」とのことだった。
Exercise 1 - Ruby
In as few lines of code as possible, implement a class Person so that each instance of this class can have children and grandchildren (of that same class Person) - but not beyond grandchildren.
問題は単純。Personクラスを作って、そのPersonのインスタンス変数には子供（children）が何人か居て、さらに孫も何人か居るように設計してね、と。
こういうのを出された時に私が言う第一声はいつも同じ。「いい問題だねー」と。で、これは技術問題の最初の第一問としては素直にいい問題だと思う。難しすぎず、特定の技術を要することなく基本ができていればだいたい解ける問題だし。
向こうの担当者はモニター越しに応募者がコードをどのぐらいのスピードで書けるか様子を見ていて、イケてそうなら次にもう少し難しい問題を。ダメそうなら次にカンタンな問題に移るのだろう。
出題された時に私が書いたコード。今から読み返すと改善の余地もあるかもしれないが、まーこんなもんでもOkかな、と。
class Person attr_reader :children attr_reader :name def initialize(name, children: []) @name = name @children = children end def grand_children @children.flat_map(&:children) end end
実行する時
grand_child = Person.new('GrandChild A') grand_child2 = Person.new('GrandChild B') child = Person.new('Child A', children: [grand_child]) child2 = Person.new('Child B', children: [grand_child2]) parent = Person.new('Parent A', children: [child, child2]) p parent.name p parent.children.map(&:name) p parent.grand_children.map(&:name)
実行結果
$ ruby person.rb "Parent A" ["Child A", "Child B"] ["GrandChild A", "GrandChild B"]
この手の問題を突破するためのコツとしてはいくつかコード書きながら話すネタを用意しておくこと。それはどんな問題が出た際にも普遍的に話せるネタの方がいい。つまり冒頭で「英語で話ながらコード書いてね」と言われるのだが、それが案外むずかしい。本来なら考えていることをそのまま言えればいいのだが、あんまりいいアイデアが無い場合にそれをするとボロが出まくる。そうした事態を避けるには「オレってコード書く時はいっつもVimを使っててね。以前はEmacsも試したんだけどやっぱりVimだよね。だって。。。」と意味はなくても話せるネタがあればかなり心強い。
想像して欲しいのだが「あれ？この問題ムズい。どうしよう。。。」と考えてモニターを眺めて黙ってしまっている時の気まずさはかなりある。そういう状況はやたら焦るのだ。「なんか英語で言わなきゃ！でもどうやってコード書いたらいいのか分からん！でもなんか言わなきゃ！なんて言う？こんな時、英語でなんて言ったらいいんだー！！」とかなってたら本来書けるはずのコードすら書けなくなる。したがって話のネタは用意すべし。
どうでもいいことでも話してたら心が落ち着くし、少なくとも雰囲気は保てる。こうした技術面談は技術だけじゃなく「こいつと一緒に働くことになってもOkか、どうか」も見られている。ムスッと黙って何も言わない人になってしまうと「こいつ大丈夫かよ？」となってしまうので、話しネタは重要。
上記の問題を見て「こんなカンタンな問題、楽勝だわ」とお考えならば、それを国境を超えた向こうの会社の人にモニター越しにあなたのタイプをひとつひとつ眺められてかつ英語で話しながらコード書かされることはだいぶ雰囲気が違うんですよ、と言いたい。慣れたらどうってこと無いんだけど。
外国人の家に泊まる、結婚式に出席する、葬式に出席する、という変な目標
シンガポールに移住した当初に個人的に立てた目標があって、パソコン内のファイルに書いて残しておいた。もうすぐヨーロッパに引っ越す予定で、ファイルを整理していたら、その当初の目標書いたファイルが出てきてそれを確かめたら、なんかあまり意識せずにも全部達成されていた。その目標はこの３つ。
- 外国人のご家庭と家族ぐるみで仲良くなってその家でお泊りすること
- 外国人カップルの結婚式に出席すること
- 外国人のお葬式に出席すること
私は元々がそこまで社交的ではないし、友達も少ない方だ。友達なんてひとりも居ないシンガポールに突然に家族で引っ越してきてこの目標を立てた時はかなり達成困難なハードルの高い高い目標に思えた。だいたい３つめの目標なんてとても高度だ。どれだけ仲良くなった人であっても「今は元気かもしれないが、もしあんたの父親が急死したらその際にはぜひお葬式にお誘いいただきたく」なんて言える訳がない。普段から密な友人関係を築いておくこと以外に方法は無い。
しかし異様にコミュニケーション能力の高い妻のおかげもあって、３つともいつの間にか達成していた。外国の人の家に泊まることはもちろん、結婚式やお葬式などその人の人生の節目になる行事に参加して友人として家族と共に見届けるというのは貴重な体験だった。
別に誰かにこんな目標を立てることをおすすめする訳でもないし、この目標のおかげで人生救われました、などと言ってる訳でもない。ただ心のどこかでこういう感じの目標が達成できるような海外生活を送りたいと、考えていたことは確かだ。そうして何気に意識していることは、普段の生活に影響して自ずとそういう方向に行く。
シンガポールには５年も住んだことだし、いい人達にたくさん出会えて変な目標も達成したし、次はヨーロッパに行くことにしたけどそれはそれでええのかな、とも思った。ITスタートアップ業界の鼻息の荒い人達はもっとすげー目標を立てるのだろう。「＊＊ドルのバリエーションを獲得するゼ！」「世界を変える！」とか。
そんなんばっかりじゃなくて、個人の生活をちょっと豊かにするような目標があってもいいのかな、と。そしてヨーロッパに行っても同じ目標を立てることにした。
tango-ruby.hatenablog.com
