海外のスタートアップのコーディング面接を受ける機会があったので、やっておけばよかったなーと思うことを忘れないようにメモっておく。
なお、まだ受かったかどうかの連絡は来ていないので、参考程度にして頂ければと思う。合否は追記したい。
(一応、 Qiita の方針に従うために、 React の説明入れた)
前提
- ベルリンのスタートアップ
- React のちょっとした問題を出された
- この会社では1次面接は自己紹介で、2次面接がコーディング面接だった
- appear.in + Codepen で面接した
- 所要時間 1時間20分 (多分もっと早く終るはずだったのだろう)
教訓
事前準備
- まず最初に、自分のレベルを知る
- 受験で、模試や過去問を解くのに近い
- アルゴリズム系は、 https://leetcode.com で練習できる
- 本番っぽい面接は、 http://pramp.com/ で実練習できるので、時間あれば是非やっておく
- これめっちゃ良かった、教えてくれた方に感謝☆
- 独特の焦る感じを体験できる
- ここでインド人のめっちゃ優秀な人と当たって、危機感を感じた
- もっと早くやっておけば良かった
- コーディング面接は、事前の面談などで、できるだけどんな内容が出るのかを聞いておく
- できるだけ対面で聞いたほうが良い
- 後で聞くと、対策しようとしているんじゃないかと思われる
- 軽い感じで、さらっと聞きたい
- 直接聞きづらい場合は、事前にその会社が使っているライブラリ等を聞いておいて、徹底的に使い倒しておく
- 今回は「
recompose
使って書いて」って言われて、ちょっとしか使ったことないからその場で「ドキュメント読むよ」って言ってドキュメント読んだ- 使ったこと無いライブラリが出ても評価は下がらないと思うが、心理的な負担になる
- その場で読むと焦るので理解が遅くなる
- 網羅的に勉強しようとして、下記のような(面接のためには)無駄な努力してしまった。まあ勉強にはなったけど
- ソートのアルゴリズム
- 二分岐探索
- 計算量
- Google の入社問題を解く
- 今まで受けてきたコーディング面接では、下記パターンに分類できそう
- アルゴリズム系の問題。技術系の会社に多そう。
- JavaScript の知識。
[] === []
がfalse
になるとか - React のコンポーネントを書くなど、実務に近いもの。 Web サービス企業に多そう(今回のはこれ)
- できるだけ対面で聞いたほうが良い
- CTOや面接官の考えを知る
- その人が考えていることや大事にしていることを予め理解しておく
- ブログなどを徹底的に読む
- 結局、人なので、気に入られるかどうかが大事
- できれば同じ言葉で話せると良い
- 今回で言えば、 Generic という言葉が、「汎用的な」という意味で出てきた
- Generic と言われて、反射的に
<T>
が出てきて混乱した - 多分、事前に知っておけば混乱しなかった
- 曖昧な点、知識の穴は事前に潰しておく
- たまに使うけどいっつもコピペしている、みたいなやつは、出てきた時に怖い
- 今回で言えば、下記が、どうやればよいかは分かるが、若干曖昧でググった
event.preventDefault
event.target.name
- 一応、今回 JS/React で下記を復習して潰し、英語で説明できるようにしておいた
-
type
とinterface
の違い -
componentWill*
系はなんで非推奨になったのか、代わりに何を使えばよいのか -
Context API
の実装。実務で使ったこと無いから、自分でも書いておく。ドキュメント読んだだけでは穴になる可能性ある -
this.setState(state => ...)
とthis.setState({ ... })
の違い -
HOC
,Render Props
,composition
など、 React でよく使われるパターンについて
-
- 海外のエンジニアの Podcasts を聞いておくと良いかも
- 本場の話し方、言葉の使い方など雰囲気が分かる
- 理解できなくても、精神的に慣れる
- ずっとこれ聞いてた https://dev.to/hanselminutes/alcohol-and-the-tech-industry-with-victor-yocco
当日
- Codepen で同時編集していたが、一回バグって同期できなくなった
- 食い違いが発生した
- 俺の画面では動いているけど、そっちでは動いてないの?ってなった
- 食い違ったら画面シェアリングするのが吉
- 使っている面接ツール、今回で言えば appear.in の拡張機能は入れておく
- 画面共有できるようにする
- その場で拡張機能入れていると、間が持たない
- Codepen とかは、 Vim バインディング等があるなら入れておきたい
- 細かい動作に気を取られて、時間をロスするのは勿体無い
- 思わぬタイポになることも。 Mac ユーザーだが
C-k
で「行末まで削除」ができなくて手間取る
- コーディングよりも、コミュニケーションの方が難しい
- コーディングしながら英語でコミュニケーションするなど、超絶技巧に思える
- 分からない時は聞く
- 曖昧な状態で進むのは恐ろしい、精神的にもきついので方針を明確にしたい
- 黙るのは良くない、独り言でもいいから話しながら書く
- 日本語を忘れた方が良い
- 独り言で「あー」とか「えーと」「なんだっけなー」とか出ると、向こうには意味不明な言葉を話しているようにしか思えないので、印象が悪い
- 「日本語ならできるんだけどな」とか考えちゃうとつらい
- 100%目指すのは無理なので、80%の時点で意思表示をする。分かった風に言いたい。
- 「機能的には実装したが、変数名とか調整したい」
- 「このケースの場合には、おかしな挙動をする可能性がある」
- 「このロジックは共通化できるが、一旦動作確認して後で共通化する」
- 意図を確認してからコーディング始める
- 課題を出されてから、何も言わずに書き始めるのは、即 「No Hire」らしい
- 情報収集していたので、今回はかなり意識した
- ただ、「念の為確認する」と言わないと、ただ物分りの悪い人っぽくなる
- 参考: https://www.amazon.co.jp/exec/obidos/ASIN/4774176567/necojackarc-22/
- 諦めない心が大事
- 途中で「早く終わってくれよ」と思っても、最後まで諦めない
これだけ読むと全くできなかったみたいだ。笑