Surviving the technical interview

As a programmer at a fast growing start-up, I’ve been able to gain a bit of experience on the other side of the table. I’m not a hiring manager or a recruiter, I don’t choose which resumes to call or negotiate salary and benefits. My part is the technical screening.

Some technical interviews obvious successes, and many others are obvious failures. But there are many that are muddled and hard to interpret, often in ways that were preventable. Read on for my thoughts on how you can make the best of the technical interview.

Hoping to leave class-oriented programming

Sometimes you need to pass around a function. In Java, since “Everything Is An Object”, you make a class, and define the function as a method in that class. Of course, you need a separate source files for this, since you want this class to be public.

Before long, you find that in a different situation, you want to pass a different function, so you make an interface, another class, and make both classes extend the interface. Now the two functions that would have logically fit in some already existing file have generated three source files.

Does it have to be this way? It’s a lesser known fact that in Python, everything is an object. A function is an object, a class is an object, a module is an object. But somehow, a commitment to everything being an object didn’t lead Guido to conclude that everything should have it’s own class file. Somehow “Everything Is An Object” doesn’t imply (in Python or Ruby) that functions must be defined in classes.

I’ve been using Spring with Java, and that is certainly preferable to me than Java without Spring, for medium or large projects. But it strikes me that much of what Spring helps me manage is the simple fact that I need many functions available in situations where I don’t want to instantiate an object first. When I use Spring to inject a singleton object, often what I really want is a handful of related, stateless functions. I would guess that about well over half of the classes in my projects are essentially one of two things: glorified namespaces or data types without behavior.

More to the point, as I build complex applications, I fear that building them in Java significantly adds to the complexity. I fear that I’m building in a way that requires some acclimation to a handful of patterns and a framework that ultimately shift the complexity of the problem to a different sort of complexity. It seems that this is the best that the Java world allows: familiar patterns of complexity.

So what’s a Java developer to do? Where to go from here?

Using a Naive Bayes classifier for user submitted content

I’ve enjoyed building a Naive Bayes classifier to classify user submitted content at Manta. I wrote a post about how one might implement this on Manta’s engineering blog. I’m giving a colloquium on this at Wittenberg University today, and the slides to that talk are available after the jump.