career

概要

プログラマーのキャリアに関することをまとめる。

キャリアのことについて考えるのはあまり面白くない。が、同じ努力で結果が大きく変わる要素のために無視してもいられない。たとえばProgramming Languageの選択で未来は変わる。業界や領域が死ねば、精通していてもアドバンテージを失う。たまには考えないと。

よく考える疑問: 働くとしたら大企業がいいのか、startupがいいのか。あるいはフリーランス、会社を立ち上げるのがいいのか。 望むものや状況によって最善の手は変わりそうなので、よく周りと自分を理解するために書く。

Memo

やりたいことをやりきる

たとえば前職のレガシーなシステムに不満がありました、という理由は採用側から見るとクソに見える。じゃあなんで改修しないの、しようとしたの、と。結局のところ、すごい人は環境ごと変えるので、説得感のある理由にならない。環境を変えられない人は価値がない。そしてモダンな開発にも対応してないんじゃ話しにならない。 やることは2つ。

  • 何かしらのレガシーの根本的な脱却をすること。モダン化すること。バージョンを上げる、ライブラリ置き換えや削除、データベースリファクタリング。
  • モダンな技術スタック開発に精通すること

どうせ離れることを考えているなら，何も失うものはないので技術的挑戦を自分から上を説得してやるのがよさそう。何も気にする必要がなくやりたい放題。それによって結局のところ会社は長期的なメリットを得る。個人も実績を積むことができるので、もはや常時離れるつもりで仕事をやったほうがいいか。少なくとも居座るつもりで挑戦しないよりは確実に良い。

やることを選ぶ

スキル的な面で、やりたい仕事の種類を優先づけしていくことが重要に見える。 与えられた仕事をやるだと、ジャンルがバラけて技術が蓄積しない。 割り振るのにもコストがかかる。

自分から取っていくこと、言い方を変えると選べる範囲で仕事を選ぶことが重要そうだ。選ぶというとアレな感じがするが、我慢しても見返りは来ない。やりたいことを明確に伝えないと。

仕事の探し方

まず自分の要件を明確にする。それから探す。カジュアル面談して掘り下げ。応募する。

資金調達額から探す。

  • Startup DB
  • 業種
    • toB, toC
  • 使用技術
    • プログラミング言語
  • 理想のキャリア
  • 会社の規模
  • 幅広くか、掘り下げか
  • リモートワーク
  • 給料
  • 自分がよいと思えるサービスがいい
    • とくに開発やプログラマーとして使える、使っているものだとよい。極端な例はGitHub、CircleCIとか。自分がユーザとしてイメージできないものは作れない
  • 利用ユーザ数
    • 多いほど要件がシビアで、知見や能力が向上する可能性は高い。例: 1000万ユーザのサービスで遅いクエリを作ると完全に止まるので、ノウハウが蓄積する。1万ユーザでは致命的に遅いクエリでないかぎり問題にならない
  • ユーザとの距離感

仕事内容を数字で示す

アピールしよう、ってなったときでは思い出せないので重要な手柄については日頃メモしておく。リンクだけでも思い出しやすい。

期間やラベルを指定して検索した結果の(クエリがくっついた)URLを貼ると、数字として示しやすい。

  • PR数
  • Review数
  • 解決Issue数(必ずやるときはAssignしておくことが重要)
  • OSS活動へのリンク

聞くこと

  • 開発マシンにLinuxを使えるか
  • メンバーの開発マシン・エディタはなにか
  • 開発人員の数。チームの数、チームの人数
  • GitHubを使っているか
  • チームは何の単位で分割されてるのか
  • チームごとの違いは何か
  • どのチームに配属される可能性があるのか
  • 期待されているポジション。技術レベル/スタック
  • カバレッジ率はどれくらいか
  • 技術負債はどうしているか
  • OSSにコントリビュートしてる人はいるか
  • 会社やチームの課題は何か
  • フルリモートワークは可能か
  • オフィスに何人くらい来ているか
  • オフィスは静かか
  • ドキュメント管理はどうやっているか
    • 例えば設計書はどうやって書くか
  • 技術選定の理由
  • GitHubやりとり見せて(review, PRコメントの感じ)
  • プロジェクト管理見せて(タスクの切り方、進めかた)
  • プロダクト見せて
  • 専門領域の知識を必要とするか(例: 法律)
  • どのように開発すすめてるか
  • 最近の入退職の人数

話すこと

高頻度で聞かれること。何を話すにも、きっかけ、ストーリーが必要なのでそのへんも考える。

  • エンジニアとして目指している方向性
  • 前職を辞めた理由
  • 志望理由

理由のテンプレート

前社で足りないものから探す。

  • 開発の進め方
  • プロダクトへの興味
  • 上に評価されない。任せてはもらえるものの、評価につながらない

新しいことをやりたいは、枠組みの中でなぜやらなかったという話になる。

効果的なコミュニケーションを行えているか

リモートワークではcommunicationについての共通理解が、より重要になる。 リアルの仕事環境と異なる点。 高コンテキストでのリモートワークはやりにくい。 仕事の行いやすさに直結するだろう。

だから、集団としてどのような取り組みを行っているか、そこを整備している人間はいるか確認するとよいだろう。

デフォルトの条件

  • リモートワークOK
  • フルフレックス
  • 人が多くない(仕事全体に自分の占める割合が多いほうがいいから。結果が見えるのがいい) かつ 技術力がある 規模というより、文化による違いの可能性が高いので再考。

マッチョさ

実際には面接の前の段階で勝負は決まっているように見える。だから面接で緊張する必要はない。何も武器を持たずに応募する時点で失敗しているし、すごい経験があるなら経験した時点で成功している。生き残る確実な戦略は、すでに何か難しいことを達成していて、それをオープンにできることだ。

  • 業務やプライベートでの困難な経験(基本的には、業務 > プライベート で評価される。責任・困難さ・他者を巻き込む的な意味で)
  • ↑経験に基づく何らかの発表などの還元

それを踏まえたうえで、業務やプライベートでやることを選択する必要がある。十分に難しい、挑戦的なことをしているか、技術スタックは合っているか、等々。どんな仕事でも挑戦して何かを達成しないと、次の仕事探しで詰む。

スタック的には1つのプログラミング言語に精通していれば、ほかの言語を習得することは難しくないと予想できるので、技術スタックが一致していないことは大きな問題にならない。WEB開発の場合は、DB・API設計は共通のため、そこの技術力や経験があるかは重視される。

Tasks

Reference

7年在籍したCircleCIを退職しました | Program Is Made At Night

海外のスタートアップで働くこと。面白い。

シリコンバレーと日本のエンジニアの能力の違い : 酒井潤公式ブログ

アメリカだと、自分はPythonで専門にバックエンドでやっていくと決めたら、他のKubernetesなどの技術はインフラエンジニアの領域なので、知らなくてもいいし、任せるって感じがあります。多少Kubernetsに関しては知識として身につけることはありますが、さほどのめり込みません。

日本は他人と比較して、自分が知らないことに不安を感じ、いろんなことに手を出してしまうエンジニアが多いので、専門的な領域でプロフェッショナルになりにくいというところもあるかもしれません。

超わかる。まさに自分がこの状況。 色々手を出してどれも中途半端。

The Product Led Growth Market Map - OpenView

プロダクトを成長させる市場。こういう企業を狙うとよさそう。

エンジニアという仕事を楽しみ続けるためには | ドクセル

技術の選択、プログラマとしてのブランディング、キャリア論。

TODO VALVE handbook for new employees

VALVEの新入社員ガイド。

Netflix Jobs

Netflixのカルチャーガイド。日本語訳もある。

Netflix Culture

スライドバージョン。

Overview - Dropbox Engineering Career Framework

Dropboxのキャリアの文書化。

Archives