I once interviewed for what I suppose you could call the chief architect position at a small firm (about 1,500 employees) that wrote logistics software. Their flagship product was based on Enterprise Java Beans (EJB) version 2.1 and they were looking for someone to lead them through the migration to EJB 3.0. At the time I was the team lead for the Java half of a internal resource management application.

Part of the interview process involved an in-depth technical discussion of EJBs with a panel of their existing architects. We discussed the underpinnings of EJB 3.0 persistence, its performance and code maintenance benefits relative to EJB 2.1, and the probable level of effort involved in migrating from EJB 2.1 to EJB 3.0. Suddenly, one of the architects asked why I was not using EJBs in my current application, given my obvious  respect for the technology. I then launched into a 30-minute explanation of situations that do not lend themselves to the use of EJB persistence. Because these were Java nerds I went into excruciating detail about EJB entity relations, the actual SQL queries executed to build result sets, and the interaction between an EJB-based application and a CICS application that updates the same database. Altogether, I presented a half dozen application-specific design issues that either nullified the advantages of using EJBs or exposed a disadvantage of EJBs.

I presume my answer was satisfactory (if perhaps long-winded), because they made me an offer the next day. The recruiter that presented me to the company claimed she had worked with them for nearly a decade and had never seen them turn around an offer so quickly. I mention that because (1) why not take the opportunity to brag a little and (2) the fact that they got so excited about the candidate who told them when not to use a particular technology is relevant to my point. Far too many technologists have an allegience to a particular technology and begin looking for possible situations to use the technology instead of looking for the right technology for a given situation. As they say, when you're holding a hammer everything looks like a nail. Fix this natural human tendency by putting down all your tools before evaluating the situation. Once you determine whether you're really looking at a nail or a screw you can pick the appropriate tool from your toolbox. Don't recommend  VMware when Linux on zSeries is a better fit. Don't use Linux on zSeries when a Java fabric on Intel would work better.