未来の転職が、過去にさかのぼって現在の自分を有能にする - 分裂勘違い君劇場
転職、すなわち中途採用の面接では、自分が過去に取り組んだ仕事について質問されます。 しかも、ごまかしがきかないよう、具体的な行動内容を、細かく聞かれます。 広く浅く訊くのではなく、何カ所か適当に選んで、狭く深く訊いていきます。 たとえば、エンジニアなら、過去に自分が開発したシステムにおいて、 なぜ、そのフレームワーク、ツール、ライブラリ、DBを使ったのか？ 他に、どのようなフレームワーク、ツール、ライブラリ、DBが候補として 上げられたのか？ 他の選択肢と比べて、どの様な短所と長所があるのか？ なぜ、他の選択肢ではなく、それを選んだのか？ 使う前に、どのように性能評価・検証したのか？ なぜ、ある部分を汎用的に作り、別の部分をハードコーディングしたのか？ なぜ、その設計だと、生産性が高く、トラブルのリスクやメンテナンスコストが低くなるのか？ もっと低くできる余地として、どのようなものが考えら
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
