同じ組織で働く人は常に転職活動をしていてほしい
早いものでLINE株式会社に入社して3年が経ちました。今日から勤務4年目となり、業界としてはそれなりに長く働いている側に足を突っ込んできた自覚があります。仕事もエンジニアからマネージャーになり、役割も変わってきたところ。 現職でまだやりたいこともあるだけでなく、明確にバリューを出せていて組織からも評価されている現状、しばらく転職する予定はないのですが、一方で、私は常に他の選択肢がないかを探し続けています。 そして一緒に働く同僚やチームメンバーには語弊を恐れずに言えば「常に転職活動をしながら仕事をしてほしい」と思っています。 現職についてのエントリに興味がある人はそう多くないと思うので、3年目が終わった節目として、今日は市場を見て仕事をすることの重要性について書き記すことにしました。 自社に満足しているときほど、外部の働き方を知る必要がある 「あなたは今の仕事に満足していますか？」と聞かれた
プロダクトにNext.jsとGoを採用した理由と背景 - ANDPAD Tech Blog
はじめに こんにちは！エンジニアの柿森です。新規プロジェクトを担当しております。 ANDPADではマイクロサービス開発を推進しており、新規プロジェクトは個別に技術選定を行い、既存システムとAPI経由で連携します。 また、マイクロサービス基盤はk8sで構築されており、死活監視やログ収集もよしなにやってくれる環境が整っております。 新規プロジェクトを立ち上げで、k8s上に乗せることを前提に技術選定を行いました。 技術選定を行うにあたって検討したポイントと、採用した技術について話していきたいと思います。(あくまで筆者個人の考えです。) 採用した技術スタックの概要 フロントエンドはBlitz-jsを参考にNext.jsを採用。 バックエンドはGo + gRPCを採用。 技術選定の方針 大きな方針としては一般的な考えを踏襲しています。 ドキュメントがしっかりしており、GitHubのStarがそれなり
なぜ僕たちはサーバレスでJavaを諦めTypescriptを採用したか - Qiita
この記事は個人ブログのうち技術に関する箇所のみを抜粋した転載です。 なぜ僕たちはサーバレスでJavaを諦めTypescriptを採用したか -Junks, GC cannot sweep- またブログには書いたのですが、諸事情により先に英語版が存在します。 こちらも書いたのは僕なので、剽窃などではないことはご了承ください。 [元記事]: Why we replaced Java with Typescript for Serverless in dev.to はじめに サーバレス(serverless)は昨今もっとも注目を集める設計手法の一つで、おそらく多くの開発者が大なり小なり自分のプロダクトに応用し始めているのではないでしょうか？ 僕自身、完全にサーバレスに魅せられてしまい、昔ながらの自分でサーバやミドルウェアを管理しながら運用するみたいな世界には戻れる気がしません。 そもそもスケーリ
GraphQL 採用における反省と Apollo Server の運用について
こんにちは。武田（@tkdn）です。 GraphQL を API として採用したサービスを今年序盤にリリースしています。具体的な内容は今年の夏サミ 2020 の公募枠でお話させていただいたのでよろしければ資料もご参考ください。 週一でリリースし続けるためのフロントエンドにおける不確実性との戦い方 / Developers Summit 2020 Summer C-4 - Speaker Deck今日は GraphQL や Apollo Server についての振り返りと反省を中心に供養しておきます。GraphQL 採用に迷いがある開発者、Apollo Server を採用しようとしている開発者へ向けた知見になれば幸いです。 まとめてみたら GraphQL みが思いの外少なくなりましたが、GraphQL Advent Calendar 2020 の 23 日目の記事です。 なぜ GraphQ
CTO不在の企業で開発組織を作っていくために大事なこと｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 これは CTOA Advent Calendar 2020 の5日目の記事です。 今までウノウとUUUMの2社のスタートアップでCTOを足掛け10年近くやってきました。経歴柄、CTOのいない企業から開発組織の作り方の相談を受けることが多いですが、やはりCTOが不在で開発組織を作っていくのは非常に困難です。とはいえ、転職市場に都合よく即戦力になりうるCTO人材が簡単に見つかるのも稀です。そこでCTOが不在の中で開発組織を作っていくために大事なことをまとめてみました。 開発組織作りで大事なのは採用ではなく環境作り開発組織作りで大事なことはいろいろありますが、最も大事なのは採用と環境の2つではないかと思います。環境が良くなければ優秀なエンジニアは採用できないし、優秀なエンジニアに来てもらえなければ良い開発環境を作ることができません。いわゆる
私が（iOS エンジニアの）採用でコードチェックする時何を見ているのか - Qiita
2021-10-17 追加 弊社の Android 採用課題も公開されましたので、そのリンクを追加しました。 2020-05-18 追加 本日から弊社の採用課題がこちらに変更されました。これまではアプリをゼロから作成していただく課題でしたが、今後は既存のコードをリファクタリングしてもらう課題となりました。ただし我々が確認する項目はそれほど大きく変更するわけではありませんので、本記事の内容の多くは引き続き有効です。 ここ数ヶ月は、iOS のエンジニア採用のコードチェックにもよく参加していますので、そろそろ良さそうと思って、ここで私がコードチェックする時に一体何をチェックしているのかを共有し、皆さんの転職活動やキャリア設計に役に立てればと思います。 Disclaimer この記事の内容はあくまで株式会社ゆめみの iOS エンジニア採用のものです。弊社以外の iOS エンジニア採用や、弊社でも
RE: 最終出社日について - megamouthの葬列
松田部長 お疲れ様です。システム戦略グループの山下です。 最終出社日についてのお返事ありがとうございました。 先日ご連絡した来年1月20日を最終出社とする退職は難しい、とのご回答でしたが、申し訳ありません、こちらとしましても、諸事情を考慮のうえ、最終出社日をご提示させていただいている次第となりますので、退職日を3月末まで延期するというご希望に沿うことはできません。 あしからずご了承下さい。 また、同時にご連絡させていただいた業務の引き継ぎについてですが、引き継ぎ人員が存在しないことにより、未だ一切の進捗がございません。 おそらくは、この点が、松田部長のおっしゃっている「就業規則上に明記されている業務上の支障が発生する事由」に該当すると思われます。 この点につきましては、システムインフラを解する人員が私以外に存在しない現状において、とり急ぎ解消の目処はたたないかと愚考いたします。 よって、勝
エンジニアの採用はどこを見ているか - 室長のひとりごち
エンジニアの自己評価を見るとき、気になる言い回しがある。 『○○をやった』 『○○を達成した』 そう書きたくなる気持ちもわからなくはないが、そう書かれると『それで』と返したくなる（言わないが）。 同じように、中途採用のレジメを読んでいると、エントリいただく方々の多くも、やはり『やった系』の書きっぷりが多い。例えば、 『○○業務プロジェクトでプロジェクトリーダとして云々かんぬんをやった』 などと書かれる。そのあとに、適用技術を列挙されたりする。 果たしてこれで、エントリされている中途採用のご希望を持たれているエンジニアさんとして、どこをアピールされているのだろうか。少なくとも自分にとっては、魅力的に感じられない。 こちらでご応募願いたいエンジニアさんに一緒に解決していきたい業務課題をあげているわけだ。であれば、その課題を解決しれくれそうなエンジニアとまずはカジュアルに会話してみたいと思うので
M社の採用について · GitHub
<a href="http://archive.today/ziDQ8"> <img style="width:300px;height:200px;background-color:white" src="https://archive.md/ziDQ8/737033e9e30423acf2c23fbedbcd1520665bd28d/scr.png"><br> M社の採用について · GitHub<br> アーカイブされた 2018年9月11日 10:48:44 UTC </a> {{cite web | title = M社の採用について · GitHub | url = https://gist.github.com/syguer/1d035473bd964a122dba9b4bbef191e6 | date = 2018-09-11 | archiveurl = http://a
エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた - Qiita
エンジニアの転職メモ を読んで、刺激を受けたので書いてみました。 非常に共感しました！ 自分的にちょっと気になるところ+αを書こうかなと。 書かれたことは会社的な方針ではなく、個人としての観点です。 自分誰よ とある企業で採用の一次面接に呼ばれたりする現場のエンジニアです。 Javaエンジニアです。Scalaもたまに書いてました。 転職回数は片手では足りないくらいの回数をしています。 最近はエンジニアマネジメントの比重が多く、ほとんどコード書いてないです。 コードは書いていませんがレビューや調査では読んだりします。 アーキテクチャ、フレームワーク選定、インフラ方針などの決定権は持っていて、 ビジネスバランスを取りながら実装の方針などを決めます。 採用面接官のエンジニアは現場エンジニアが多い 人事によるピックアップとは別 前提として技術力はエンジニアしか判断できないと思っています。 でも、採
その「エンジニア採用」が不幸を生む ～良い人材を見つけ、活躍してもらうには何が必要か？
Google在籍時も、現職のスタートアップでも、技術者の採用には苦労している。正直、Googleでの苦労はぜいたくだったと思う。知名度は抜群で、多くのエンジニアの憧れの的だ。だが、高いハードルの元、Googleの基準に達する人はそう多くはない。優秀な人は現状でも魅力あるポジションでやりがいのある仕事についている。収入を含む待遇も悪くない。そのような人にどのようにして転職を考えてもらうかが悩みのタネだった。 現職はプログラマー向けサービスをやっているだけあり、知名度はある。業界で名のしれたエンジニアがいることもあり、Web系エンジニアからはそこそこ評価されているようだ。だが、採用には苦労している。応募も少なく、採用まで至る人はその中でもわずかだ。 私は自社以外のスタートアップの技術顧問やアドバイザーをやっている関係で、他社の状況も良くわかるのだが、どこも似たような状態だ。Facebookなど
転職する時に必ずチェックしたい募集要項 - Qiita
転職 Advent Calendar こんにちは、 @ma3tk です。 この記事は 転職（その２） Advent Calendar 2016 の 15日目の記事です。 みなさん転職された時のお話が多いですが、本日はちょっとまた違った視点で「いい会社かどうかを見分けるためにどうするべきか」について書きたいと思います！ 後ほど見分けるためのチェックリストも記載しています。 いい会社かどうか この記事を読まれてる方は多分 Web 系の方が多く、ご自身や周りの同僚が転職する機会が多いのではないかなと思います。 知人の紹介で転職される方だと信頼関係があって魅力も伝わりやすく採用される率も高いケースが多いですね。 そうでない場合、「エージェント経由」or 「求人が載ってるサイトを巡る」などで、多数ある企業から絞り込んでいくと思いますが、これって相当大変ですよね。 「会社の名前を聞いてもぶっちゃけ知ら
優秀なエンジニアを採用するために面接で気をつけていること - UUUMエンジニアブログ
おはこんばんちは!! 尾藤 a.k.a. BTOでっす UUUM では僭越ながら CTO をさせてもらってマッスル。 なので UUUM でのエンジニアの面接は僕がやっているんですが、面接の時に気をつけていること、やっていることをご紹介したいと思います。 最初に会社の紹介をする 何はなくともまずはこれ。 転職活動中の方に、UUUM を選んでもらわなければ来てもらえません。 特に UUUM は YouTuber のプロダクションとしてのイメージが強く、エンジニアには馴染みがありません。 システム開発や、新規事業の立ち上げをしていることも知らない方が多いかなと思います。 なので、最初に会社に紹介をして、UUUM に入社することの魅力を感じてもらう努力をします。 実は最初の頃は技術面接をメインにやってて、会社の紹介をあまりやってこなかったために、最終選考に残るものの、最終的に別会社に転職されるケー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ushironoko.me