I will not do a tech interview

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.

My free time is very limited and valuable. Google sounds interesting, but here are my options:

a) Spend my free time exploring and building small projects with new technologies and techniques. Maybe work on a mobile app that could make some money.

b) Find my old CS textbook and notes and do algorithm studying and exercises just to prepare for an interview.

Doing a) directly improves my skills and has lots of benefits. I've been able to improve projects and gain a lot of good reputation at work because of things I discovered doing a). a) could also lead to making a revenue-generating mobile app. And perhaps most important of all, a) is FUN.

Doing b) just feels like a giant waste of time. Doing b) is a direct opportunity cost of not doing a). The potential return for b) is what? Going through a day long interview with judgmental engineers trying to look smart? And it's boring. It was fun learning in college when it was the first time and I had that aha moment of understanding. Now its just boring to go over it again and again just to rote memorize things. I would rather be building or learning something new.

Heres a choice quote that I'm still happy with:

"Programming isn’t theatre or performance, “on demand” isn’t how your job works"

What I worry about most isn't that the contemporary coding interview creates false negatives. What I worry about is I suspect that it unevenly creates false negatives.

The UK civil service used interview boards consisting of a manager of the role, a subject matter expert and an independent person from outside the organisation. It is an inherently high-stress situation for the candidate due to the numbers involved and and usually due to the room layout.

I was trained to account for the stress reactions and see past a freeze due to the situation and focus on clear demonstrations of skill and experience. If anything we were trained to try to make the candidates perform at their best in the board rather than probe to see their worst sides.

It was complicated by the fact I was employed in a highly technical specialist team (It was a military research agency) and few people we interviewed had any experience of what we were planning to employ them for.

We also consciously went beyond a general knowledge test and focused on how the candidate thought about answering questions rather than if they knew every technical detail. In that role technical detail was only a man page or a conversation with a colleague away if you know what you didn't know and were prepared to ask for help.

Any interview that stresses the candidate, quizzes the candidates memory of detailed technical facts and doesn't work from the premise that it is a high stress artificial situation is not going to provide a valuable outcome for anyone involved.

Edit: My best question to identify general technical competence starts with "Can you describe the TCP handshake?" and if they know is quickly followed up with "Why is it like that?". Unless there is role specific reasons to know TCP then it doesn't really matter if they don't know, if they do know I am really interested in their answer to why it is the way it is. Many even quite senior candidates have never considered it before and watching their process of thinking about it is very instructive about their ability to think about technical details in the abstract.