海外転職の面接で英語で聞かれるRubyとRailsの質問事例とそれを会話で対処する方法 - その１
エンジニアが海外転職する際に面接で英語で聞かれる基礎質問において、その解答と同じぐらい重要なのが「会話」になる。
前回「海外転職の面接の時に英語で聞かれるRubyとRailsの基礎質問を徹底マスターしておく方法」という記事を書いた際に自分で書いておいてなんだけど、「質問が単純すぎだな」と感じていた。だいたいの基礎質問はその候補者があれこれと解答を模索する際に見せてくれる会話の中で雰囲気とかスキルレベルを把握することが目的としてある。なので会話が無いと面談が成り立たない。
質問者「Aとはナニ？」
解答者「Aは○○です。」終わり
みたいなのでは、せっかくの転職面談なのに会話もクソもない。
ということで「Rubyの質問事例とそれを会話で対処する方法」を書いた。こっちの方がより海外転職の面談において実践的だと思う。実際この中から今の勤め先に応募された方に出した問題もあるし。
面談の形式やなぜ最初に基礎的な技術質問をするか、などの前提事項に関しては前回エントリーをご参照ください。
【問題１】
Given:
x = "hello"Explain the difference between:
x += " world"and
x.concat " world"
（解答例を読む前に声に出して英語で答えてみることをオススメします。頭の中で「分かっているぜ！オレ」と実際に「英語を声に出して説明すること」の差は自分の想像以上にあるものなので。）
【解答例１】
The += operator re-initializes the variable with a new value. Therefore, += is actually creating a new object and pointing the the old variable to that new object.
This is perhaps easier to understand if written as follows:
irb> x = "hello" => "hello" irb> x.object_id => 70301799032080 irb> x.concat " world" => "hello world" irb> x.object_id => 70301799032080 irb> x = "hello" => "hello" irb> x += " world" => "hello world" irb> x.object_id => 70301799055220The difference has implications for performance. Basically concat is faster than +=.
解答にあたってもし+=とconcatの動作の違いを知らなかったとしても問題ない。ある程度のレベルのエンジニアでも面談の場で「たまたま知らなかったこと」を聞かれることがあるからだ。「+=とconcatの違いが分かってないエンジニアは不合格だ！」なんて偏屈な面接官はきっと居ない。
仮にその違いが把握できてなかったとしても、この質問のポイントを指摘して「この質問はメモリ割り当てに関する内容だよね」と言えばいい。
すると面接官が「そうなんだよね。+=, concat, <<, と全部は似たようなやり方なんだけど、メモリ割り当てがどれがどれだったか覚えてる？」
と助け船を出してくれる。
「いやーそれは覚えてないなー」となってもその場にもしPCがあればirbでも起動して、上記のようにx.object_idで確かめてみればOk。もしPCが無かったとしても「どっちかがメモリー領域を（もしサイズがあれば）そのまま流用されて、他の一方が新しいメモリーが確保されてそこに保存される。確かめ方はx.object_idで。。。」と話して説明すればいい。
この辺りのもっと詳しい解説はこちら。
Rubyの文字列連結に関して知っておくべきこと - Qiita
仮に細かい仕様については知らなかったとしても、その会社で働くことになった場合には現場でちょっとググればいい。要は「メモリにも気配りできる技術レベルですよ」がアピールできればOk。
という感じに会話を進めていく訳です。その２につづく。
海外転職の面接で英語で聞かれるRubyとRailsの質問事例とそれを会話で対処する方法 - その２ - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
ちなみに「そんな細かい仕様のことなんて聞いて、その候補者のナニが分かるんだよ」とお考えの方へ。
私もかつては同じ感想をいだいていた。しかし面接官の立場で応募者を選考するようになると分かってきた。これ以外の方法で技術レベルを推し量る方法が無いのだ。もしこれをお読みの方でもっとスマートな方法で技術レベルが把握できるアイデアをお持ちの方がいれば、ぜひそれをサービス化していただきたい。
この分野で本当に有用なアイデアを実装すれば巨万の富が得られること間違いない。GitHubやらLinkedinやら誰もがこの問題解決に挑んでいるがイマイチ決定打が無く、どの会社も人材採用に苦労しているのだから。
海外転職の面接で英語で聞かれるRubyとRailsの質問事例とそれを会話で対処する方法 - その２
前回のつづき。
【問題２】
What will val1 and val2 equal after the code below is executed? Explain your answer.
val1 = true and false val2 = true && false
もしすぐに答えが分かったとしても「え？なんか同じに見えるなー。この問題ってキミが考えたの？おもしろいなー」とか言って面接官をムダに調子に乗らせるのもいい。
【解答例２】
Although these two statements might appear to be equivalent, they are not, due to the order of operations. Specifically, the `and` and `or` operators have lower precedence than the `=` operator, whereas the `&&` and `||` operators have higher precedence than the `=` operator, based on order of operations.
To help clarify this, here’s the same code, but employing parentheses to clarify the default order of operations:
(val1 = true) and false # results in val1 being equal to true val2 = (true && false) # results in val2 being equal to false
この問題に関しても全ての演算子の優先順位を記憶しておく必要はない。たとえそれが暗記できていなくても「これって演算子の優先順位を問う問題だよね」と問題の骨格が指摘できればほぼOk。後は会話の流れで「=とandってどっちが上だったっけ？」とか聞けば、面接官も会話の中でどっちが上かぐらいは話し出す。最後は解答例にあるように（）を付けたコード事例を示せば完璧。実際のコードにおいても（）があった方が可読性が上がる。読む人に「演算子の優先順位を考慮させるコード」なんて優しさに欠ける。
この問題のポイントはそういう演算子の優先順位とかをまったく気にかけず「これはどう見ても同じ結果が返ってくるだろー！」とか言い出すレベルじゃないことを証明することだけ。
演算子の優先順位はこれ。
高い ::
[]
+(単項) ! ~
**
-(単項)
* / %
+ -
<< >>
&
| ^
> >= < <=
<=> == === != =~ !~
&&
||
.. ...
?:(条件演算子)
=(+=, -= ... )
not
低い and orその３につづく。
海外転職の面接で英語で聞かれるRubyとRailsの質問事例とそれを会話で対処する方法 - その３ - Ruby on Railsのビシバシはぁはぁ日記
もっと詳しくエンジニア転職のコツとか書いてる本。
- 作者: Gayle Laakmann McDowell
- 出版社/メーカー: Wiley
- 発売日: 2014/09/02
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
海外転職の面接で英語で聞かれるRubyとRailsの質問事例とそれを会話で対処する方法 - その３
前回のつづき。
【問題３】
What’s the issue with the controller code below? How would you fix it?
class CommentsController < ApplicationController def users_comments posts = Post.all comments = posts.map(&:comments).flatten @user_comments = comments.select do |comment| comment.author.username == params[:username] end end end
これはなにも「このコードをリファクタリングしてくれ」ってことではない。問題の箇所と解決方法を英語で話すだけ。
【解答例３】
This is a classic example of the notorious “n+1” bug. The first line will retrieve all of the Post objects from the database, but then the very next line will make an additional request for each Post to retrieve the corresponding Comment objects. To make matters worse, this code is then making even more database requests in order to retrieve the Author of each Comment.
This can all be avoided by changing the first line in the method to:
posts = Post.includes(comments: [:author]).allThis tells ActiveRecord to retrieve the corresponding Comment and Author records from the database immediately after the initial request for all Posts, thereby reducing the number of database requests to just three.
まー典型的なN+1問題だね（a classic example of the notorious “n+1” bug）、と指摘できれば、それでもうほぼ正解。
解答例として
posts = Post.includes(:comments).all
としても「いや、もう１段階あるんだけど」ぐらいは指摘されるかもしれない。
とにかくN+1問題に対処した経験があって、データベースのパフォーマンスにも気を使える技術レベルですよ、とアピールすることが肝心。
会話の中で「アタシはGemでBulletとか入れて、デバッグしてるんだよね。あれがあったらN+1が見つかりやすいから。あんたの会社ではナニ使ってんの？」とか質問していろいろ聞くべし。そうした会話の中でその会社の現場の様子なども把握できるし、なにより応募者の技術レベルが「それなりに分かってるレベル」であることが証明できる。
次回につづく。
もっと詳しくエンジニア転職のコツとか書いてる本。
- 作者: Gayle Laakmann McDowell
- 出版社/メーカー: Wiley
- 発売日: 2014/09/02
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
