I tend to agree with this sentence:“easy choices, hard life; hard choices, easy life.” I think we can add “easy questions, storm incoming”.

Image for post
Image for post
Yo babe, should we leave the city?

Say you’re thinking about the dishes, they need to be cleaned. That’s part of modern life. Maybe she’s done it already? If not, let’s do it, right? Simple, effective, logical. Just wanna know, right?

Yo babe, have you already cleaned the dishes?

Now, a lot is actually being conveyed on your behalf here without your knowing!

Why yes I cleaned them. What the fuck is that question? You think I’m your maid? Go fuck yourself!

Tough but…


  1. Dietary fat, whether saturated or not, is not a cause of obesity, heart disease, or any other chronic disease of civilization.
  2. The problem is the carbohydrates in the diet, their effect on insulin secretion, and thus the hormonal regulation of homeostasis―the entire harmonic ensemble of the human body. The more easily digestible and refined the carbohydrates, the greater the effect on our health, weight, and well-being.
  3. Sugars―sucrose and high-fructose corn syrup specifically―are particularly harmful, probably because the combination of fructose and glucose simultaneously elevates insulin levels while overloading the liver with carbohydrates.
  4. Through their direct effect on insulin and blood…


2015年からサイボウズでAndroidデベロッパーとして勤めていたフランス人なのですが2017年の秋にAndroidデベロッパーとして Square社に応募しました。応募する側からして採用プロセスは合理的でやりやすかったので、この採用プロセスが他の企業にも似たような形で広まっていくと良いなと思って Square の採用プロセスを説明するためにこの文章を書きます。

応募

インターネットで求人を見かけた事から始まりました。Android開発の世界じゃSquareが提供してるライブラリは誰でも見たことがあると思います。正直なところ、直接応募するのには不安があって、先に SNS 上で Squareの社員に声かけて話を聞いてみようと考えました。相談にのってくれた Squareの社員は親切な人で話が終わるところで「よかったら連絡先を教えてもらえばうちの人事から連絡がいくようにお願いするよ」と言ってくれたので、連絡先を渡しました。

リクルーター

一週間後、Square のリクルーターさんからメールが届いて「都合の良い時にビデオチャットしようか」と。当たり前ですがリクルーターさんはニューヨークにいてるので時差は13時間(冬は14時間)です。人事の方の業務時間に収まるように、日本の朝7時でインタビューをする事になりました。

何を聞かれるかや何を用意したらいいかがわからなくて緊張していたけれど:

― どうも。あなたの github をみてたけど Square を知ったきっかけって Dagger ですかね?

― そうですね。そちらのライブラリはもういくつか使わせてもらっているし、有名なエンジニア(JW)もいるので前からは知ってましたね。

― そうかそうか。今から採用プロセスを始めようと思うけど質問ありますか?

― えっ!?

なんか、僕が無駄に緊張していたようでした。リクルーターさんは「応募者の仲間」という立場で採用プロセスの最初から最後まで相談できるパートナー的な役割になります。日本でいうと、人材紹介会社の人と同じ感じですかね。

挨拶してすぐに質問はないかって聞かれて困りました。逆に向こうから色々質問されると思っていたからです。ちなみに、この時点で資料:履歴書、職務経歴書、PRなどを一切出してません。「あなたの個人ウェブサイトをみたけどそれで十分」って言われてびっくりしました。その時点で採用プロセスの大きな流れを説明されたのですが、まずリモートのテレビ会議で面接を3回して、そこを通過すると実際に会社に来て、更にいくつかの面接を受けるという事でした。

口頭でもメールでも説明を頂いたのですが「これから受けて頂く面接はその流れ:リモートの面接を全て同じ日にやるか、別の日に分けて行うかなどの配分はお任せします。」例えば、3回の面接を3時間とおして1日で行うか3回の面接を1時間ずつ、3日に分けて行う等。僕は、事情があって、3回にわけて1時間 x 3の面接を受けました。

ビデオチャットが終わった後にまとめのメールを頂いたのですがどうかほんまにうまくいってほしいのように色々なアドバイスが書いてありました:

  • Square のブログに面接について記事があるので確認してみて
  • 準備におすすめの本は Cracking the coding interview
  • 練習できるウェブサイトは HackerRankInterview CakePrampLeetCodeCodeEvalTopcoder
  • 面接自体は60分。45分は好きな言語で CoderPad を使ってペアプロをして最後の15分は応募者からの質問対応(雑談)
  • 技術面接に対するアドバイス:1)本番環境にリリースされるのと同じぐらいきちんとコードを書く事、2)自分の得意ところを発揮する事:あまり知らない言語を選ばないなど、3)課題をちゃんと理解する事:曖昧な部分は確認しておく事、4)コンピュータ科学の基礎を勉強する、5)時間を考慮する:ゴールは時間内に動くコードをリリースする事、6)面接官とコミュニケーションをとること:実際に採用された場合は仲間とコミュニケーションとれるかどうかもみられる、7)自分が書いたコード以外の解決方法、他の選択肢を話せるように心の準備を:面接官がツッコミや質問でいろいろ聞く可能性あり。
  • ペアプロ中は忘れた事や気になる事はなんでも Google やStackOverflow で探しても良い。普段の仕事と同じ状況での行動を見ることを目的として面接をするから。

じゃ、面接を受けたい時にまた連絡くれたら良いですよ」と。ちゃんと勉強しようと思って1ヶ月ぐらい先の日程を設定してもらいました。

ペアプロ面接

3回ともですが実際に Squareで働くエンジニアが面接官でした。ただし、自分が応募した求人内容は知らないし、自分が応募したチームとの関係のない人でした。この面接では、客観的にデベロッパーとしてコードが書けるのか問題なくコミュニケーションができるのかを確認された印象でした。

流れは最初に課題の説明を受けて、その後、課題の内容で曖昧な部分を話して明確にしてからコードを書いていきます。ペアプロ中は困った時に相談したり、意見を聞いたり、インターネットで調べたりしながら課題を解いていきました。ある程度、課題を解決した時に「じゃ、次はこれも必要になる、どうする?」って追加のテーマが与えられ、それに対応するというサイクルの繰り返しで45分が経ちます。与えられる課題自体はあまり難しくなくて、例えば URL をパースする関数を書くとか、ブロッキングキューを実現するとかの課題でした。が、45分はあっという間に経ちます!45分が経ったら課題の解決ができても、できてなくても最後の15分の話をするために時間が守られてコーディングがここで終わります。

最後の15分は自分が聞きたい質問を自由に聞けます。面接官は自分が応募してるチームの人じゃなかったのでプロジェクトの話はできなくてかわりに会社全体の事とか、面接官自身の事について質問していました。

フィードバック

各面接が終わると、毎回必ずリクルーターさんとビデオチャットをします。リクルーターさんから「面接はどうだった?」って感想を聞かれてこっちの感想を共有するし、更に面接官が書き上げたフィードバックを細かいところまで共有してもらえます。それによって、リクルーターさんは面接官と応募者の間に認識のずれがないかを確認してるし、応募者として自分がうまく行かなかって凹んでいる時に「そんな事ないと思うな、面接官は〇〇言うたし、大丈夫ですよ」と言うてくれたりします。心強い。

面接官の選び方について聞いたのですが、Square は入社が1年以上の社員には全員にオリエンテーションやトレーニングさせて、面接に参加してもらってるようです。ですので、面接官はそれぞれな人がいます。面接官が向いてない人もいるし、めっちゃ上手な人もいます。

現場へ行く

無事にリモートで受けた3つの面接をパスしたので、現場へ行く事になりました。現場に行って応募したプロジェクトのチームに初めて会える機会になります。ちなみに、日本から北アメリカへの飛行機やレンターカーやホテルや食事代など、会社がすべて負担を抱えてくださいました。

通常アメリカ国内で採用する場合は北アメリカ内の移動なのでホテルをとらないパターンが多いと思うのですが、日本から受けに行く場合でも問題なく二泊も泊まる事ができました。更に「時差ボケのせいで自分の能力を発揮ができなかったらもったいないのでもっとはやく来て泊まって良いよ」って言うてくれました。こういうとこも、応募者のパフォーマンスが最大限発揮されるように考えてくれてて、非常に好印象でした。僕はただ飛行機の中でちゃんと寝れば時差ボケがでる前に面接を受けられるんじゃないかなと考えて現場へ行ってすぐ面接を受ける事にしました。

現場での面接

現場で受ける面接は3つありました。

  1. ペアプロ(リモートでやったやつと同じ)
  2. 経験に対する質問対応
  3. システムデザイン・アーキテクチャ

経験に対する質問対応

今までやってきた事を軽く説明してから突っ込まれる面接です。必要な時にホワイトボードを使います。

― 最後に作ったアプリはどんなアプリ?

―その機能はどうやって実現した?どういう設計?〇〇ってどういう事?

―テストはどうやって書いた?なんでそういうふうに書くの?

―〇〇の時はどう選択肢をした?なんで〇〇しなかった?

広いところから細かいところまでの質問を受ける45分でした。最後の15分はいつも通り自分が聞きたい事を聞きました。

システムデザイン・アーキテクチャ

変な汗が出てたぐらいに一番焦った面接でした。今回も必要に応じてホワイトボードが使えます。

駐車場を管理するシステムのAPIをデザインしてください

実際、与えられた課題は違うネタだったのだけれどイメージとしては言われるのは本当にそれぐらいです。すごく苦労しました。自分がフリーズしたら面接官が質問や提案で課題解決に向けたガイドをしてくれたのでなんとか進める事ができました。

マネージャーとのコミュニケーション

すべての面接が終わった後に、マネージャーからPRトークを頂きました。探している人材の話だとか、プロジェクトの課題と会社のビジョンの話が聞けて良い感じでした。特に印象に残ったのは「耐え難いアホは要らん」って言われた事です!

契約

最終的にお陰様で合格しました。じゃ日本からどうやって契約をサインできるのかと思ってたら DocuSign 経由でデジタルな契約を送られてきて普通にインターネット上でサインする事ができました。

最後に

全体を通して面白いと思ったのは最初のリクルーターさんのビデオチャットから最後のマネージャーとの話までは、履歴書とか、他の資料は一切求められませんでした。ああいうのを作るのは大変だから助かったし、実際にコミュニケーションをしながら、お互いのスキルや相性を確かめるプロセスになっていて、非常に合理的だなと感じました。

別な話で、北アメリカのIT企業の面接は基本、難しい課題をホワイトボードでコーディングする事が多いイメージです。実際の仕事と違うので場合によって賢い人でも落ちる事はよくあります。なぜそうなっているかっていうと企業は偽陽性(False Positive)を避けようとしているからだと思います。要するに間違って企業に合わない人(人間として、人材として)を採用するのが最悪だと思われています。良い人材を見過ごすよりも合わない人材を採用する方がコストが高いからです。

しかし、Square の場合はリクルーターさんとの関係性や面接のやり方をみて逆だと思った:Square は偽陽性を避けながら、偽陰性(False Negative)も強く避けようとしています。要するに面接で与えた課題がおかしかったり、普段の仕事と違いすぎたせいで誤って良い人材を見送る事ももったいないと考えています。なんか少しでもSquareの場合はバランスがとれてると思いました。そのため、リモートや現地での複数回の面接やコミュニケーション、リクルーターによるアドバイス、旅費の負担など、応募者が選考において最大限のパフォーマンスを発揮できるように設計されてて、Squareの採用プロセスは採用する側、応募者側双方にとって、非常にバランスがとれていると感じました。

以上!


育児休業を取った育メンの3名がいる。家庭に貢献がしたく、3名の育メンも毎日朝昼晩にご飯を食べたら洗い物をする。

一人目のパパは食器を洗ったら休憩も取らずにタオルでお皿を拭いて食器棚にすべてを戻す。次にご飯の時間が来たらまた食器棚から必要の食器を取り出す。このパパのSwappinessは最高で100だ!

二人目のパパは食器を洗ったら休憩を取る。時間が経ったらパパは乾いた食器を食器棚に戻す。次にご飯の時間が来たら食器置きにまだおいてあるものがあればそれを使って、それから必要な食器を食器棚から取り出す。このパパのSwappinessは普通で60だ!

三人目のパパは食器を洗ったら「しゅーりょー」って言って休む。食器置きにスペースが余る限り、時間が経っても食器棚に食器一つも何も戻さない。食器置きにスペースがなくなった時だけ、仕方なく追加で置きたい食器の分だけ乾いた食器を棚に戻す。次にご飯の時間が来たら食器置きにおいてある食器だけでテーブルの準備をする。必要な時に限って食器棚からものを取り出す。このパパのSwappinessは最低で0だ!

あなたの Swappiness はいかがですか?


今は昔、お洒落なお手洗いありけり。同時に二人の方がお手洗いに入りける。二人共が恥ずかしがり屋で「一人になってからウオシュレットを使ってやろう!」という事で二人共が待ち始める。一人になる状態が現れず、お互いに待ちすぎた結果、二人の方は死んでしまった。

それがデッドロックだ!

お陰様で、そのデッドロックの深刻度を認めた人間がいた。トイレで死亡が発生しないため、音姫が開発された。素晴らしい。


There are multiple articles, talks, and podcasts that address the topic of what the Model-View-Intent architecture is, but I rarely hear about what I think are the principles of this architecture.

Model-View-Intent in a few words

The MVI architecture is a pattern which aims at organizing the higher layers, i.e. close to the UI, of your application to make its development simple. Now, the architecture is reactive and since most of us, Android developers are not used to the reactive paradigm, I believe the simplicity of the MVI architecture remains overlooked.

Image for post
Image for post
The Model-View-Intent Architecture as I see it

As I see it, the simplicity is found in a contract which the MVI…


The thoughts of others
Were light and fleeting,
Of lovers’ meeting
Or luck or fame.
Mine were of trouble,
And mine were steady;
So I was ready
When trouble came.


We’ll be using Dagger here but I believe other library can offer the same functionality.

In Android, we can pass data to activities via the intent, specifically its extras. We can also take advantage of the savedInstanceState bundle for restoring our view after it’s been discarded. If we want to use the data contained inside the bundle, we would need to extract it in a context bound environment, keep it and pass it over to other members as needed.

public class MyActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { Intent intent = getIntent(); String myValue = intent.getStringExtra(“MY_KEY”); //…


Arrêté, interrogé et torturé, le régicide sera condamné, le 2 mars, à être conduit en place de Grève “et sur un échafaud qui y sera dressé, tenaillé aux mamelles, bras, cuisses et gras des jambes, sa main droite tenant en icelle le couteau dont il a commis le dit parricide, brûlée de feu de soufre, et sur les endroits ou il sera tenaillé, jeté du plomb fondu, de l’huile bouillante, de la poix résine brûlante, de la cire et soufre fondus ensemble et ensuite son corps tiré et démembré à quatre chevaux et ses membres et corps consumés au feu…


When I find some cool stuff―helper methods, automation scripts, fancy way to do things―in some projects I am checking out, there is usually a strong appeal inside of me to apply the same sweet stuff to my own projects.

Somewhat, I feel guilty of my copying many existing code into my own projects. What if the original author would show up and shout at me: “Oh, I wrote that.”

Should I feel guilty or sorry I benefited from someone else’s work? I don’t know.

I usually add the right copyright to explicitly acknowledging my plagia. When possible, I also try…

Benoît Quenaudon

Android Engineer / https://benoitquenaudon.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store