卒業制作(capstone):4人で作ったのに私しか説明できなかった部屋予約Webアプリ
共有者はMicrosoftの新卒選考ループでこのcapstoneをメインのプロジェクト話として使い、その後内定を獲得しました。
この面接を練習する
実際の深掘り4問 · うち難問1 · 約12分
各質問に自分で答えると、本人の実際の答えが見られます。
本人はこう語った
4人チームの卒業制作で、キャンパスの学習室予約アプリを作りました。面接で面白かったのは技術の話ではなく、作業量が均等ではなかったチームの中で私が実際に何をやったのかを解きほぐす部分でした。
全文を読む
卒業制作(senior design capstone)として、4人でキャンパスの図書館の学習室を予約するWebアプリを作りました。フロントエンドはReact、APIはNode/Express、その裏にPostgresという構成です。書類上は均等に分担したことになっていましたが、実際には2人が途中で離脱気味になり、バックエンドの大半とデプロイは私ともう1人に降ってきました。私が担当したのは予約ロジックと競合チェック、つまり時間帯が重なる同じ部屋を2人が予約できないようにする部分です。最初のバージョンは素朴なチェックしかしておらず、レースコンディションがありました。2つのリクエストが両方とも「空いているか」のチェックを通過して、両方ともinsertできてしまうのです。これはアプリケーションコードで防ごうとするのではなく、時間範囲に対する排他制約(exclusion constraint)を使ったデータベース制約で修正し、DBが重複を拒否するようにしました。教授にデモし、図書館員の方数名からフィードバックももらいましたが、実際に図書館で稼働することはありませんでした。面接で一番難しかったのは、チームメイトを悪く言わずに、グループの成果から自分の貢献を切り分けて話すことでした。事実ベースで、「これは私がコミットしたもの、ここは彼らに委ねる部分」と伝えるように努めました。面接官は排他制約そのものよりも、私がチームについてどう語るかに興味があるように見えました。
実際に聞かれた質問
同じ部屋を同じ時間に2人が予約するのをどう防ぎましたか?
普通作業はどう分担し、あなたは具体的に何を書きましたか?
易しい貢献していないチームメイトがいました。あなたはどうしましたか?
難しい実際の学生が大規模に使ったら、最初に壊れるのはどこですか?
普通