あなたのことが嫌いなのでも意地悪をしているわけでもなく、これから説明するフロー状態をなんとか維持しようとしてるんです（たいていは維持できないのでそのあと機嫌が悪くなります）。
エンジニアの生産性は短期記憶の扱いにかかっている
設計をする時も既存のコードを追う時も新しいコードを書く時も、とにかく短期記憶を使います。
たとえば、Xという関数はA,B,C,Dという4つの関数から呼ばれることがあってAからDの関数からは3通りの性質の違うデータが渡されてくることがあって、関数Xで処理されたデータはその後に状況によって関数E,F,Gのいずれかで処理をされるけれど…、といったように人間が扱えるとされている短期記憶数9を軽く超えていきます（実際は9のうち2はチャンク？）。
ピープルウェアでは、作業に没頭して能率があがる「フロー状態」に入るには少なくとも15分かかるとしています。
私の理解では集中して15分以上経過した非常に集中できている状態では短期記憶が Seven, Plus or Minus Two に打ち勝てる、そして打ち勝てるエンジニアの生産性が非常に高い、ということなのかと。
フロー状態は中断されるとやり直しです（短期記憶も失われて最初からやり直し）。
応募があるのに断ってるのはなぜ？
エンジニアがとれないとれないと騒いでるのに応募があっても会いもせずに断ってる、他の職種からすると意味がわからないと思います。
エンジニアが仲間になったときに双方不幸がなくやっていけるか、文化的な部分についての確認をしています。文化的な確認には実際はこの短期記憶に関する問題も含まれているかもしれない、というのが本エントリの本題です。
短期記憶は9までしか扱えないとされているのに、エンジニアはもっとたくさんのことを短期記憶に詰め込んで仕事をしています。フロー状態で少し9を超えられるとしても、たとえば1の領域に4を入れられるとしたらどうでしょう？a,b,c,dという事象は当然のZとして短期記憶に格納できるとしたら生産性が上がることになるでしょう。この、a,b,c,dという事象が当然Zであるという考えをチーム全員が共有出来るとしたら？
日々の勉強のインプットの仕方が似ていたり、書いているコードの考え方が同質であったり、ツイートに共感できるか、などから指向や知識に関しての文化が自分たちにあうと推測できてはじめて実際に会ってみるというステップに進みます。もちろん、事前には判断不能で可能性に期待して会ってみるということはありますが、そもそも会う前から粗探しをして無下に断っているわけではありません。
短期記憶と中断について考えていたら、採用についても実は短期記憶が関係していたことに気づいたので、書いてみました。全然そんなことねーよーって意見も聞いてみたいところ。
プログラマ殺しの職場環境 というエントリでは、電話のコール数をカウントするのに短期記憶を使ってしまうというかなしい職場環境の話が書かれていてうかつにも笑ってしまいました（すぐに辞めれば良いのにと思いましたよ）。ピープルウェアの第1版は1989年だし、ソフトウェア開発の現場で何十年も同じ悩みが発露されていてかなり萎えます。
なんじゃ!?このスパゲッティコードは〜？とか、コンポーネントレベルでスパゲッティとか初めて見たわー、とかってのは、想定外過ぎて短期記憶が足りないので相手するのが困難、ということなのかな。ぐへー