Technical Interviewing Is a Skill Worth Developing

I’m going to let you into a secret: our industry is horrible at interviewing developers. What’s really silly is that we almost never sit a candidate down to write actual code in the actual environment they’re going to be developing in. That’s like testing a musician on theory but never listening to them play.

The good news is that interviewing is a skill like any other, meaning it can be learned. As with acquiring any other skill, you can research what’s involved and practice, practice, practice. If you get rejected during interviews it doesn’t mean you’re not a good developer. It might just mean you’re not good at interviews. That’s something you can improve on, and each interview is another opportunity to gather more data and to practice.

Interviewers will often ask similar sorts of questions. Here are three that are fairly typical:

• Multithreading gotchas. It’s still common to be asked to inspect code with synchronized scattered liberally around and find the race condition or deadlock. Organizations with this sort of code have bigger problems than hiring developers (although if they show that code in interviews they’ll definitely have a problem hiring developers), so maybe you don’t want to work there anyway. Having a working understanding of concurrency in Java will help you navigate most of these interview questions. If you don’t know old-school Java concurrency, talk about how modern Java has abstracted away these problems and explain how you might use Fork/Join or parallel streams instead.
• Compiler gotchas. “Does this code compile?” Well, I dunno, that’s what a computer and IDE are for — the tools can answer the question while I worry about other things. If you get asked these sorts of questions in interviews, use some of the Java Certification study materials (for example, actual books) to learn how to answer them.
• Data structures. Java data structures are fairly straightforward: understanding the difference between a List, a Set, and a Map is a good place to start. Knowing what a hash code is for helps, and so does how equals is used in the contexts of collections.

A quick web search for common java interview questions will also give you a good set of topics to research.

Is this cheating? If you learn just enough to get through the interview will you really know enough to do the job? Remember: our industry is horrible at interviewing developers. The interview experience is often miles away from the job experience. Ask plenty of questions to see if you can get a glimpse of what working there is really like. You can learn new technologies easily enough — that’s what we do all the time. It’s all that people-related stuff that often determines whether you’ll succeed. But that’s a topic for another article.