My current company is still looking for a Sr. Java developer in SF and I am usually one of the 1st round interviewers. Naturally, it makes me ponder on the optimal approach to interviewing. Recently I started noticing that on more and more topics my real answer is "it depends". It also frequently requires we agree on some conceptual model. I do not believe in the universal best answer to an important question but I also recognize that in real life any progress is possible only when one actually chooses and pursues one of the possible answers.
Interviewing is not any different. In my life I have witnessed at least five distinctly different interview types:
- No real questions - you chat with a few members of the team but they do not test you. You tell them about your background, ask about their system and answer a couple trivial technical questions. Strangely enough, I worked almost five years for two companies that hired me in this style. Although I heard some people think it's a red flag (as in "Do you really think they will have sufficiently bright people with such poor screening?") one of those two was the best company in my eleven years. And yes, it happens in the US too.
- Outsourcing-style - an endless stream of extremely low-level technical questions on particular technologies and APIs. RDBMS isolation levels, the servlet lifecycle, the methods on EJB home/remote interfaces, JSP scopes. A design pattern for them is always one from the GOF book or Sun J2EE patterns guidelines. Characteristically, they do not care about your design skills or code quality and really like J2EE-style.
- CS undergraduate-style - in my opinion a questions such as "implement a RW-lock on the whiteboard" is a good example. Surely enough, real-life locks have nothing to do with whatever you will come up with in 15 minutes and, unless they prepared specifically, quite a few people will probably not be able to remember enough textbook material.
- Common sense-style - reverse a list. Suggest a design for logging system. Implement a Map with additional non-standard requirements. You can answer them on the basis of real-life experience or with some thinking of the kind you do day-by-day at work.
- GOOG-style (actually, I read it was MSFT who originated it) - CS undergraduate on steroids with a puzzle or two to load. Personally, I was not happy during some of those interviews, especially the ones I knew I was blowing badly :) Incidentally, I also learned a lot from them. But when I have only an hour with a candidate I am not quite sure which approach to follow.
From what I see, a typical Java-centered company is either a J2EE enterprise or a place where they care about util.concurrent. Amusingly, this seems to be a very clear dichotomy. In both cases, there is a pile of [de facto] standard APIs and frameworks which take considerable time to master. And people who gravitate to one of the two types tend to be rather apprehensive if not ignorant of the other. I am also inclined to think that very little of even basic algoritms&data structures material is used in those companies. At least not deeper than TreeMap v HashMap and such. So asking more theoretical questions seems almost unfair (and not justified by actual day-by-day development needs).
As an example, today I interviewed another "Sr. Java" engineer. He did not know exactly what the volatile keyword meant (wtf? after all it's a keyword and not some obscure optional library). He was immediately confused with "try { foo(); return 1; } catch (Exception e) { return 2; } finally { return 3; }". And so on. He stated Hibernate experience in his resume but he actually meant "experience in calling Hibernate via JPA". Obviously he did not know about caching capabilities of Hibernate or mapping of OO models on relational schemas although it takes one book and a weekend to learn about. Frankly, I cannot imagine how a senior-level engineer could be so ignorant. After all, you learn by osmosis at work and glean questions from interviews throughout your career.
But what's the point of discussing, say, software architecture with people who fail simple questions relevant to daily coding? In a language universally regarded as outdated and extremely simple? Someone knowledgeable of actual CS must be pretty comfortable with basic hashCode/equals/HashMap stuff. Could I be gratuitously harsh on candidates because of some misplaced self-righteousness? Or I am right in that people who are too lazy to read half a dozen books before an interview do not deserve much? Or is my current company so unappealing that only losers apply?