[感想]コーディング面接にどう備えたらいいか全然わからないし、そもそも自分が何がわからないのか全然わからないけど一歩踏み出してみた
はじめに
結論、このブログは「うだうだ悩んで、答えを出せなかった」というポエムですのでご了承ください。
-
あなたは誰?
- katoakiといいます。AWSが好きなソフトウェアエンジニアです(ソフトウェアエンジニア歴2.5年/IT業界12年)
-
年齢
- 私は今30台中盤です。
-
悩みは何か
- コーディング面接対策、何をどうしたらいいかわからなくなった。
-
悩んだきっかけ
- コロナがきっかけでキャリアプランを見直したことです。
- 最近働き方増えて、カスタマーフェイシングな業務もあるけどフルリモート/一部リモート可とか見つけたし、社内でもそういう部署があったのを見つけたので転部チャレンジもありかもなと思ったことです。
-
目指す姿
- 目指しているのはクラウド系のアーキテクトです。
-
目指す姿(やる・やら)
- 最終的には、経営とか事業は諦めて人に任せて、「クライアントと話す力」「技術力」を両立し、主にモダンな技術で事業会社の課題解決をサポートするプロとして、中長期的に日本の中で最も価値を出しつづけそうなポジションに立つことを目指すことにしてます。
- そのためには、「インターネットが壊れました、なんか強くしてください。」みたいなお客様に向き合うことも厭わないし、逆にパフォーマンスを追求する部分は強い人にお願いしに行く、みたいな。ふわっとしてるけど。。
-
なんで目指すの
- なぜなら、自分は人と話すのは好き。
- その上で…
- 技術面ではGitHubでスターとか全然ないし、
- アカデミックなバックグラウンドもないし
- けど強いて言えばちょいとフロントエンドできるので、スクラッチで小規模なコーポレートサイトは作れるくらいである。
- つまり積み上げてきたものがほぼ無いのです。
- だからこそトレンドが変わりまくるクラウドやフロントの最新トピックに時間を投機することになんの抵抗もない(ブログで利確する、自分の株上がる、的なメリット感で続いてる)。なのであえて学習コストの高い分野で攻めていこうという試みであります。これがいいのかわからないけど。。
-
スキルと経験いかほどか
SIer6年→4年間のWEBディレクション経験→直近2.5年間のSaaS開発の経験があります。- でも、特に後者については実際は優秀な同僚にペアプロでフリーライドせざるを得ないし、MDNやAWSのドキュメントや自分や人のブログから情報をスクラップしてアレンジしてなんとか継ぎ接ぎしているような状況なので、「todo管理アプリを作って見せてください」みたいなのが出てきたらまずググりますし、「最適な方法でアルゴリズム・データ構造をチョイスしてください」みたいな問題に直面すると固まってしまいそうです。がこれじゃ実力不足であろう。。
-
なんでコーディング面接で悩んでんの
- 社内異動を考え初めてみています。お客様と窓口もしながらコーディングバリバリやってる部署に
- そのため、次のステップでは間違いなく「コーディング面接」が行われるであろう。というかむしろやってほしいと考えています。なぜなら、ちょろまかして入るよりも、現状のフィット&ギャップを図り、足りないところはこれから時間を掛けて補おうとしているためである。(異動の延期)
-
今日まで何してたんだ?これから何するの?
- ってのを次のセクションから書きます
やってみたこと
このブログを書き始めてから3日目たちました。やったことは以下です。
1日目〜3日目
- コーディング面接とは、について時間区切って立場(受験者・面)関係なく情報を集めまくってみる
- とりあえずコードを描いてみる
- (コーディング面接官のペルソナを仮定し)これならできそうだ、という課題をセットして。
- 頭の中をブログに書いてみる←いまここ
ちなみにこれからこんなことをやる予定。たぶん具体的すぎる話になっちゃうのでブログにしないかも。
4日目
- コーディング面接やってる人に話を聞いてみる
- 想像で面接官の立場に立ってみる
- 今後のアクションを考える
5日目〜
- 決めたアクションを実行してみる
コーディング面接とは、について時間区切って立場(受験者・面接官)関係なく情報を集めまくってみた
とりあえず、トレンド関係なく「コーディング面接とは」でググってTop10に出てきた記事を雑に全部見てみる
- コーディング面接の例 - soutaroブログ https://soutaro.hatenablog.com/entry/2015/06/21/174042
- [エンジニア転職] コーディング面接の内容・評価ポイント・対策方法 | Hackerdemy https://hackerdemy.com/2021/01/22/coding-interview/
- コーディング面接の対策方法と例題 - Yhei Web Design https://yhei-web-design.com/blogs/colum/how-to-work/how-to-codeing-interview/
- 世界で闘うプログラミング力を鍛える本 コーディング面接189問とその解法 | Gayle Laakmann McDowell, 岡田 佑一, 小林 啓倫 | キャリア | Kindleストア | Amazon https://www.amazon.co.jp/dp/B071GN3JN2/ref=dp-kindle-redirect
- leetcode時代の外資コーディング面接対策 - Qiita https://qiita.com/ktsujino/items/9cfa31dced5a68720485
- ソフトウェアエンジニアのスキルを測るには? コーディング面接の方法と、プログラミング力の測定と育成 (1/3):CodeZine(コードジン) https://codezine.jp/article/detail/14066
- プログラマの採用面接で聞かれる、データ構造とアルゴリズムに関する50以上の質問 | POSTD https://postd.cc/50-data-structure-and-algorithms-interview-questions-for-programmers/
- 付け焼き刃でサンフランシスコ・ベイエリアのコード面接を突破する方法 - ログミーTech https://logmi.jp/tech/articles/320600
- アルゴリズムのせいで面接に落ちた https://zenn.dev/rana_kualu/articles/efd74e8525ccab6c8474
- コーディング面接の練習を支援するシステムの構築 | IIS Lab / 東大矢谷研究室 https://iis-lab.org/research/coding-interview/
あとトレンド情報をざざーっとみて、関係ありそうなものを探してみる。
と、2021年10月28日の人気エントリーでたまたまコレだ、というのが見つかった(右下の右から2番目)
ソフトウェアエンジニア採用におけるコーディングテストのススメ - MAYAH https://mayah.jp/posts/2021/10/coding-test/
タイムリーで(古くなくて)、なおかつ一番内容がギュッとつまってて納得感もあったのがこの記事。
で、ここまでで時間切れ。
学びをピックアップ(あんまつよつよエンジニア向けじゃないやつ)して要約してみると・・・
- 「話はできる」のに初歩的なコーディングすらできない人がいるので、コーディング面接大事
-
https://codezine.jp/article/detail/14066?p=2
単純なループが書けなかったり、単純なif文も書けないというレベルで、どうやって今までコードを書いてきたのか非常に不思議なレベルです。このような、受け答えは良さそうなのに実際にはコードが書けない候補者は、私の過去の経験では、書類審査通過者のうち5%
-
- 一方で、あのHomebrewの開発者ですらGoogleのコーディング試験を通らなかったみたいな話もあり、職務上の能力と面接の評価は一致しないことがありそうという問題もある
- Googleのコーディング面接の動画があるので、みるとイメージ湧く
-
https://www.youtube.com/watch?v=XKu_SEDAykw
- なんか、うん、ギリギリできなそう。業務で直接的にはこんなことあんまやってないからー
- それに、この問題かなり簡単な方なんじゃないか?
-
https://www.youtube.com/watch?v=XKu_SEDAykw
- データ構造とかアルゴリズムに関して出されることがある
- そもそも、十分な前提知識が無いと詰む
- だと自分はもう詰んでるので、勉強すべし
- そもそも、十分な前提知識が無いと詰む
- あえてお題を当日まで決めずに、「アプローチ方法」を見る形式がある
- そこでは例えばLinked Listを書いてくださいとか、基礎アルゴリズム系の問題が出たりする。アルゴリズムそのものの知識も測れて合理的だね。
- いきなりコードを書くべからず
- コミュニケーション取りながら、制約事項などを整理する
- 途中で「ここなんでこうしたの?」みたいな意図は聞かれることもあるし、話す
- leetCodeで基礎的なテーマのコーディング面接問題が実戦形式で勉強できるみたい
- あんまりこういうのでハックするのはどうなんだろう、と思う人もいる。コーディング面接は手段であるので。
で、いま自分どうなんだろ?ってことで、とりあえずはleetCodeやってみました。
一番簡単そうな問題をピックアップして、とりあえずやってみました。
いわゆる「Two Sum」問題です。
結果これです。2時間くらいかかった。これ普通15分くらいで終わるんじゃないか。
/**
* @param {number[]} nums
* @param {number} target
* @return {number[]}
*/
var twoSum = function(nums, target) {
// nums = [ 2, 7, 11, 15 ]
// target = 9
// 少なくとも、配列の最初の値から順番に考えていけば、必要な計算式の組み合わせがもれなく出せる(ベストかどうかは不明)
// - 実際に手動で計算式を考えてみると次のようになる
// - 2+7, 2+11, 2+15, 7+11, 7+15, 11+15
for(let i = 0; i < nums.length; i++) {
// iは0, 1, 2, 3の場合がある
// nums.length-1回分、隣の数値との足し算をする必要がある。なぜなら
// - 実際に手動で考えてみると次のようになる
// - i=0( 2)の時: 3パターン num[i]+num[i+1] | num[i]+num[i+2] | num[i]+num[i+3]
// - i=1( 7)の時: 2パターン num[i]+num[i+1] | num[i]+num[i+2]
// - i=2(11)の時: 1パターン num[i]+num[i+1]
// - i=3(15)の時: 計算不要
// i+1, 1+2などの部分をパターン化すると、
for(let j=i+1; j<=nums.length-1; j++){
// console.log( nums[i] + "+" + nums[j] + "=" + parseInt(nums[i] + nums[j]));
let resultSum = nums[i] + nums[j];
if(resultSum === target){
console.log([i, j]);
return [i, j];
}
}
// let result = nums[i]+nums[i+1] ? console.log(nums[i]+nums[i+1]) : "";
// console.log(result);
}
};
コメントを見ると、弱者ぶりがよく伝わると思ったのであえて残してありますw
終わってから気づいたことがあります。
- 入力チェック漏れ
- nums
- 数値の配列以外が入ってきた場合
- 値がnullだった場合
- nums
- 場合分け漏れ
- 答えがなかった場合
- nullになっちゃうので、その場合は「答えがありません」ということを書いたほうが親切(答えは存在する、という前提条件ではあるけど)
- 答えがなかった場合
- 命名
- resultSumっていう変数名が気持ち悪い。resultなんて自明なので、sumで十分では?
- 計算量
- もしnumsに1億桁くらい入ってきたらループの途中でメモリがエラーになるのでは?その場合、予めnumsはさすがに10000つまで、みたいな仕様を決めて、それを超えたら「想定よりも入力が多すぎて処理できません」って出したほうが、もしこれを他と連携するときとかも考えると親切なのでは?少なくとも無限に受け入れるぜ!って作りにはなってないわけだよね。
- その他
- 何がわからないのかわからないけど、もっと良くなる気がする
ネットで調べたら色々改善ポイントは見つかるのでしょうが、とりあえず自分が自力で気づけた点だけ上げてみました。
なにがヤバいかって、何がわからないのかわからないことです。
とりあえずコードを描いてみる
やっぱり一般的に「コーディング面接、イケます」とは口が裂けても言えないことは分かったので、まずできることを探してみます。
とりあえず、以前こんな動画を出したのでNuxt.jsでフロントエンドのモックを作るとかはできます。
Nuxt.jsでSPAを実装してみた話 #devio2020 - YouTube https://www.youtube.com/watch?v=IkSRJFox-MY
なので、フレームワークとかをフル活用して、ミニマムでなるべくブラックボックスが少ない「todoアプリ」を作ってみることにしました。CDKとかちょっと使ってるし、ぎりぎりできそうなので。
ただ、始める前に一旦それに意味があることを仮定してみます。
- 面接官の所属会社は、事業会社の課題解決をサポートするプロとして「対人スキル」「実装スキル」を兼ね備えた人材を採用したい
- 「対人スキル」については、別途追求する
- 「実装スキル」については、会社が期待するフィージビリティスタディのインプットを作るスキルを図りたい。逆に言うと、特定領域のパフォーマンスを追求するためのコード改善というよりも、クイックにモックを作れるほうを重視する
- 会社は、割とモダンな技術が使える人物を増員したい。
- キャッチアップ力が強そうで、かつ基礎力があれば、ポテンシャル採用する
- いくら対人スキルがあっても採用で絶対避けたいことは次の通り
- ifとかforとかのコードが書けない人を採用する
- もはや、プログラムさせるより電卓と紙と根性でやったほうが早いレベルになっちゃってる。
- ITに関する基礎知識が少なすぎる
- 特定領域のパフォーマンスを追求するチームと共同するため、会話のベースとして基本的なソートアルゴリズムやデータ構造のバリエーションやメリデメなどを知っていないと、そういうケースが起こる度にコミュニケーションの無駄が生じるが故に、チームとしてのリードタイムが遅れる
- ウソをつく
- 替え玉とかの不正しちゃうとか
- ifとかforとかのコードが書けない人を採用する
ということで、自分が受験者として、ミニマムでなるべくブラックボックスが少ないtodoアプリを「30分縛り」でライブコーディングで作ってみました。
それについてはまた別途どこかにあげようかと思いますが、モックのREAD用APIをフロントエンドに繋いでろくにスタイリングもせずに出しただけ、くらいでおわってしまいました。。
30分縛りいらなかったかなぁ。これくらいで何かわかるんだろうか。やっぱり一人で答えを出すのは限界があるな。
最後に
3日間色々やってみたけど、進捗が見えない。自力で打開するの厳しそうなので、第三者に聞いてみて軌道修正しようと思います。
とりあえず、このもやもや感が誰かの悩みのヒントになれば幸いです。
Discussion
とある方にお話を聞いた所、次の結論が出た
・一旦ちゃんと数学について復習するのがよさそう
・データ構造やアルゴリズムについて重点的に学ぶのがよさそう
・LeetCodeとかの易しめのやつから続けてみるとよさそう
色々ヒアリングしてもらった結果、根本を見抜いてもらった気がする。
アルゴリズムでよく利用するような数学の基礎の部分って今の今までカバーされていない状態になっていないっぽい。私は高校の時から数学が苦手で、そこからノーアクションなので。
視座が高い人に見てもらうっていうのはとても有効ですね。なかなか得難いチャンスですが。
何を持って視座が高いとするかは主観でしか判断しがたい(自分の視点では)ですが、件の方はご経歴見ると明らかな感じでした。