What are the Java essentials that I should be familiar with before interviewing? What do I need to know about working with Java at scale? Are there any good prep resources I can look into?
Also, check out the Google Java style guide. It's a nice point-of-reference, but don't get too hung up on their conventions.
That's pretty generic advice. There is probably a better resource specific to what you'll be doing.
EDIT: I'm still just a college student, but I have done a few Java-based internships. My advice probably won't be all that helpful if your senior developer, or doing some super low-level stuff.
At one point in my career, I had to evaluate Java as a potential base language for a new software product family my company was planning to develop. It was early days for Java, so little was known about it in our developer community. Early days also made the Internet far from useful as an information source. We were a Microsoft C / Visual FoxPro shop at that time, but needed much better support for Internet communications than was easily found in those parishes. As well, the possibility of automated memory management was a blessing after our grossly drawn-out foray into C++ design and debugging on another project.
The company bought me one of the “Learn <Programming Language> in 24 Hours / 14 Days” style of books and I sat down at my desk Monday morning. With a paper notebook to one side, I started with Chapter 1 and just motored my way through, taking notes like I was in class and doing paper exercises where possible. We had no Java compiler yet, but the book was a useful hand-holder. In three working days I had finished the book, and was ready to discuss Java intelligently, program with it tentatively, and recommend it as a “possible” for our project.
We obtained the Java development environment and with the recent book-learning I was able to test-build some planned features from our new product quite quickly – far quicker than in C++, the nearest object-oriented equivalent we had experience with. But Java’s then-terrible run-time performance knocked it out of the competition and we ended up continuing with C++, incurring all the pain we already dreaded as well as shiny new pain when we got further into the depths of native Windows development.
The major point I wanted to make about the “Learn X in 24 Hours” book approach is that it made me a just-in-time Java expert for at least a few weeks. The instructional material was very well organized. Easy topics could be skipped (operator precedence), and hard ones pounded into submission (thread communications). The purpose of this style of book is to introduce every feature of the language, so when I finished I was up-to-date on the current state of the art, even though many of the items of knowledge were not useful afterwards (AWT and Swing, dang it!).
This benefit may apply to your situation by giving you an organized and rapid way to recap your existing knowledge of Java. You’ll be able to skip more than I did, as you have already been introduced to the language. But you’ll also be re-exposed to elements you may not have focused on the first time you learnt Java, perhaps programmatic control of garbage collection, RMI (remote method invocation), or servlets. Interview questions often lurk in the language’s darker corners, but you’ll be less likely to be caught flat-footed if you’ve worked through all the chapters recently.
Using the book, as opposed to getting pretty much the same information from the Internet, gives you a sequenced, tutorial-like stream of information. Nothing is under-explained, everything important is touched on, exercises help fix concepts in memory, and there are no kittens to look at. The fat book will appear daunting, but in my experience it’s just a few days work to push through one (on the corner of my desk, I have Java 8 In Action[1] awaiting the same push!). A second-hand programming-language book is also as cheap as a cup of coffee, and equally widely available – usually from the local charity store, where they pile up like last year’s unwanted fashion apparel, or from one of Amazon’s used-book vendors
I think the time / benefit quotient for the tutorial book approach is far better than for the “I’ll just fire up Google and learn the few things I need”. I recently had the experience of trying to evaluate Docker using the vast interwebs as an information source (four months of disorganized, part-time amusement) versus using a book, and the book won once again (four days of concentrated reading, and I’m far more effective at explaining and using Docker than I was after all that Googling).
I also concur with other posts here in pointing out that the books Effective Java[2] and Practical Java[3] are information-rich sources on nit-picky and gritty Java concerns. If I was going for an entry-level Java position and had to minimize my hours of preparation, I’d still go with the tutorial style of book for the low preparation time and broad coverage. But if I was going to interview for a more senior developer position, or face a room full of Google corporate interviewers, I’d grab Effective Java and spend a couple of weeks perfecting the hard stuff (probably do both if I had a couple of weeks, to be honest).
In the second case I’d also do some web research and find out what areas the hiring organization was focusing on. Once you find that you’re budgeting your interview prep time, it just seems smarter to buff what they’re going to look for, rather than be a broader but necessarily shallower “expert”.
I won’t bore you with details of competitor analysis and “web content indexing” here, but I suggest you may be surprised what you can find out about the hiring organization if you’re serious about impressing them. At a minimum, go through their other job postings (preferably over two or three recent years, not just what’s visible today) – you’ll be able to identify some or most of their technology stack and major systems by parsing the job ads.
If their line of business or current project is Java web sites, brush up on servlets and web frameworks (preferably the ones they favor). If they’re looking at big data, load your brain with Hadoop and Mahout (and a half-dozen more – it’s a burgeoning field). If they’re looking at distributed or high-availability systems, swallow a mug of hemlock. You can fill in the rest of this list with a little Googling after your competitor analysis.
I should finish by adding that the twenty-four hours spent learning Java wasn’t wasted, as it has turned out to be one of the last commercial programming languages I learned and needed. I used it prolifically for web service development, corporate data mangling, high-availability data centers, distributed systems, and (most recently) big data and the delicately-named “web indexing” industry. The years of C++ learning and toil finally petered out in the face of languages that were faster to develop in, yet produced safer and more “commercial” final products for desktop and server. Je ne regrette rien!
[1] Java 8 in Action: Lambdas, streams, and functional-style programming (2014) - Raoul-Gabriel Urma, Mario Fusco, Alan Mycroft
[2] Effective Java (2008) - Joshua Bloch
[3] Practical Java Programming Language Guide (2000) - Peter Haggar