プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
「最悪の事故」から学ぶ教訓 : 小野和俊のブログ
「最悪の事故が起こるまで人は何をしていたのか」では、チェルノブイリ原発事故、スペースシャトル・チャレンジャー爆発墜落事故をはじめ、潜水艦の沈没や航空機墜落事故、石油プラットフォームの爆発や橋の崩落といった巨大事故が実際に起こってしまった事例と、事故が起こる直前に食い止めることができた事例を通じて、事故を生み出してしまったシステムや体制、組織の規律やそこで働く人のメンタルな状態など、さまざまな切り口から事故の原因が考察されていく。 普段の生活において、自分のちょっとしたミスがこのような大事故につながるような場所に身を置いている人はそれほど多くないかもしれない。しかし、本書で述べられている内容のうち、事故の原因とそこから学ぶ教訓の部分について目を向けてみると、私たちが日常的に接しているような場面においても同じように当てはまる内容があまりにも多いことに驚く。 本書には実に数多くの教訓が含まれてい
型と自分のスタイルとそれに要する経験と時間について : 小野和俊のブログ
「まず型をきちんと覚えろ。はじめは自分のやり方も何もないだろ」 高校時代、陸上部の先輩は私にそう言ったのだった。 私は当時、反抗心だけで、 型なんて覚えずにあんたなんて追い抜いてやるさ、と思ったものだが、 だからと言って一人だけ部活とは別に練習をするわけにもいかず、 動き作り、走り込みなど、先輩から言われたとおりに、 望ましいとされる同じ動きを自分自身の体が自然に動くようになるまで、 毎日、夜遅くまで何度も練習した。 例えば、陸上の短距離走では初速をつけるために スタート後しばらくは前傾姿勢を取るのだが、 私の場合には前傾姿勢をその後しばらく取り続けると タイムが良くなることがわかってきた。 最終的には、400m走で250m付近まで前傾に近い姿勢を取り続ける スタイルが定着して、高校2年の頃にはちょうど50秒*1で 400mを走りきることができるようになった。 これとまったく反対の事例とし
知識が摘み取る創造力の芽 : 小野和俊のブログ
こういうものをつくりたいと思います。 それはすでに世の中にある別のものでも十分なのだ。 他の会社は先駆けてその分野に着手している。 差別化ポイントは？ 調べに調べつくして、 他の人がもうやっていることだったのかと落胆して 何も始めずに終わる人もいる。 何も知らずにトップに躍り出る人もいる。 誰よりも遠くまで飛べた人。 彼らは、躍動する筋肉を楽しんでいた。 風を切って風景がみるみる変わっていくことに興奮していた。 明日もこのことについてずっと考えていたい。 そう思えるものがある人には、知識なんて不要なのだ。 それをやっている人はもういますよ。 それは今からやったって難しい。 最先端の研究ではこうなっている。 速く走ろうとしている者の前に、 そんな指摘がどれほどの意味を持つのか。 彼らが無邪気でいられなくなったときには、 過去に同じ境遇にあった人の話を、しみじみと眉をひそめて聞くだろう。 壁を
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
小野和俊のブログ:続・プログラム・デザイナー宣言
前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
