就職します

就職活動終わりました

ブログにも書いてたんですが、年末で前職を退職して就職活動してました。

無事に次のところも決まったので、どんな感じだったのか軽くまとめておきます。

su-kun1899.hatenablog.com

謝辞

ブログや SNS で公開してたこともあり、本当にいろんな人から沢山の会社を教えてもらいました。

数年(数十年?)ぶりに連絡とってくれた人から親戚まで笑

大なり小なり自分のことを知ってる人から頂ける情報というのは職場探しにあたって大きな助けになりました。

ありがとうございました。

活動期間

  • 2019年12月8日に求職エントリをPOST
  • 話を聞き始める
  • 年明けから本格的に行脚をはじめる
  • 2020年1月中頃から徐々に選考へシフト
  • 1月末頃にオファーが出そろう
  • 2月頭に就職先を決める

以前から声をかけてくれていたところは早くから具体的な選考を受けてたりもしましたが、大体こんな感じです。

1月は学生時代の就職活動を思い出すくらい色んなところに行っていました笑

使った媒体

実際に話を聞きに行った会社だけでも、20以上あると思います。

当初は、自分から積極的に探すことやエージェントに頼むことも考えていたたんですが、すぐにキャパオーバーになりました。

落ち着いて考えてみれば、10人が紹介してくれたらそれだけで10社になるし、1日3社回っても3日以上かかるんですよね。。

アクティブに探した会社は基本的にないです。
(コンタクトはアクティブに取った場合でも、誰かから紹介してもらったとか)

話を聞きに行く

最近は採用前提の媒体でも「まずはカジュアル面談」というところが多いと思うんですが、会う前に自分の状況を伝えるようにはしていました。

「御社のお話も聞きたいんだけれども、自分は本格的に探しているので、そちらも突っ込んだこと聞いてくれて構わない」といった感じです。

カジュアル面談は転職を考えていないときも時々行ったことはあるのですが、職探しの熱量が高いことを伝えておくと、かなり具体的な話ができるような気はします。

たくさんの企業とお話してみてよかったなぁと思うのは、会話の中で自己分析がかなり進むということです。

「自分はこういうことが (やりたい|やりたくない) んだなぁ」とか「こういう価値観なんだなぁ」と気付かされることがとても多かったです。

そうすると、いざ選考に進むときのも自分の中での動機づけはかなりしっかりされるので、いろんなことが言語化された状態で臨めました。

あと就職とは関係ないところで、世の中にはいい会社がたくさんあるというのを知れたのはよかったです。

自分が当事者として働くにはフェーズやタイミング等の変数が絡みますが、企業や組織、お会いした人たちが取り組んでいることを応援したいというところは多かったです。

「自分も早く次を見つけて、負けじと頑張らねば」と、労働意欲を刺激されました。

逆に大変なのはやはり時間と労力の問題で、このやり方は退職済だったからできたと思います。

日頃から情報収集大事だよなと思いつつ、話を聞きに行ったのが半年前だったら、会社も応募者もフェーズが変わってる可能性は十分にあるだろうし。

この辺は難しいところです。*1

選考

実際に選考に進んだのは 6 社くらいです。

大体 3 回くらいの面接で終わるところが多かったです。
カジュアル面談と比べてさすがに少し緊張はしましたが、割と雑談っぽい感じが多かった気がします。 *2

選考とは少し違うかもしれませんが、体験入社だったり、今思えばあれは選考だったのかなという会食もありました笑

コーディングテストのある会社は少なかったです。
面接の中で、「これはスキルチェックの観点で聞いてるんだろうな」と思う質問は当然ありましたが。

関係ないですが、コーディングテスト対策でやってみた LeetCode*3 がちょっとした気分転換にいいので、今も時々トライしています。

面接は誰が出てくるかでかなり印象が変わってくる気がします。
採用に会社がどういうスタンスなのかが表れる部分でもあると思うので。

自分は下記のような人たちと話せるとうれしいなという感じです。

  • 開発チームの偉い人(いるなら CTO とか)
  • 開発チームの現場の人
  • 開発者じゃない偉い人(事業部長とか)
  • 偉い人(社長とか)
  • 開発者じゃない現場の人(プロダクトオーナーとか)

よく聞かれたこと

何社かに聞かれて、ちょっと思うことがあった質問。

マネージメントか技術か

マネージメント方面に行きたいのか、技術を突き詰めたいのか、みたいな質問はすごくよくされました。

その度に、「そういう風には考えてないです」と答える厄介な応募者でした笑

マネージメントも技術もどちらも開発の場に必要なもので、「マネージャーという役割をおく」のは実装のひとつでしかないと考えています。

濃淡はあれど、役割としてそこを求められるのは、少なくとも今の自分のキャリア志向とは違うという回答をしていました。

ただ採用する側からすると、ポジションで探すのも普通だと思うので、面倒くさい応募者だったと思います。

XXXX を作るとしたらどう作りますか?

この質問は多分、採用する技術スタックだとか選定理由だとかを聞いて、スキルレベルみたいなものをみたいんだと思います。

ただ自分みたいな思考の人間だと、「それは何で作るんですか?」「本当に作らなきゃいけないんですか?」みたいな返しになってしまうので、お互いに微妙な気がしました。

それよりは、これまで実際に携わったサービスとかベースで語るほうがやりやすいのではないかなぁ。
(ゼロから同じものを作り直すとしたらどうしますか?で、同等の会話はできると思うし)

職務経歴書

選考に進むときには求められることが多かったと思います。
(あればください、くらいの温度感だったかも)

僕の場合は Wantedly と LinkedIn に割としっかり書いていたので、その内容で事足りたというのはありそうです。

もう少し補足して書いたものは、個人で使っている esa にまとめていました。
なので、求められた場合は esa の共有機能 で生成した URL を渡していました。

紙の書類を求めるところはなかったですが、 PDF で渡せというところが一社だけありました。

オファー

ありがたいことに複数社から内定をいただき、かつオファーが出揃うまで返事を待ってもらえました。

待遇面は下限が満たされていれば、後は自分が何を軸に選ぶかになってくると思います。

そもそもで行きたいと思うところしか選考に進まなかったので、相当に迷いました。

金銭的なことはある種もっとも客観的な評価でもあるし、技術的に面白そうな環境はそれだけでも魅力的です。

ギリギリまで迷ったんですが、ふと自分の転職エントリや職務経歴書を見返して、原点回帰というか、「一番こういう思いで働ける場所」という軸で選びました。*4

  • 最高のチームで誰かのライフスタイルを変えるようなプロダクトを作りたい
  • 何を課題として、何を解決策としてやっている(作っている)か
  • どんな価値観・文化か
  • どんな人がいるか
  • etc

断るのが一番心苦しかったです。。

入社

2/16から新しい会社で働き始めます。

なので、もう少しだけ無職を満喫します笑

新しい会社でのことは、また追々ブログ等に書けたらいいなと思っています。*5

ウィッシュリストはこちら

*1:それを解決できるのが (少なくとも従来のような) 転職エージェントでない気はする

*2:先方の配慮もあったのだと思う

*3:https://leetcode.com/

*4:あくまで比較のうえなので、他の会社も魅力的なことは前提

*5:所属先を隠すつもりもないですが、積極的に明かすつもりもない

1299. Replace Elements with Greatest Element on Right Side

LeetCode の挑戦ログ

Problem

https://leetcode.com/problems/replace-elements-with-greatest-element-on-right-side/

  • 配列の右側で最大の値に置き換えた配列を作成する
  • 配列の最後に -1 をつける

Solution

class Solution {
    public int[] replaceElements(int[] arr) {
        List<Integer> nums = Arrays.stream(arr).boxed().collect(Collectors.toUnmodifiableList());

        int[] replaced = new int[nums.size()];
        int max = extractMax(nums.subList(1, nums.size()));
        for (int i = 0; i < (nums.size() - 1); i++) {
            if (nums.get(i) == max) {
                max = extractMax(nums.subList(i + 1, nums.size()));
            }
            replaced[i] = max;
        }
        // last element
        replaced[replaced.length - 1] = -1;

        return replaced;
    }

    private int extractMax(List<Integer> list) {
        return list.stream()
                .mapToInt(Integer::intValue)
                .max()
                .orElse(0);
    }
}

Impressions

  • 最大値を毎回計算していたら Time Limit になってしまった
  • 一度計算したら、その最大値が出てくるまでは計算不要にした

数字の配列を降順にソートする #java

概要

  • 数値の配列を降順にソートされたリストにする
  • Stream の sorted を使う
  • Collections の reverseOrder で降順になる

サンプル

int[] nums = {3, 6, 8, 1, 5, 4, 7, 9, 2};

List<Integer> sorted = Arrays.stream(nums).boxed()
        .sorted(Collections.reverseOrder())
        .collect(Collectors.toList());

System.out.println(sorted); // [9, 8, 7, 6, 5, 4, 3, 2, 1]

補足

  • sorted には Comparator を渡せる
  • Comparator には comparing という生成メソッドがある
  • プリミティブ型には comparingInt のように専用のものが用意されている

参考

JavaScript で隔週判定する #javaScript

概要

GAS (Google Apps Script) のトリガーは隔週実行に対応していない。

なので、隔週判定を自前で実装してみる。

考え方

  • 「基準日」と「判定日」を引数で渡す
  • 「基準日」と「判定日」の経過時間を算出する
  • 経過時間を一週間の経過時間で割る
  • 結果が偶数であれば、「判定日」は「基準日」から見て隔週日であると判定する

実装

// base: 基準日, target: 判定日
const isBiweeklyDay = (base: Date, target: Date) : boolean => {
  // 日付以下を切り捨て
  const baseDate = new Date(base.getFullYear(), base.getMonth(), base.getDate())
  const targetDate = new Date(target.getFullYear(), target.getMonth(), target.getDate())

  if (baseDate > targetDate) {
    // target の方が過去
    return false
  }

  // 経過時間
  const passTime = targetDate.getTime() - baseDate.getTime()

  // 経過時間を一週間で割って、偶数なら隔週
  const weekTimes = 604800000
  return (passTime / twoWeekTimes) % 2 === 0
}

テスト

jest で書いたサンプル

describe('基準日が 2020-01-01 の場合' => {
  // month index が 0 始まりなのは分かりにくいので
  const JANUARY = 0
  const baseDate = new Date(2020, JANUARY, 1)

  test('2020-01-08 は false', () => {
    expect(isBiweeklyDay(baseDate, new Date(2020, JANUARY, 7))).toBeFalsy()
  })

  test('2020-01-15 は true', () => {
    expect(isBiweeklyDay(baseDate, new Date(2020, JANUARY, 15))).toBeTruthy()
  })
})

配列を任意のグループに分ける #javaScript

概要

JavaScript で配列を任意のグループに分ける。

例えば 7 人を 3 グループに分けると 3人-2人-2人みたいに分けたい。

考え方

  • 「配列」と「分けたい数」を引数で受け取る
  • まず割り切れる分を分けてしまう
  • 余りを改めて配る

素数が 7 だと 7 / 3 = 2 余り 1 になる。

まず 2-2-2 に分けたあと、余った分を先頭に追加して 3-2-2 にする。

実装

const splitArray = (array, splitSize) => {
  // まず割り切れる分を分ける
  const itemCount = Math.floor(array.length / splitSize)
  const splited = []
  for (let i = 0; i < splitSize; i++) {
    if (i === 0) {
      splited.push(array.slice(i, itemCount ));
      continue
    }
    splited.push(array.slice(itemCount * i, (itemCount * (i + 1))));
  }

  //  余りを配り直す
  const fraction = array.length % splitSize
  if (fraction === 0) {
    return splited
  }
  for (let i = 0; i < fraction; i++) {
    (splited[i]).push(array[array.length - (fraction-i)])
  }

  return splited
}

テスト

たとえば jest で書くなら。

test('7人を3つのグループに分ける', () => {
  const array = [1, 2, 3, 4, 5, 6, 7]
  const splitSize = 3
  expect(splitArray(array, splitSize)).toMatchObject([
    [1, 2, 7],
    [3, 4],
    [5, 6]
  ])
})

問題点

このやり方だと余りをあとから配るので、先頭のグループが [1, 2, 7] になってしまう。

これを [1, 2, 3] にするとしたら、どうするか。

  • 一度要素を総なめして、グループ分けをマークする
  • マークに沿って要素を詰め直す

こっちの方がよさそうな気がした。

もっとスマートなやり方もある気がする。

アジャイルコーチングを読んだ

アジャイルコーチング

アジャイルコーチング

永らく積まれていたのだが、ようやく読んだ。

僕はチームをリードする立場になったことはあってもコーチという立場になったことはない。

ただチームビルディングや開発プロセスをメンテナンスする時に自分が考えていることと、かなり近いことがいい感じにまとまってるなと思った。

自分のチームビルディング、うれしいことに褒めてもらえることが時々ある。 ただ状況に振る舞いが左右されることが多いので、一貫した考えをうまく言語化して伝えるのが難しいと感じていた。

もし、チーム作りみたいなものをスキルとして学ぶとしたら、この本を一緒に読みながら議論していくといいのかななんて思った。

気になったこと

この本はアジャイルコーチに向けた本だと思うのだけれど、紹介されている内容はチーム開発のスキルだと思う。 (もちろん、それを助ける人がいてもいいとは思うんだけど)

コーチングじゃなくて、チーム開発のスキルとして広まって欲しいことがたくさんあるなと思った。

アジャイルコーチング読書メモ · GitHub

テストコードでのヘルパーとか重複とか

テストコードでのヘルパーとか重複について考えた。

gihyo.jp

ちょっと調べたら、少し前のだけれども大御所の人たちの記事を見つけた。

僕もテストコード内のヘルパーや重複にはかなり慎重派。

もちろん見通しのよさや独立性っていう話もあるんだけれども、それよりも「安心したい」っていうモチベーションが強いかもしれない。

テストコードはある意味命綱だから、テストコード自体を信頼できるようにしておきたくて、シンプルに保ちたいという考え。

とはいえ重複絶対嫌とかそういうことではなくて、「共有は慎重に」ということ。

ヘルパを作るなら、ヘルパ自体を十分にテストしたいし、そのコストに見合うタイミングで導入すればいいと思っている。

TDD Bootcamp だったかでいいなと思ったのが、「パラメータライズドテストを検討するのは 3ケース目くらいから」という話。

感覚的にはそれに似ている。