| I think part of the problem is the breadth of material for which you can be questioned in. Since I live in the Java world, let me use that as an example. I have heard of anonymous classes. I've never used one on the job. Maybe that's a function of me being more server side and I think anonymous classes are use more heavily in Swing. Ditto for reflection -- aware of it and when to use it, but just never had the need. For better or worse, the pieces of functionality I've had to build out over the years simply did not require me to use those pieces of Java. There are countless of pieces of Java that I simply do not use, even if I'm aware of them. A Java developer (at least in my circles) rarely just codes in Java all day. Often, they're using a framework. It might be Spring. It might be Hibernate. Right there, you have two vertical streams of expertise they could pounce on. Now add SQL. Even if you're using Hibernate, you'll still need some fundamental knowledge of SQL. Likely, they'll hit you with HQL questions. Maybe some lazy loading. Maybe some optimistic locking. Maybe add EJBs. Maybe add JPA. Throw in some jQuery/HTML/CSS (unless they live exclusively in the server tier). Inevitably, some may ask about stored procs/PL-SQL. Oh what the hell...let's add web services, SOAP, REST, Ajax, JMS, transaction isolation levels, clustering, SSL. And so on. Wait...add Linux admin. The disconnect (anxiety?) comes from a developer having to use so many technologies, which is realistic, and the interviewer salivating at the opportunity to go deep in any one of those. "Excuse me...you can't write a static nested inner class? And you call yourself a Java developer?" I once had an interviewer disappointed in not being able to ask me PL/SQL questions, despite me not even having PL/SQL on my resume. He just wanted to go there. The interviews are often based on a notion that a developer does nothing else but use the language to its fullest. All day. Every day. Reality suggests that a developer uses only as much of a language as needed to build out a piece of functionality for a given need. They don't use every data structure available, nor necessarily every major piece of the language. There's seemingly no way around this conflict. The interview is focused on a language. The developer is often focused on putting together solutions. Depth vs. breadth. For the record, I had an interview once for a Grails developer spot and was asked about UDP. Yes, seriously...UDP. We're not God. We're just developers. |