I have been a Java developer, part- or full-time, for a long time now. I have also developed in Clojure, Scala, and Groovy.
Right now I am looking for a post in Java multithreaded development.
While I get lots of interest when I apply for Java and full-stack jobs, I am not as successful getting interviews at positions calling for
multithreaded skills. I have done bits of multithreaded development (Swing GUI, handling images), but not a lot.
So I want to break the typical ice. I want a job in an area in which I don't have extensive professional experience. I am a contractor, so maybe that's one problem. But there must be practical solutions. I have been, perhaps it goes without saying, studying the classic books on the subject, like B. Goetz's Java Concurrency in Practice. But I suspect actual experience of some kind might be needed.
My question is: how might I develop multithreading skills applicable to professional Java development?
Or even more simply: how can I get a job doing Java multithreading?
I have thought of perhaps github or project contributions. There are many potentially relevant projects, but I am not certain which ones might be most accessible. 'Volunteer' programming, pro-bono work of some kind, might be another solution, but a few googles did not immediately indicate who I might do such work for.
A subtantial number of backend jobs in London, for example, call for multi-threading as a principal requirement. While these positions do not focus upon this area exclusively, insofar as they are concerned with solving certain kinds of problems, multi-threading skills are frequently mentioned as the most important requirement and prerequisite.
These are positions which call either for movements of large amounts of data quickly and with minimal waste of resources, or the analysis of very-large datasets or video, or the execution of algorithms very quickly and in parallel, taking advantage of multi-core hardware architectures. These positions have little to do with website development.
Just start by writing simple servers and come up with some multi-threaded task to accomplish! ;-)
I recently wrote a password validation server because I didn't want to install the 170MB dictionary file on every server and and to port the way to access the dictionary to every programming language. It uses cracklib with additional validation under the cover. I wanted that server to be standalone (needs to be always up) and wrapping the logic into a tomcat webapp or what not would have been overkill.
A year ago, I wrote a server which Asterisk VOIP server connects to when an agent receives a call. That server then call the webapp server to displays a popup on the agent screen with the customer data pulled from the database based on its callerid.
My first production grade multithreaded server was a JSP like server before JSPs existed...
That's an excellent idea. Thanks for that. I had planned to study Tomcat and then Netty sourcecode, but your idea cuts straight to the chase: why not write a server yourself, having thought of a decent application?
I'll also look around on github and other places for other examples of custom servers, etc. If I find some good sources (including, eventually, my own?) I'll post them in a reply.
Also keep in mind that, nowadays, writing multi-threaded apps has become the swiss knife of the java environment. It is much likely comparable to the ability to write shell scripts with an added grain of multi-threading capabilities.
What kind of feedback are you getting from interviewers regarding your "multi-threading" experience and their "multi-threading" requirements?
Many job ads - especially for contractors - are put together by people with only a vague understanding (if any) of what they claim to be looking for. So they may be asking for "multi-threading" but actually looking for more general experience with concurrency or parallel processing, or it may simply be a buzzword that somebody mentioned at some point as a "nice to have" but has now morphed into a supposed requirement that nobody really understands or indeed requires.
On the other hand, you may be getting interviewed by hard-core engineering types who really need hard-core multi-threaded engineering experience, which they know how to recognise and which you are not able to offer currently. When people hire contractors, they are usually looking for people who already have the skills they need, as they don't generally want to pay you contract rates while you're learning how to do the job they hired you for.
So, do either of these situations seem to apply to your recent experience of interviewing for "multi-threaded" development roles?
If you have been given specific tips about the perceived gaps in your experience, then that would be a good place to start. Alternatively, you could start looking into the current state of the art i.e. what are people using right now to do this kind of thing, and what are the alternatives to hand-coding thread management, in order to get a feel for what might be the most marketable skills in the world of concurrency over the next year or two. But it's a fairly narrow niche that demands a lot of skill to do it properly, so you may find it hard to break into it without much hands-on experience, especially if you are restricting yourself to contract roles.
Multi-threading in itself is not an area I know much about, but it does relate to my own work on Big Data, where we are seeing a lot of interest in tools like Akka, ideas like the Reactive Manifesto, and Scala-based frameworks such as Spark for large-scale distributed processing. This is also reflected in the job ads in the City, where these kind of skills are definitely in demand.
FWIW, you are a braver man than I am if you really want to get into multi-threading. Now we have alternatives such as Akka for developing concurrent applications, I am happy to let thread programming go the way of pointer arithmetic as an important skill that some people need to do really well in order to provide much more convenient and reliable tools for the rest of us to use. I haven't had to worry about pointers since I stopped programming in C 20 years ago, and the sooner hand-coded threads go the same way the better!
No more Blub for me, thank you, Vicar.
Benjamin Bh Weaver
posted 4 years ago
Thanks again, Bear, A.J., and Chris, for these useful comments. You all are right to distinguish--or to ask me to distinguish--whether I in fact mean (1) low level 'multithreading' (present since Java 1.0 or 1.1. when I started, using wait, yield notify, and so on); (2) higher level concurrent Java solutions (> 1.5) using java.utils.concurrent; or (3) solutions--including rather different alternatives--to the concurrency problem including "shared-nothing" practices like Akka, et al. In fact I have been working a lot on the job with functional programming, some now in Scala but more in Clojure, toward this latter end.
And Chris, you are definitey right about those job-ads, and the intervening, frequently distorting rollrôle of recruiters(!).
Given all this, I think I will (1) continue to look at some low-level threading code; (2) perhaps focus more practically on uses of java.util.concurrent; (3) continue my other work--in which I do have experience functional approaches to concurrency (Clojure STM--transactional memory; Scala (or Java) Akka). (And yes, Chris, I have written a couple of toy programs in Spark using scala, and have found it very interesting).
Perhaps the heart of my inquiry into multi-threading will be at (2).