プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
メタプログラミングと内製回帰の組み合わせは強力 - Float on the flow
メタプログラミングで生産性が超あがるよ！という話の件。 システム開発を生活の糧としている自分にとって、よくわかる話です。 ただ、実際にメタプログラミングが強く利いてくるのは、 数億〜数十億円規模の大規模プロジェクトじゃなくて、 ユーザ企業内での内製だと思う。 SIerが入る大規模プロジェクトだと、プログラミング以外の要素が 多すぎて、メタプログラミングがもたらすメリットがあまりない。 システム開発工程の中で、ボトルネックはプログラミングではないよ、という。 （要件定義とかコミュニケーションロスが顕在化するのがプログラミング工程で あることが多いから、そう思っちゃうけど） それどころか、デメリットである 「高位ロジックが、高度であればあるほど、最終的に何が起こるのかが、わからなくなってしまう」 （by id:higayasuoさん http://d.hatena.ne.jp/higayasu
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
