Job Spec Teardown - Breaking Down the Jargon in a Technical Job Post - Java Edition

25 Oct 2023

25 Oct 2023 by Luke Puplett - Founder

Understanding job specifications is crucial for tech recruiters. Job specs outline qualifications, responsibilities, and skills needed for roles. However, they often contain confusing industry jargon and technical terminology.

In this post, I'll do a deep dive into a real job spec for a Java Developer role. My goal is to decode each section, explain requirements in plain terms, and provide context on why certain qualifications matter.

In the late 1990s I manned the telephones for Microsoft before working in big enterprise IT and then becoming a developer building trading and financial apps.

Whether you're a recruiter looking to improve your tech job spec knowledge or interested in Java development roles, I hope this analysis provides insights. By breaking the job listing down step-by-step, I aim to demystify the technical details so you can better match candidates.

Let's start dissecting this job spec section-by-section! As we review the outlined responsibilities, skills, and characteristics, I'll offer straightforward explanations and highlight strong applicant traits. Join me in unraveling the intricacies of a Java developer job specification.

Without further ado, here's the advert. It's real and as of late October 2023, you can apply for it!

Role Summary

Although there's a list of technical skills, hidden within the blurb are quite a few other technologies and jargon terms mentioned.

Let's go through them all.

Java Developer

I'll spent a bit of time on this because Java's a big deal in technical recruiting. Some mega basic things to help grok this:

• Apps are written in code. That code is often compiled into a format that the operating system can run (C++, Go, Rust).

• But sometimes it's compiled into a format that another app called a runtime can run. The runtime is actually also compiling it, but it does so just for the lump of code it's about to run, just before it runs it (Java, .NET, Python).

• And sometimes it doesn't compile it at all but a special runtime simply interprets the code and simply carries out the logic like a set of instructions (most scripting languages, Python is kinda both).

• Apps are not necessarily visible when they run, i.e. they have no UI, but they are running.

• Apps may run on a server, which is just a wide, rack mountable computer in a cold room somewhere, usually connected to the internet with a very fast connection.

• Apps may run on your machine, like Notepad or a game, but also a web page can contain code which the web browser runs on your machine or phone.

• And finally, apps talk to each other; code running on your machine may exchange data with an app running on a server.

Java has been around a long time now and has become the original gangster of garbage collected languages. Garbage wha?

It just means the programmer doesn't have to allocate and release memory, which is a flipping huge burden taken care of. The trade is speed because the program has to pause every now and again to free-up memory. That pause is too short to notice for most apps but giant ones sucking lots of RAM cause perceptible pauses which makes such languages less than ideal for things like high-freqency trading.

But otherwise, Java made building all other kinds of apps a productive, cheaper and pleasurable thing that companies could afford to do.

Java runs on a thing called a runtime which you install into Windows or Linux or macOS. The same app can therefore run on many platforms. Java is fast. Not as fast as C++ or even Rust, but it is rapid. The runtime is called the JVM or Java Virtual Machine and it acts as a translator that makes all the plaforms "look the same" to the code running on it.

Note that Java is just a language, a syntax that is compiled into a more machine-readable (far less human readable) form that the JVM then runs. This allows for other syntaxes to be designed which also compile to the same machine-readable format that the JVM can run, allowing the code to interoperate.

It's downside is that being cross-platform it was the first to need to solve the problem of displaying a GUI on each platform. Each OS has its own way of doing that which is pretty deeply integrated into the platform. So Java tends to be used to make server apps that either have no UI, they just perform logic, storage etc. or they spit out HTML which is rendered by your browser, i.e. websites.

Java has been stunningly successful. In 2000, Microsoft took inspiration, shall we say, when it designed its own .NET runtime and languages that resemble and rhyme with Java.

Object Oriented

This isn't called-out within the spec perhaps because it goes without saying that Java is an OO language. A language can be imagined as the words and punctuation of coding and a huge set of rules about what's allowed/disallowed. Imagine life without the road system and its rules. You'd have um, you'd have; well you'd have India. By not allowing people to just drive randomly, it's actually easier to get around and coordinate.

Code is immensely complex and order is much needed. It's the philosophy of the language designer in their approach to such rules and constraints that is what attracts and repels programmers, just as some people love the philosophy of Texas and others prefer Boston, or Denmark, or yeah, India.

An OO language is designed around componentry. That is, you use code to describe the smaller working parts of a large machine and each working part has its own behaviours and logic. This lets you reuse a part in another app, or replace a part with one that "fits the hole and slots in" but has different behavior.

So, that's Java in a nutshell - the OG enterprise language that made programming easier and inspired a whole bunch of others.

Languages tend to work within a "toolchain", which is all the other useful and necessary bits and bobs that are used with it.

Big Data

Not what you think, Big Data has come to refer to a set of data processing technologies rather than the amount of data. We'll cover some below.

Agile Methodologies

Trigger warning: no one can agree, and people should stop using the term.

This is a minefield. I'll be as succinct as I can because it all went horribly wrong. The first thing to understand is that building software is nothing like building a bridge or a house and should not be treated in the same way.

The soft in software means that it is more like play-doh or oil paint than concrete, but building software in a company is relatively new compared to the lifetime of a human manager, and so it was (and still is) mostly managed like a civil engineering project, or at least a traditional IT project.

In 2000-ish some 20-ish developers got together to try and help themselves and the companies they worked for get much better results from their in-house software teams. They often toiled on projects for years only to see them get axed or fail to be adopted by their users, and then axed. The problem was that by treating it like a bridge build with a set of gathered specs and a grand unveiling at the end, they software was often way off target with respect to how its actual users work and do their jobs.

Software being soft can be built alongside its end user by thinking up the smallest helpful liitle tool, handing it too the user as quickly as possible, watching them use it and talking to them, and then changing it or adding more features. That's it.

The famous twenty wrote a "manifesto" to change the world! However it failed because:

• ITIL came along at exactly the same time with its risk aversion, draconian change control and massive appeal to enterprise CIOs.

• The manifesto was open to interpretation, (by design).

• The incredible human need to keep doing things in familiar ways.

• The Victorian industrial organisation of workers into segregated groups, and the misallocation of software people in with the IT cost-center.

• Disempowering bureaucrats while empowering common programmers, who don't even wear neckties, to work autonomously.

• The hard truth that most people in large companies are fearful, of average ability and have spent a lifetime, including school, following process.

Enter Scrum

A great idea in principle, Scrum is just a basic process for working in short bursts where the team completes something testable at the end and pausing to discuss how to improve. Sounds great because it sort of is, unless you do this within a large enterprise with the problems listed above.

Scrum became the crutch that a) felt reassuring and process-like b) seemed to map to the stuff in the Agile Manifesto. When combined with the structural problems in large enterprises, what resulted was building a bridge albeit the whole backlog of work broken into two week steps with people sitting around knowing that the way to improve was entirely out of their control and meant completely changing the whole organisation and firing a number of people, ...and a final big unveil still.

Many, many companies work in this way now and have no idea that it is wrong. Meanhile, if you look through any of the thousands of high-growth Silicon Valley style startups job ads, or listen to podcasts like Lenny Ratchitsky's, or find the CV of anyone in tech in San Francisco you won't see or hear anyone ever mention the A word.

It's not avoided; it never really existed. The ideas in Agile are so obviously the way it's done that there's nothing to discuss and no identifier of this perculiar work style is needed. If anything, people talk about Lean Startup, which is a much broader way of applying experimentation to a new product business.

As such, seeing Agile on a job spec is a red flag.

Kafka

To explain this I'll need to explain events. As programmers, like people laying out the road system after the car was invented, we try and model the world and come up with patterns and ways of breaking things down into manageable units.

An event is lump of data, normally just text in a well-knowned format, that describes something that has happened or a fact. When you click on a button on a web page, that's a click event and a parcel of data represents it in the system and it can be sent to different bits of code and different apps running on disparate servers.

In a new system, the development team will brainstorm all the various events that a system will have. Programming in general is largely about passing "messages" between areas of code and an event is a posh word for a message. In a big, busy system millions of events can be flowing around memory or down wires, per hour.

If you think of these events as like loads of cars travelling along roads, Kafka is like a programmable highway with on and off ramps, lanes and traffic lights, making sure events flow efficiently between various systems and are backed-up securely in case of power outage. The events "stream" through Kafka like traffic.

Hadoop

Hadoop is a storage database designed to store massive amounts of data but in way where it can be queried rapidly. A normal database can work fast against medium amounts of highly structured data, but in general they only work on a small set of customer data, continually pecking at little bits like updating orders and changing you username or whatever.

By contract, in Hadoop you might store years of orders or user behavioural data then a data team will use it to run queries against and spot patterns. It's good at that kind of thing.

Cassandra

This one is more like the "normal" (non-Hadoop) database mentioned above that sits behind your application holding all the user logins and stuff used in the bulk of the application's main user experience.

Twenty years ago almost everyone used an SQL-based databases for this, which you can think of as storing data in a giant, invisible Excel Workbook, tabular. But since building apps became common and done with continuous user feedback, it's now normal for apps to radically change design. SQL is painful to change while document databases are easier.

Moreover, consider the Object Oriented nature of code. A user login in code is more like a Word document describing the user, like a one-page CV, than a row in an Excel sheet. Using SQL means lots of coding effort goes into reshaping rows into documents and back again (called ORM).

Databases like Cassandra came along which store data as documents but still allows it all to be queried. They are also very fast and handle the high loads that web apps can be subject to at scale with less effort than SQL (which can be even faster, but requires tuning skills, special queries and even hardware design, which is a pain when you're using the cloud or a remote team who follow a process).

MongoDB

It's useful to say that Mongo is similar to Cassandra in that it is a "no-sql" document store. It stores objects in a similar format to JSON which is a native text-based JavaScript syntax and very, very popular for data exchange and storage.

Mongo is arguably the original Gangster no-sql database, still widely used and really good.

Multithreading

Code is like a set of instructions and your computer carries them out. A thread is the name given to the CPU task which is carrying out the instructions. Multithreading is writing code where there'll be more than one thread executing your code, simultaneously.

The hard part of writing multithreaded code is when more than one thread is reading and writing to the same bit of memory, or when trying to exchange information between threads or coordinate what happens, when.

It's a big and deeply technical subject. When recruiting, you need to make sure the developer has worked on highly multithreaded applications because they're quite uncommon. Most developers today are web developers and threading, concurrency and parallelism doesn't come up as much, and when it does it's quite simple stuff.

JMS (Java Message Service)

Rewind back to events and Kafka. Remember events are messages which I likened to cars flowing around roads. You can also think of them as letters in envelopes being sent around the world. Perhaps JMS could be compared to the rules of the postal system: an envelope, a stamp, the hierarchical format of the building address, that you must write it on the front and stick it in a box on the street.

These are the norms to adopt to post something physical. JMS are computing norms, called a standard or a protocol.

ActiveMQ

Think of a cash-machine crashing just as it was going to give you the money. Did it deduct from your account? Or will it deduct when it comes back online? What if it deducted AND it'll deduct again when it comes back online!?

MQ stands for Message Queue, which reveals that this is related to JMS. In fact, ActiveMQ is open-source software which uses the JMS standard above to send and receive messages.

Messaging is actually a tricky thing in computing because you have to build a system which can tolerate the server having its power cord ripped out at any moment and no messages will be lost. But also you run the risk of delivering the same message twice. It's like a computer handing a baton over in a relay and having to code for the quite-likely situation that either person could vanish at any moment and then reappear seconds or hours later, and the baton transfer MUST succeed.

All the world's cash moving around depends on reliable message queues. This is why Bitcoin was a breakthrough because it solves the problem without message queues, using a bizarre idea that actually worked so far!

But that's for another day. Hmm... a crypto engineering role. That would be interesting!!

So long folks.

---

Learn more