個人用メモ: 面接対策
2次面接の日程が決まった。泣いても笑ってもこれで最後だという。しかも2時間を予定されている。面接まではまだ数日あるが、今から緊張で体の不調を感じるほどだ。この俺がこんな緊張することがあるとは。会社で先輩と話す時もLTで大勢の前で話す時も図太かった俺が。
少しでも安心するため、エージェントの方から教えて貰った想定質問集の回答を箇条書きで用意してみる。多分コピペだろうが、中には実際に用意しておいたほうがいいと感じたものも多かったので回答した。技術的な知識を確認する質問や相手のサービスそのものに関する質問は調べながら書いたため、結構時間がかかった。勉強会のネタとしては意外にふさわしかったのではないか。(土曜のもくもく会を利用して記事を書いた)
一部、内容が重複していたり、相手の企業名が直接書いてあったりしたので、そこは編集した。また、「退職してから何をしていたか」など明らかに条件に該当しない質問も削除した。
- 志望動機
- エンジニアとしてプログラムに触れる機会を増やす
- Rails, JavaScriptなどの最新技術を勉強できそう
- 自分のエンジニアとしての価値を試したい
- 転職理由
- 今の会社での業務が書類作成や打ち合わせの実施に時間を取られコーディングをあまりせず、また今後人員や費用の調整が多くなってくるためエンジニアとしてのキャリアに不安を感じた
- プログラムを変更するのに顧客の承認が必要であったり、付随するドキュメントが数多く必要であったり、またテスト作業を人手で行うべきというプロジェクトの方針に不自由さを感じた
- やりたいこと
- プログラマとして機能の開発や改善に携わりたい
- 最新技術を勉強したい
- タスク管理や雰囲気作りなど、マネジメントの方向でも貢献したい
- 周りから自分のここが認めらなかったと思うこと
- プログラムの改善提案をしても、テストが大変になるだったり承認が必須だったり機能に不足はないだったりで却下されることが多々あった
- そもそもプログラムを作る機会が少なく、今まで勉強してきたコンピュータサイエンスの知識を全体的に活かせていない
- 周りから自分のここが認められたと思うこと ※3:7 位で技術:エンジニアとしての心構えみたいなやりとりが多いです。
- 文章作成やプレゼンテーションはおおむね高評価
- ログやDBの分析調査など計算が必要なシーンで、正確かつ早く結果を出した
- スクラムの手法を用いてタスクを整理し、メンバーが安心して仕事に取り組めるようにした
- チームで仕事をしている時に気をつけていることはなにか。
- HTTPリクエストから、HTTPレスポンスを返すまでに行われるコンピュータの仕組みについて、話してください。
- 分散システムを構築するにあたり、注意することはなにか。
- 分散コンピューティング、という認識か?
- 多数の端末を介するため、セキュリティ面で脆弱になりやすい
- 分散・集計処理に時間がかかり、却って性能が落ちる可能性がある
- sessionの保存の仕方と役割
- ブラウザにCookieを用いて保存する手法が一般的
- 本来ステートレスであるHTTP通信に保存できる情報を付加することができる
- セキュリティ上問題ない場合は、リクエストURLパラメータに含めることもある
- DBのインデックスの設定の仕方
- create table (インデックス名 型 primary key, …)
- ALTER TABLE table_name ADD [ CONSTRAINT primary_key_name ] PRIMARY KEY (col_name, colname2 ..) ;
- って感じかなあ、聞かれるかどうか分からんが
- どんな開発に携わってきたか?
- 開発はどれくらい出来るのか?
- Railsを使ったシンプルなアプリなら3時間程度でリリースできる(面白いかどうかは別として)
- どれくらいっていうのは、例えば?
- rails を使った時に困った事は?
- 最近どんな技術を勉強しているか?
- Ruby on Railsを休日や業務後の時間を利用して勉強を進めている。
- 競技プログラミングサイトで数学問題をRubyで解くことで、Rubyの文法と数学のスキルを勉強しなおす
- 何かフレームワークを使った事があるか?
- Struts2 (業務経験あり)
- Ruby on Rails (趣味)
- Django (学生の頃のアルバイト。求人票を見る限り、意外に採用している企業は多いようだ)
- 弊社サービスの改善点(ちゃんと使い込んでないと回答できない)
- チームの人数が増えてきた時にどんな工夫をして上手く回すか?
- スクラムの手法を活用する。ストーリー・タスクを定義し決められたスプリントで消化するために検討を重ねる
- 人数が多い時はチームを分割(4〜7人)する。チーム間の干渉は多ければいいというものでもない
- 当日の割り込み作業が発生しないよう交渉する。期日と目標を聞き出し、日中の依頼はなるべく翌日に回せないか交渉する
- 小さなチームの集まりで開発を進める際のメリット・デメリットは何だと思いますか?
- メリット
- タスクの管理がしやすい
- チームの合意が早いため開発のスピードも速い
- メンバーの個性を生かして、各自のみでは作り出せないサービスをチームとして開発できる
- デメリット
- 量が多い問題に対しては不向き
- 新しいメンバーに対する教育が不十分になりがち
- 事故でメンバーが欠員する時のリスクが大きい
- メリット
こんな感じか。面接の準備にブログを使うとは当初の予想になかったが、なかなか効果ありそうだ。あとは冷静に挑むのみ。