Bad Interviewing

Went on an interview recently that went poorly.  Here is my assessment.

1. I was not enthusiastic about the job.  I have no enthusiasm for the business model.
2. I interviewed on the day after Christmas and one of the guys interviewing me was on speaker phone from his home.  I was interrupting his time off with his family.
3. The manager spent an hour telling me about the details of the business and the application using company specific terms.  I've seen this mistake over and over again.  As much as every IT shop has similarities, they also have many differences.  Either terms mean slightly different things or the company uses completely different terminology.  I need a ten minute overview.  I don't go on interviews to start remembering the IP addresses of servers.
4. The manager told me that they work on 12 to 15 projects a year and then come crunch time they throw away all but 2 or 3 of them.  In my head I'm thinking that sounds awfully incompetent, but I can give no reaction to a statement like that.
5. They used Hibernate and were proud of it.  How many times do I have to fight this battle in my career?  JDBC and SQL is easier and faster than Hibernate.  IBatis is also pretty good.  Database access is one of the top impacts to performance.  I don't understand why architects always want to turn over fine grained control to get database portability in return.  In enterprise Java I've seen performance problems over and over again in my career.  I've never seen a critical application switched from using one database to using a new database.
6. The architect interviewing me believed Scala was going to replace Java.  I couldn't even remember Scala's name at the interview.  I've read about it, but I don't care deeply about it.  It is not going to replace Java, despite what you or he thinks.
7. The architect interviewing me wanted to know if I knew what closures were.  I did not off the top of my head.  I had read about them before, but I didn't find them important.  There are many ways in Java to do what closures offer and despite 3 requests, it appears like they didn't make it into Java 7.  He thought they were important.  I do not.
8. The architect interviewing me wanted to talk about MongoDB.  MongoDB is a documented-oriented database system or a key value store.  Now, I don't know much about taxes, but I would think you'd want to understand the data well enough to put them into a traditional relational database.  A key-value store seems to me like it would have serious memory demands.  I'm open on this point because tax laws are constantly changing, but even with that the key data stays the same.