エンジニアの
コードを
出題の頻度は、国内の転職メディアと技術記事 (2026 年 10 月に調べました) に、分野ごとに調べた問い集のうち同じ問いが何本出ていたかで、よく
レベルの目安
- 未経験から
実務 2 年ほど - 一人で
機能を 作り切れる 3〜5 年ほど - 難しい
設計と 実装を 自分で 決めて作り切る - チームの
技術の 方針、 設計の 判断、 レビューと 育成、 事業との 折り合いを持つ
設計と品質
ネイティブ、
Flutter、 React Native を、 どう 選びますか 作る
人の 数、 OS の 機能を どれだけ深く 使うか、 チームの 得意、の 3 つで 選ぶ問い。 両 OS を 1 つの コードで 作る 良さと、 そのかわりに 困る 場面まで 答えます。 技術的負債と
どう 向き合いますか 放って
おいた ときの 費用を 言葉と 数字に して 共有し、 機能を 作る 仕事の 中で 少し ずつ返すか、 決まった 枠を 取って 返す、と 答える 問い。 全部を 返そうとしない 判断まで 話します。 モノリスと
マイクロサービス、 どちらで 始めますか 小さい
チームや 初期は モノリスで 始め、 中の モジュールの 境界を きれいに 保ち、 要るようになった 部分だけ切り出す、と 答える 問い。 分ける 運用の 重さと、 分けるべき 条件まで 話します。 予算や
期限が 厳しい 案件で、 技術と 設計を どう 決めますか 作り
込んで 差を つける 部分と、 認証や 決済や 通知のように 既存の サービスに 任せる 部分を 分け、 運用の 手間も 費用と して 数える、と 答える 問い。 任せる 弱点と、 自分で 作る 条件まで 話します。 古い
システムを 新しい 物へ 置き換える 計画を、 どう 立てますか 一度に
全部を 切り 替えず、 機能ごとに 少しずつ 新しい 側へ 移し、 各段で 戻せるように する、と 答える 問い。 置き換える 理由と 終わりの 形を 先に 決め、 移さない 物を 選び、 事業の 側と 途中の 約束を そろえる 判断まで 話します。 自分たちで
作るか、 外の サービスを 使うかを、 どう 決めますか 事業の
強みに なる 所は 自分たちで 作り、 どこでも 同じ 所 (認証、 決済、 メール 送信など ) は 外の サービスを 使う、と 答える 問い。 作る 費用だけでなく 動かし続ける 費用まで 比べ、 離れる ときの 道を 先に 用意する 判断まで 話します。 チームの
テストの 方針 (どこまで 自動で 試すか ) を、 どう 決めますか 壊れた
ときの 損が 大きい 所から 自動の 試しを 厚くし、 速い 小さな 試しを 多く、 画面を 通す試しは 大事な 流れだけに 絞る、と 答える 問い。 マージを 止める 条件、 不安定な 試しの 扱い、 網羅率を 目標に しない 決まりまで チームで そろえる 判断を 見せます。 SLO と
エラーバジェットを、 どう 決めて チームで 使いますか SLO は
事業の 側と 一緒に 利用者の 目線で 決め、 100% から 引いた 残りを 「失敗して よい 量 (エラーバジェット)」と して 扱う、と 答える 問い。 残りが 減ったら 新しい 機能より 安定を 先に する 決まりを 先に 合意し、 速さと 安定の 言い 争いを 数字で 決める 形まで 話します。 クラウドの
費用が 増えすぎた とき、 どう 見直しますか まず
費用を 「何に、 どの チームの 物に」 使っているかに 分けて 見える 形にし、 大きい 物から、 使っていない 物を 消す、 大きすぎる 物を 小さく する、 買い方を 変える、の 順で 減らす、と 答える 問い。 費用を チームが 持つ数字に して、 増えたら 気づける 仕組みを 残す 判断まで 話します。
コードを