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.

Next steps for Java development

So you wanted to learn Java. Naturally, you did the hello world thing, then you learned about flow control. You became accustomed to the type system, declarations, initialization, and you learned about scoping issues. Then you learned about polymorphism, inheritance, and you’ve learned how to write object oriented Java code. You’re familiar with the collections API, and you are accustomed to using generics for type safety.

Of course, you want to get paid for programming in Java eventually, and the little console apps you have been building don’t exactly look production quality. Moreover, when you look at the job postings, you see a hodgepodge of terms that don’t mean anything to you, such as Struts, Spring, Hibernate, J2EE, Tomcat, WebSphere, Ant, Maven, etc. What to do?

Be the worst

You know you aren’t the best programmer out there. You haven’t created an open source project in your free time. You probably haven’t even contributed a patch. You don’t go to all of the hip conferences to learn about the latest “latest and greatest” technologies. You don’t give talks at the local user group, and you don’t have a widely read blog.

But you aren’t the worst programmer either. You try to do your work well and you read a few technical books a year. You attend a user group or two when it fits in your schedule. There are a few technologies that you understand fairly well, and others on your team look to you for help in your areas of relative expertise.

The problem is, you are in a rut. You aren’t gaining skills as quickly as you were last year. You aren’t exactly thrilled about your current job, but not so dissatisfied that you want to take the chance of trading your known problems for unknown problems. What to do?

Jeff Atwood does more good work

Jeff Atwood announced that he is leaving Stack Overflow / Stack Exchange after this month in order to have more time for the more important, world-changing work of caring for his young and growing family.

The Internet is full of praise for men whose professional successes come at a terrible cost to their wives, and to their children. Meanwhile we wring our hands at the costs of fatherlessness in our nation. Let us take our hats off to Jeff for his manly choice to do the humble, necessary work that does not lead to public praise.

Choose your frontier wisely.

Living with cutting edge technologies is life on the frontier. Exciting new opportunities abound, but so do the challenges and dangers. The frontier is exciting because many mundane problems have been left behind, but it isn’t long until you miss the the boring benefits of community, the doctors, the policemen, the grocers, the plumbers, the libraries, and the companionship.

Should you get certified? Should anyone?

Technology certification exams have a bad reputation. You don’t have to go far to find someone deriding the idea that a multiple choice test could be useful in distinguishing programming skill. Some say that they are a waste of time and a marketing scam. Others even claim that they distinguish you in the wrong way, and that any certifications that you have earned should be removed from your resume, as they will actually hurt your chances of getting the job you want.

I disagree, and think that there is a place for certifications, but there is some confusion about what you can and cannot get out of them, and when they may be beneficial to your career.

Five things you DON’T need to get your first programming job

How do you get your first programming job? In any field there is the catch-22 of needing experience to get a job and needing a job to get experience. In software development there is good news: You can get experience without a job.

The bad news is that figuring out what experience to get can be paralyzing. Read the job ads and you find that experience with frameworks like Spring, Struts, and Hibernate are required for most Java jobs. Read forums and blogs and you find that the cool kids that get the startup jobs all have their projects available on GitHub or BitBucket. Some say that mobile jobs are hot. Others say that their are no decent jobs in Java or .NET, that you should be investing in Ruby, Clojure, Scala, and Node.js.

What if you don’t know where to begin? Let’s reduce the pressure by considering a list of things that you don’t need to have before getting your first programming job.

Accepted new position: Search Engineer at Manta.com

Yesterday I unofficially accepted a position as Search Engineer at Manta.com. What’s Manta? What’s a search engineer? Why the change?

Hello, world!

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

I executed that program about 30 months ago. For me, it was a moment of optimism, now that Java was installed and working, I could focus on learning how to program. For my wife, it was depressing. Seeing the plain white text on the black console window highlighted how much I had yet to learn.