How to prep for and ace a (Java) interview
Long gone are the days of C++ ruling the development space. Just as few knew that ‘NT’ stood for ‘New Technology’ in the late 90s, few still remember that ‘VB’ stands for ‘Visual Basic’, and even fewer can speak about its Beta version being tested by Boeing for Microsoft.
Things were going well. Novell offered great NDS trees, AS400 was the ‘poor man’s Unix, and OLAP was the revolution in Relational Databases. Btrieve and Access were respectable ways to approach technology, up to 10 users at a time, and personality was optional, when it came to hiring programmers.
The H-1 consultants brought the ‘point and click’ approach in their quest for Green Cards, while being robbed blind by consulting companies; and more and more Bachelor degrees in Computer Science didn’t even bother teaching the concept of non-virtual functions. Interviews demanded precise knowledge of technologies, application and the confusing ‘full life cycle’ experience, which later became the ‘full stack’ demand; first round screening was almost always over the phone and numerous programming tests and exercises began circulating all over.
How does one comply with having the ‘true’ Java experience? Even Spring isn’t that hip anymore and most think of SOAP as outdated, barely even recognizing REST as a piece of technology capable of offering a challenge.
At first, let’s take a step back in history to understand that. It used to be that C was the language, the ++ compiler gave it some chops, and then it was up to you whether you want to start using visual pointers and tables. Of course the compiler itself didn’t produce inline code, but recursion is sort of a coding incest anyway. The alternative was Java. Even before it became so useful for the web tasks, there was no need to define functions as virtual – SUN shone bright on the non-coffee sister (forgive the pun). The introduction of the web, and all related development, brought more buzzwords into the mixture, than anyone ever expected. From JSPs, and subsequent Struts, to enterprising the beans; Hibernate took over from JDBC; Spring stormed in and inverted the control container; and Java 8 even offered the functional programming option, albeit to a lesser extent, than Scala or Clojure, yet still light years away from LISP. Then DevOps methodologies and approaches turned software development into the implementation race, and suddenly being a great Java expert meant something entirely different.
What should you know, when going for a technical Java interview then, outside of the Agile DevOps space, which is really just an automated technical cocaine consumption? Don’t forget that it all begins with JDK, and for the last dozen years it’s been a free development tool. Remember the JVM basics – be able to explain the garbage collection algorithm and the class loader activities. Don’t forget about binary compatibility. Hash functions and tables still matter! Multithreading doesn’t just happen automatically – concurrent programming matters! Asynchronous programming increases speed and efficiency exponentially! Refresh your knowledge integer; recall that a string can be an anagram; enumerators define structures; Fibonacci sequence is the mother of numbers; palindrome isn’t just for ‘super geeks’; and stack is not just an abstract.
Feeling lost yet? Above and beyond, remember that nobody knows everything. Make sure to understand, and be able to explain, the architectural purpose and presence of what you do. Stay current on the basics. And you have to absolutely love what you do. ‘Winding down’ after work should mean a GitHub contribution, or at least some measure of experimental madness on a partition, not Netflixing. After all, you aren’t a regular person in a big world, you’re a programmer, who can birth things out of nothing and bring cool ideas to reality on a whim.