  |
はてなキーワード: コーディングとは
コンピュータやプログラミングが好きで、その技術で以て社会に貢献したいと考えている人へ告ぐ。
日本のSIerなどに就職しても、給料以外に得るものなどない。だから、就職するな。
もし、コンピュータの技術で人の役に立ちたいと思うなら、オープンソースのプロジェクトに参加したり、本などを書いたりした方が良い（後者は一発当てると生活に不自由しない程度には稼げる）。
まず、世のSIerやPGに就職したところで、実質的に価値のあるソフトウェアを作ることは、まず無いと思っていい。
案件の大半は、コンピュータリテラシーの低い老人向けのクソ下らない業務システムなどだ。信じられないかも知れないが、「FAXと連動する」みたいなソフトウェアは、今も日本中で生産され続けている。
おまけに客自身が、そのシステムで実現したいことを本質的に理解してないから、従来紙の上でやっていたことを、そのままパソコンで行うだけのシステムを作ることになる。
ついでに言うと、SEやプログラマの仕事が設計やコーディング等の知的業務だと思ったら大間違いで、「客の送ってくるエクセルやパワポ資料の体裁を保ちながら、丸番号つきのスクリーンショットを追加する」みたいな下らない仕事が開発と同じくらいある。
あと、「IE9で動かない」とか「Firefoxで見たときだけテーブルの枠線が薄くなる」みたいな、本当にどうでもいい理由で既存のライブラリを利用せずに、フルスクラッチで書こうとする勢力が多数。
あと、日本の職業エンジニアのレベルは本当に低い。趣味でプログラミングを学んだその辺の学生の方がずっとレベルが高い。
まず、職業エンジニアのほとんどは、アルゴリズムとかオブジェクト指向設計とか、プログラムの性能や保守性に関わる知識を全然知らない。ハードウェア、データベース、ネットワーク、セキュリティ等のシステム運用に必要な情報技術の基礎知識を一通り知ってるエンジニアなんて、全体の1%もいない。
そもそも、業務で使っているプログラミング言語すらまともに勉強していない。「Effective ○○」みたいな本に書いてあるようなベストプラクティスをことごとく無視してクソコードを量産する。クソコードはそのプロダクトが死に絶えるまで残り続けて、改修のコストを指数関数的に増加させる。
下請けのゴミにもなると、ググって出てきたコードを意味もわからずコピペして「動かないんですけど」とか言ってくる。それでも仕事はある。
あと、ソースコードをバージョン管理していない会社すらわりと存在する。（「GitではなくSVNを使っている」とかいう意味ではない。文字通りバージョン管理していないのである）
こんなことは別にIT業界に限らないんだろうが、要はレベルの低い人ほど偉そうで、全体の足を引っ張っているわけである。
ここで言うレベルっていうのは、別にJavaやC++などを使いこなせることを意味してるわけじゃない。仕事の内容や目的をきちんと理解して、自立して仕事ができるかどうかだ。
お前んとこの独自フォーマットのエクセル出勤簿をシステムに取り込む機能が本当に必要なのか、よく考えて欲しい。あと、パソコンの使い方レベルの問い合わせを、開発者までたらい回しにしないで欲しい。本当に無駄でしかない。
私はみなさんがよく知っている某社でVPとして働いている。VPの仕事は多岐に渡るが、その中でもソフトウェアエンジニアの採用は最も重要な仕事の一つである。そんな中、弊社の採用対策として、特に新卒の学生の間で競技プログラミングというものが流行っているようである。これについて私の所属する部門での印象を述べる。
まず、身も蓋もないことをいってしまうと、少なくともうちの部門では新卒・中途関わらず競技プログラミングの知識はほぼ不要である。新卒のヘッドカウントは少なくなっているものの、大学でコンピュータサイエンスをしっかり学び、かつ自分で手を動かした経験がある人であればあとは人間性の問題である事が多い。弊社は選考の際にコーディングスキル、特に競技プログラミングのスキルを見ていると思われることが多いらしく、学生もその対策としてまるで受験勉強であるかのように取り組んでる人が多いという印象がある。弊社はそれなりに大きい会社であるため、中にはそのような目線で採用面接をする部門・エンジニアもいると思うが、少なくともうちのチームはコンピュータサイエンスの最低限の足切りをしたあとは一緒に働いて和を乱さないかを重視している。つまり、面接をしたエンジニアの単なる印象に近い（これをあからさまにいうと社内でも怒られるが、意外とそんなものである。）
これだけ聞くと弊社も一般の会社と変わらないのか・・・と思われるかもしれないが、これには色々理由がある。まずは私が見ている部門の話をしたい。
まず弊部門は革新的なプロダクトを次々開発するための「高速道路」が非常に整備されている。あまり詳しく言うことはできないが、例えばソフトウェアエンジニアであればGitHubやCircleCI、AWS、といったサービスを使って開発をしていると思う。これらの10年先を行っているインフラが社内で自由に、しかも誰でも使いやすいように整備されていると思って貰えればよい。これによってプログラミング経験がほとんどない人（といっても最低限の足切りはされていると思ってほしい）でもドキュメントやコードを参考にすることですぐにプロダクトとして出すことができるということである。これは逆に言えば競技プログラミングで青とか黄といった高度なプログラミングの技術力は必要ないということである。どちらかといえば社内に存在する膨大な技術資料を読み込み応用できる忍耐力と発想力、そしてわからないことは例え相手が英語があまり話せない人だったとしてもコミュケーションを厭わない対人能力のほうがはるかに重要である。これは社内の人材を評価をする際の統計データでも如実に現れている。
一方で実験的プロダクトや社内向けプロダクトを開発している部門おいては少々事情が違う。こちらはいわゆる「高速道路」が整備されていないためコードを1から書く必要がある。こういう場所では競技プログラミングといった高度なプログラミングの技術力を持つ人が多数活躍している。完全にリサーチャーとまではいかないものの、半分リサーチャー、半分エンジニアといった感じの仕事になっていることが多いと思う。そのような部門では驚くべきことに「Gitの使い方がわからない」といった人まで存在する。だがしかしそれを圧倒する実績を保有しているか、または現在発揮中のいずれかである。ただ弊社も大企業になって久しいためこのようなポジションはだんだん減少傾向にある。競技プログラミングで赤や黄であり高度なアルゴリズムを開発するポジションを希望するという人は常に一定数いるが、正直採用されることは困難というイメージである。どちらかと言うとこのような部門は優秀な人を引きつけるための広告塔として機能していると思ったほうがよい。実際に採用されるエンジニアの大半は弊部門のような泥臭い作業を任されることがほとんどである。
最後に個人的な主観を述べておく。これはあくまでも私の周辺だけの話ではあるが（とはいえVPではあるのでみなさんが思うよりは広いと思う）、10年以上前に入社した人はいわゆるプログラミングガチ勢が多かったように思う。しかし今採用されている人はそのような一点特価型はほぼいなくなり、技術力やコミュケーション力を含めたオールラウンダーが増えてきた。これはあくまでも想像であるが、現在シニアエンジニアとして活躍しているような人材は技術力はかなり高いものの、やはりコミュケーション力や忍耐力といった点で難点のある人が多い。そのため、ジュニアとして採用するエンジニアはそういった人材とチームを組めるだけのコミュケーション力や忍耐力が要求されることになる。一方で技術力に関していえば社内で独自開発するよりは、外部から会社ごと買ってくるほうが簡単である。という意味でやはり求められているのはすべての面において難点がないことなのである。これは会社の規模に応じた必要不可欠な変化であると考えられるし、また弊社は外資の中ではクビになりにくい体制であるというのも大きいだろう。
【21新卒SWE】 私はこうしてGoogleに落ちた ~Googleに挑んだ120日~
https://note.com/grouse324/n/n1f329de5ee50
Google特定じゃなくてこの業界の一般的な流れなんですが。
もともとコーディング面接って、特定の技術分野に強い人じゃなくて、何でもできるポテンシャルの高い人を採用するための手段として使われてきたんですよね。
それが機能していた時代(10年くらい前？)は、競技プログラミングやそれに類する経験のない人のほうが多数で、そういう人たちが競プロ的な課題をその場で解いたり議論してたりしてたんですよ。
ところがその後、競技プログラミング勢が増えてきたことによる弊害が明らかになります。というのも、彼らの競技プログラミング勢の入社後のパフォーマンスが明らかに低い。そりゃそうですよね、予習なしで面接課題を解ける人たちと、予習込みでないと解けなかった人たちとでは、前者のほうが優秀に決まってる。
しかし、時既に遅し。それが明らかになった頃には、いろんなソフトを書いてきた優秀なプログラマではなく、競技プログラミングに特化したアスリートばかりが入社するようになってしまっていました(というのは言い過ぎで、超超優秀な人たちはソフトも書けるし競技プログラミングでも優秀だから、そういう人たちは入社後も活躍している)。
事態を更に悪化させたのが、LeetCodeやモックインタビュー等によるコーディング面接対策サービスの勃興でした。コーディング面接に特化した訓練を積んだ面接者が激増した結果、エンジニアとしては十分優秀なのに面接訓練を積んでこなかった人が面接に非常に通りにくくなるという現状が生まれてしまいました。
もちろん各社この状況は十分認識していて、さまざまな試行錯誤が行われている状況です。ですが、これといった対策は未だに生み出されていないようです。
どうすればいいんでしょうね？
使い道含めて理解してる？
要するに前のプロジェクトはパワーコーディングで作っていった結果、収拾できなくなってしまったんでしょう？
抽象化というのはそのまんま情報の簡略化であり、情報を簡略化するには綺麗なコードじゃないと無理なんだよ。
綺麗なコードは各々のオブジェクトが持つべき役割・持つべきではない役割が明確化されており、綺麗なコードというのはコードコメントがなくても他者が理解できるようになっている。コード自体が処理の説明がなされているんだよ。
もう一つ、あなたのプロジェクト構成はちゃんとレイヤー化されている？
新しいクラスファイルを配置する時、明確なルールが作られている？
とはいえ、誰しもが最初から全てを理解しているわけじゃない。みんなあなたのように「やらかして」反省して、同じ徹を踏まないように次のコードで反映させていくのだから。
旦那のグループLINEに回ってきた、町内の育成会の人が作ったらしいチラシに、とてつもない敗北感を覚えた。
田んぼと畑と寂れた神社しかない典型的など田舎の自治体の草むしり写真が、よくぞここまで加工したな！と感心するくらいの美しいグリーンに囲まれた自然風景に。
しかも写真を装飾するデザインがまた、シャレオツとしか言いようのない出来で。
web制作会社に2ケタの年数勤めてもデザインの4文字とは無縁のせいでコーディングしかできないお荷物コーダーには、色々と刺激的だった。
学生時代、5教科の成績も良くはなかったけど（特に理数系は壊滅的）、更に悪かったのが書道に図工に家庭科に音楽に保健体育。（音楽はリコーダーのみ）
「私ぃ、5教科以外だけ成績良いんだよね！」というよくある自虐が、本気で自慢にしか聞こえないくらい。
ピアノを3〜4年習ってもバイエル卒業できず、中学校では美術部・高校の選択授業では美術を選んでも尚画力もデザイン力も学年ビリ。
中学校の生花クラブなんて、毎回毎回先生に「全部」無言で生け直しされ、何が良いとも悪いともアドバイスさえもらえなかったっけ。（ちなみに他の生徒はアドバイス交えて少し手直しされる程度だった）
成人して、親の美術館通いに時々付き合うようになり、その現象にも納得した。
絵でも彫刻でも、何なら水族館の魚でも、本っ当になんの感想も浮かばないのだ。
何か感じるものが見つかれば、と思いつつ眺めはするものの、心の中ではFacebookの「いいね」を連打しているだけ。
綺麗だとは思うものの、何が綺麗とかどの部分が印象に残ったとか、人に語れる具体的なものが一文字もない。
そりゃ、理解できないのに生み出せるはずないわな。
当方、プログラマです。私は独学でプログラミングを学び今もプログラマでお仕事しています。
休日にも勉強されているのは良いことですね。業種によっては理系的な知識が必要になりますが、必須ではないです。
昔はそういうのもあったらしいし、金融系とかだと設計書通りにバッチコマンド書くだけみたいな仕事もあったりするみたいね
私のチームではアジャイル開発を採用しているからむしろクライアントの要望（仕様）を明確化し、設計を考えてコーディングを行っているので、とてもじゃないが思考停止で仕事が回るようなものではないね。
・用意されているAIをColaboratry(Googleの無料貸し出しPC)上で5秒で動かす。
データサイエンスVtuberに相談する。
・初心者向け動画講義まとめ
1. 【世界で18万人が受講】実践Pythonデータサイエンス | Udemy
2. Machine Learning by Stanford University | Coursera
3. Eラーニング教材・講義動画配信 | 数理・データサイエンス教育強化拠点コンソーシアム
- データハンドリングなどの入門者講座はUdemy の方が良いが、時系列解析・データ活用講座に関してはこれより良い教材は無い。
- 多分、動画の[1,2,3]を理解していてコードが書けて、学歴があるならTier4 のインターン・バイトは受かる。
4. DeepMind x UCL | Deep Learning Lecture Series 2020 | Youtube
- Deep Learning 講座、タイトル通り
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
530あとで/4137users NTT フレッツ光における通信速度などの現状について、背景や仕組みから正しく理解する 2020 - diary.sorah
304あとで/1974users 高等学校情報科「情報Ⅱ」教員研修用教材(本編)：文部科学省
204あとで/2230users iPhoneでの料理撮影が苦手なライターがカメラマンに論理的に指導を受けた結果→憂鬱な撮影が楽しくなった - メシ通 | ホットペッパーグルメ
202あとで/1706users 天才プログラマーの「締切に対する考え方」に、感銘を受けた。 | Books&Apps
177あとで/1946users ネットワークエンジニアとして | www.infraexpert.com
170あとで/1064users 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
169あとで/826users 7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
168あとで/1180users ローカル開発環境の https 化 | blog.jxck.io
166あとで/1005users ソースコードブランチ管理のパターン | Martin Fowler's Bliki (ja)
164あとで/991users 大学に行かずにコンピュータサイエンスを学ぶときに優れている教科書や講義映像はどんなものがあるのか？ - GIGAZINE
164あとで/1541users 衝撃の結末が話題 無名ラッパーが投稿したYouTube動画が異例の48万再生、投稿者と大学側を取材 - ねとらぼ
161あとで/1789users 無印良品によるサーキュレーターの季節別の活用方法が有益すぎる→早速効果を実感する人も「部屋が快適…！」 - Togetter
147あとで/2111users 批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
143あとで/809users データベース設計の際に気をつけていること - 食べチョク開発者ブログ
142あとで/731users Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
136あとで/1777users 「言い切る人」が強すぎる。 | Books&Apps
129あとで/1655users iPhoneのNFCシールでの自動化が便利すぎてシール貼りまくった – ごりゅご.com
129あとで/616users 良いコードを書くための8つの習慣 - New Relic公式ブログ
128あとで/1164users GAFAコーディング面接こんな感じでした - yambe2002’s diary
126あとで/1345users 無料で美麗な絵画やカオスなポスターなどがダウンロードし放題、編集や商用利用も可能な「Artvee」が登場 - GIGAZINE
125あとで/687users デザイン脳を鍛える方法｜ハラ ヒロシ｜note
125あとで/993users １からイラストの勉強をした話｜せたも｜note
124あとで/608users Dockerとはどういったものなのか、めちゃくちゃ丁寧に説明してみる - Qiita
124あとで/992users Web制作の常識が変わる、便利な最新オンラインツール48個まとめ - PhotoshopVIP
121あとで/1091users なぜ、国ごとに差が出たのか。そして第二波がどうなるか。 - 楽園はこちら側
119あとで/1321users アメリカの美大で学んだこと05:「絵がうまい」より大切なこと｜Kenta Shimbo｜note
119あとで/1684users 自民系の地方議員です。カネ配りについて書きます。 | はてな匿名ダイアリー
118あとで/1444users 料理に対するモチベーション「ゼロ」のぼくがたどり着いた、これだけで料理が簡単＆美味しくなる調味料 - ソレドコ
118あとで/1195users 視座の可視化｜kgmyshin｜note
116あとで/1224users 【公式】ぷよぷよeスポーツ×プログラミング | SEGA
あとで読むタグの数が1月に近いレベルまで大幅に反発、増加した。
一昨日ホットエントリを選択するアルゴリズムが変わったというアナウンスがあったが、影響を受けているかどうかは不明。
特定防止に色々ボカして書いているため、情報量が少ないのをご容赦願う。
必ずしもADHD全般に当てはまる特徴ではないかもしれないが、私は元々調子の波が激しい人間である。それは『日ごと』のレベルもあれば『5分単位』まで様々である。それゆえに、『決まった時刻から』『決まった時間内に集中して課題をこなす』というのが非常に苦手である。こんなことを書くとすぐにでも「大学の試験とかも全部そうだろ」という指摘が飛んできそうであるし、全く正しい。実際、過去に私が単位を落とす理由でもあった。(脚注1)
しかし、それでも苦手なりになんとか考え、特にADHDの治療開始後は
等の工夫をすることで、本来はアンコントローラブルな調子の波をどうにか本番に合わせてきた。
これだけの工夫してもなお、苦痛であることに変わりはない。とはいえ、これは1年のうちのたかだが4回ないし8回程度の試験期間だけどうにか行っていたことである。
しかし、競プロではそれが毎週のように課される。断続的に『調子の波を本番に合わせる』タスクを行うことは、大げさに言えば精神的な自傷行為のようなものであった。
まず、競プロが総合的に『楽しい』と思っているならば全く問題ない。ぜひ続けてほしい。
競プロに対して不安や苦痛を感じてる人達は一度、自分なりの競プロとの付き合い方を考えてみると良いかもしれない。
『趣味で始めたけど今はちょっと……』という人は、しばし距離を置いて競プロを休んでみたらどうだろう。少し胸のつっかえが取れたらまた楽しく参加できるかもしれないし、他の趣味(CTFとか、特に関係ない娯楽全般)に出会うこともあるかもしれない。
これは私の偏見だが、『競プロの成果がなければ就職できない 』かつ『競プロの成果があれば就職できる』という必要十分なケースはそう多くないと思う。潜在的にでも競プロの成果を出せる人は、大学(院)の研究なり講義で学んだ内容なり、何かしら他の方法でそのコーディング力や数学的・論理的思考能力をアピールできないだろうか。逆に、それらを評価できない程度の採用担当者が『競プロ』という物をそもそも評価できるのかとも思う。大学との両立に悩むのなら、やはり競プロを休止して大学の学習や課題に専念するのもアリだと思う。
当記事に対し競プロ関係者などから怒られが発生した場合、当記事は予告なく消滅する場合があります。
ぼく「こんにちは、ベン。ぼくはWashlet2000。便意はどう？」
面「超いい感じだよ。きみは？」
ぼ「ぼくも超いい感じさ」
面「それはよかった。わたしは部署AのToiletエンジニアで3年目なんだ。社内ツールを作ってるよ。Benki関係のツールで、超クールでExcitingなやつなんだ」
ぼ「それはクールだね」
ぼ「うん。ぼくは経験豊富な自宅警備員で…〇〇で貢献して…リーダー経験が……」
面「Cool（たぶん聴いてない）。じゃ、問題に入ろうか。わたしからの問題はね…」
ぼ「あ、はい」
ぼ「Unkの管理…」
面「そう。Unkってさ、知的生命体でしょ？あれを実現するの。『分裂』もあるから注意して」
ぼ「なるほど。えーと、それはHankeyみたいな普通のUnkだよね。えーとえーと」
面「…」
ぼ「えーと、そうだ、Unicodeとか決まってる？」
面「決まってるよ。U+1F4A9」
ぼ「うーん。じゃあUnkって何を保持したらいい？種類、個数？」
面「いい匂いだね。ここでは簡単のため、そうだね、個数だけにしようか」
ぼ「ならUnkの個数を持つ感じかな」
面「多分そうだね」
ぼ「えーと、そして、『分裂』のときに増える個数、『消滅』したかどうかを返すAPIが要る」
面「うん。あと新しいUnkが産声を上げたときも」
ぼ「そうだね。じゃあ内部的には、分裂した時の増殖個数を計算して、unkで現在の個数を管理する感じかな…」
面「それで行けそう？」
ぼ「待って。それで、APIはdivision()、roar()、isDead()でいい？」
面「うん、そうだね。とりあえずAPIはそれで良いよ」
ぼ「OK。あ、division()でもうそれ以上増えれないときには、どうする？」
面「それもいい匂いだ。そうだね、今の個数を返すようにしようか」
ぼ「あと何かあるかな…」
面「…」
ぼ「Unkだと、大腸菌を表示したり、そこからBenkiにジャンプしたりできるけど…」
面「あとで必要になるかもね」
ぼ「だよね。速度は…当然すべてO(1)でやらないといけない」
面「速いほうがいいね」
ぼ「あとは、えーと、Benkiクリアもあとで付けそうだな。まあこれは簡単か」
面「そうだね」
ぼ「まとめると、Unkの個数を整数のIntで持ち、unkで管理する。division()が呼ばれたら、分裂して、isDead()が呼ばれたら、生存の真偽を返す。分裂時にはroar()を呼び出して、Unkoooooooooo!×(増殖個数分)産声をあげる」
面「それで良さそう？」
ぼ「うーん、多分…なにかあるかな…」
面「『消滅』を何度かしたあと、『分裂』をしたらどうなる？」
ぼ「ん？……あ、だめだ！そうか、『消滅』『消滅』『分裂』で過去の個数うんこに増えてしまう！つまり、isDead()が真なら、その時のunkを初期化しないと！」
面「そう！ならどうする？」
ぼ「うーん。変数maxUnkを足せばいいかな。isDead()はmaxUnkより大きな場合は真。そのときはunkを初期化する」
面「なるほど。大丈夫そうだね」
ぼ「あとはOKかな？…よし、じゃあコード書いてみるよ（マーカーを手に取る）」
ぼ「まずクラス外観はこんな感じかな…（カキカキ）」
class Unk: def __init__(self): pass def division(self): pass def roar(self): pass def isDead(self): pass
面「ん？これ何の言語？」
ぼ「pyてょnだよ。ぼくはpyてょn使いなんだ（自己紹介で言ったけど…）」
面「Cool」
ぼ「そして、Unkの個数を整数で持つよ。名前はunkでいいか」
面「OK」
ぼ「それと有効な最大unk数を保持するmaxUnkが要るね」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): pass def roar(self): pass def isDead(self): pass
面「なんでunkを1で初期化したの？」
ぼ「これは『いまの個数』だから。初めは１つのUnkが存在するのを想定してる」
面「なるほど」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): self.unk = self.unk*2 def roar(self): print("Unkoooooooo! ×", self.unk//2) def isDead(self): return self.unk > self.maxUnk
ぼ「division()、roar()、isDead()も書くとこんな感じかな…」
面「増殖の計算は２倍したんだね」
ぼ「そう。ちょっと手動テストしてみるね…。えーとunkが無いときのdivision()、roar()は大丈夫そうかな…。初回のdivision()でunkのサイズが1になって…そのあとroar()したら…isDead()は……」
unk = Unk() while True: if not unk.isDead(): unk.division() unk.roar() else: break --- Unkoooooooo! × 1 Unkoooooooo! × 2 Unkoooooooo! × 4 Unkoooooooo! × 8 Unkoooooooo! × 16 Unkoooooooo! × 32 Unkoooooooo! × 64 Unkoooooooo! × 128 Unkoooooooo! × 256 Unkoooooooo! × 512 Unkoooooooo! × 1024
面「大丈夫そう？」
ぼ「うん…たぶん…」
面「じゃいくつか聞くよ」
職業上の秘密を言えば ひとそれぞれ間違い防止でこううつ みたいなマイルールを持っているプログラマーは多い。
そのマイルールコーディングを正面から邪魔しているということはプログラマーではないんだろう ２０年以上のチーム開発の経験を持つ
私は21年の新卒であり、志望分野はWeb系のプログラマだった。
選考を受けた各社に関してその選考フローと所感について述べる。
昨年2ヶ月間インターンシップに参加した。
エントリーシートの提出、技術問題 (コーディング2問、作文1問 制限時間60分)。
コーディング問題は1問目が簡単なもの、2問目が少し複雑なもの。
競プロ的なアルゴリズム力が求められるものではなく、HTTPリクエストに関する基礎的な知識が要求される。難易度は高くはない。
日本語力が要求されるわけではなく、字数制限なども特にない (あったかも)。
当該分野に造詣が深ければ無限に書けるし、なければ書けない。
人事担当のエンジニア*2との (オンライン/オフライン) 面接 (60分)。
オーソドックスな質疑応答の他、提出した技術問題のコードや作文の内容に関する聞き取りなどもある。
ここで落ちた。
CEO、シニアエンジニア、新卒エンジニアなどを交えての面接 (らしい)。
1次面接の面接官の片方が、インターン参加時のメンターの1人だった。
面接の1週間前に面接官のTwitterアカウントをブロックしたのが悪かったのかもしれない。
「(技術力が基準以上あるのは前提として) その水準の如何よりはむしろ勤労意欲の有無を重視する」みたいなことを言われた。
インターンの成果報告をD社の技術ブログに書いたが、腹がたったのでそれを削除しようかと思った。
ここのサービスは二度と使わない。
Ruby本体にコントリビュートした経験があったのでそれをアピールできるかもしれないという意図で受けた。
エントリーシートの提出。
ここで落ちた。
落ちたので知らんが同社を受けた知り合いによると5次まであるらしい。
1次面接の際に「何がしたいのかわからん (意訳)」みたいなことを言われた。
何がしたいのかと言われれば労働がしたくない。
また「勤労意欲の有無を重視する」みたいなことを言われたのでまあそういうこと。
ここのサービスは二度と使わない。
Web系。
前述2社を落ちたあと2週間くらいなにもやる気が起きなかったが、ここなら受かりそうな気がしたので受けた。
エントリーシートの提出。
シニアエンジニア*2との (オンライン/オフライン) 技術面接 (60分)。
自分の関わったプロジェクト (分野問わず) のソースコードを提出するよう求められ、当日はそれに関したディスカッションを行った。
人事、CTO、その他社員を交えたオフラインでの面談 (60分)。
内定。
Web系。
I社と同時にエントリーシートを提出した。
エントリーシートの提出、技術問題 (コーディング3問 制限時間60分)。
人事との面接 (45分)。
内定。
2次面接の際にインターンに参加しないかという打診があったが、D社に落ちた経験がトラウマになっていたので断った。
人事担当者の意思決定が全体的に遅い印象があり、特にCOVID-19や緊急事態宣言のために3次面接と最終面接との間が3ヶ月空くことになった。
複数の退職エントリに書かれている内容に関して、その真偽を社員にたずねたところすべて事実であるという証言が得られたためエントリーを取り下げた。
エントリーシートを提出したところ人事から企業説明会の案内が届いたが、その宛名が全く知らない人間の名前だった (おそらくコピペミス)。
I社を辞退し、O社の内定を承諾した。
D社・N社に落ちた経験から、同輩および後輩に対しては確固とした「「「勤労意欲」」」を持つことをおすすめする。また、面接担当者のTwitterアカウントはブロックするべきでない。
この度web系（詳細にはフロントエンドエンジニア）を辞めることにした。よりによってこのご時勢で…というのは承知で。
小さい頃からPCで何かをするのが好きで大学でもそっちの方向に進み、web系の会社に勤めてきたのだが30のオッサンになって「どうも俺はコードを書くのは好きじゃないっぽいな…？」とようやく気づいたのだ。
振り返ると新しいプログラミング言語やフレームワークの情報収集をするのもイヤイヤやっていた。なまじコードが書けたり読めはするので「仕事が進められる」ことと「仕事の内容が好き」であることを錯覚していたのだ。しかしある日急に限界を迎えた。「あ、多分もうweb（特にフロント）はイヤイヤじゃついて行けないな」と確信して数ヶ月考えた末に辞めた。
年収ダウンも承知の上で、好きこのんでやっていけそうなホビー系に転職することにした。PCは使うがコーディングではなくモデリング等で日頃からそういう趣味をやっていたのも幸いし、割とスムーズに次のところは決まった。おもちゃに関わるものと思って頂いてそんなにハズレていないと思われる。
で、転職活動中に色々ググっていて思ったのがwebエンジニア『に』転職する系の記事はめちゃくちゃ大量にヒットするのにwebエンジニア『から』の転職の記事はそんなに見当たらなかった。これからの日本はエンジニアが不足するからエンジニアを増やしたいという流れの逆なので当然の成り行きなのかもしれないけど…
まあそんな事情はさておき、コレを見ている「web業界から別の業界に転職したよ」ってみなさん 今どういう業界にいますか？
