Job Spec Teardown - Breaking Down the Jargon in a Technical Job Post - Web Front End Edition

08 Nov 2023

08 Nov 2023 by Luke Puplett - Founder

This is what people who know really know CSS, Figma and JavaScript look like. You almost don't need to look at their CVs. Almost.

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 Front End 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 November 2023, you can apply for it!

Wait. Full Stack?!

Yep. The advert is strange. It says it's a Full Stack developer but then headlines the three most front-end technologies you can get. I assume they're looking for someone to work on some of the backend stuff they mention in the ad, but I won't delve into those things, here.

By the end of this, you'll realise that this is mostly a front-end job. The thing is, to an engineer, the job title in the ad doesn't matter and the level of seniority in the description doesn't matter either. The engineer will use the details of the team and what the person will actually be building, and the pay level to work out the seniority of the job.

To be clear, most engineers use pay as a guide to seniority. This is because there's a funny thing in job ads; the more skills listed, the lower the job usually pays and the lower the experience in those skills that's required.

If an ad focuses on one thing and pays a half million quid a year for it, you know they're looking for someone who seriously knows that particular onion.

The Front End

This means the bit of the application, the UI, that users directly interact with. For the web, this is a web page in Chrome or Safari. A basic web page can be made up of solely of HTML, but it won't look nice. That's because it'll be missing its partners in crime.

HTML, CSS and JS

HTML is the original "markup" language invented by Tim Berners-Lee as a simple way to denote a page of information by denoting the headers from the paragraphs of text, images, bullet points etc. etc. It stands for Hypertext Markup Language and Tim or Sir Timmy to his mates took inspiration from a similar language called SGML.

In 1994, a guy named Håkon Wium Lie, came up with a complementary language (which looks nothing like HTML) to apply styles to the content, like making a word blue. That language is CSS which is Cascading Style Sheets.

JavaScript was invented by Brenden Eich in 1995 and originally called LiveScript. It is now sometimes called ECMAScript. It was a simple but familiar for small uses within a web page. You wrap the code in a HTML script tag and it knows what HTML elements are on the page so you can change the page content in response to user actions.

Node

Although JavaScript was conceived as a little toy language that a web browser can run to make buttons change colour and do bits of work on a page, as the web became popular, people used this language to add more and more interactivity into their websites. JavaScript became a big thing and millions learned it.

Then one day a young engineer who loves to code in JS ripped the thing that executes the code out from the browser so he could run JS code on its own, outside of a web page, on his computer. He called it Node.js and a whole new paradigm in web and app development started.

Now, front-end developers could also write their own backend code.

The Back End

We'll come back to front-end stuff in a minute but you'll need to know what is meant by the backend and what it does.

The first web pages were static HTML, CSS and JS. That is, someone hand wrote it all and saved it as a file and a web server sent that file to the browser where it was displayed.

Quite rapidly engineers figured out that they could write some code that ran on the web server which either altered the HTML in the file before it was sent down to the web user, or they could even have the whole HTML file written by their code instead of hand written by a human.

This is how a web page can contain your name, or the time, or the latest news.

Every web page is uniquely written for you

To be clear: almost all web pages you've ever visited were made of HTML which was written by a computer, just for you, when you visited the page.

Humans instead write short blocks of HTML and code, which assembles the blocks of HTML together to make up the page! Making an HTML page is called rendering and having the web server construct the HTML page is called Server Side Rendering.

To make this easier, popular programming languages have long had web frameworks which help turn a request for https://blah.com/blah into HTML and things called templating engines which help mix regular code and HTML. Most web developers and some designers spend their days in this templating code.

Node.js allowed web developers fluent in JavaScript to write the server-side rendering code and the logic that sits behind it, talk to the database etc.

Client Side Rendering

So that was server-side rendering, or SSR, so it stands to reason that CSR must be the same but done on the client. JavaScript become so big and popular that people heaped it on the backend and the frontend.

After the iPhone, people became used to using apps and the key thing about apps is that they don't look or act like a website. They have no URL and they can all be on a single page, and that page may be exactly the size of the phone screen, like a maps app.

To get this effect in a web page meant using lots and lots of JavaScript on a single web page. And instead of navigating to different URLs and reloading the page all the time, the JS could instead clear out the HTML on the current page and replace it with new HTML.

The effect is that the web page looks and feels like a cool "native" phone app. This is a lot of work and so a whole load of new JavaScript frameworks were built to help with this. These are templating engines as before except they run in JS, in the browser, on your phone or laptop!

Note that the JS running in the browser must make network calls to the server to get data and perform actions. There is a continual conversation between the JS running in your browser tab and the server and the server can even push data down as it arrives.

React

There were many of these JS front-end frameworks that came and went, arguably starting with the very simple Knockout.JS (which I still use) and several which came to the most popular use today, including Angular and Vue and some other new entrants like Svelte have come along.

React was built by Facebook engineers to help them build FB, it's ads platform, and Instagram and internal tools. React is super popular.

React let's you break down the parts of your web page into components, like how a car engine is made of individual parts that have their own behaviour, independent of the wider engine, e.g. the water pump or a piston, which themselves comprise of components.

The nice thing is that people can make and share and sell components for others to use. Things like "headless" components exist where the functionality is done for you but they have no look to them, you add your own UI bits and peices (in HTML and CSS).

TypeScript

So now that entire backends and frontend are written in lines and lines of JavaScript code, we have a problem. JS was not designed for this, even if it might be fun.

The problem is quite simple: if I am dealing with your surname in code the data has a type, it's text, which in code is called a string. Your age is held in memory as a number, obviously. In JS, the code is not aware of the different types of data while your writing it. When you run it, it knows, but not when you're writing it.

If you try to do surname + 1 then that makes no sense because you can't do math on text. Languages like Java (no relation to JavaScript) are what's called strongly-typed or statically-typed so it is known that this makes no sense when you're writing the code. As a developer, you continually know what can and cannot be done.

But in JS, all the data looks the same; imagine if all the sockets at the back of the telly were the same shape and you couldn't tell the mains power from the headphone socket.

TypeScript is a form of JavaScript made by the inventor of C# working at Microsoft. Essentially it adds the "shapes" to the data to it's easier to work with, more productive and fewer bugs.

TypeScript cannot be understood by a browser and so it must be turned into proper JS by a program called a transpiler (a translator of sorts). Doing this is the role of "front end build tools".

Other Stuff

• Tailwind - this, along with others like Bootstrap, is a set of CSS rules for styling web pages. They're mostly pre-made styles and save time but can be customized enough for a developer to differentiate the look and feel of their web app.

• Sass - Related to Tailwind, Sass is a set of additional language constructs to the CSS language to help manage the huge CSS rules and files in a large web app.

• Gulp - Languages like Sass might look like CSS but they're not and so they need to be turned into real CSS which your browser is expecting. Tools like Gulp are programs written in JS which do this kind of work and help "build" the front-end HTML, CSS and JS of big websites.

• Webpack - This helps bring together TS and JS which is usually written and managed as separate components that come together differently when you're coding and test a web app on your laptop, vs. when it is served from a web server to an end user.

NPM - this is part of Node but even if you don't use Node itself to run your web app, this is a package manager. If you've written a tool, or component that's reusable and you want to share it with the world, you put it on NPM and give it a version number. Components are made of other components and so on, so managing this chain is quite a job.

GraphQL - GraphQL is a way to get data from your server in a query-response format.

REST - practically speaking this means using the web's own HTTP to send and receive data from a web server.

Bonus: Figma

Figma is a recent phenomenon. It's a tool for collaborating around a design where the tool is especially good at designing for modern screen-based experiences.

Photoshop used to be the tool of choice, mostly due to lack of other options, it's popularity and familiarity, but it was always bending the product to do things it wasn't designed to do.

Figma was created by a bunch of engineers who struggled to come up with a good idea for a product for years before they thought that there was a gap and the world needed a way to jointly work on visual designs for apps.

Adobe are in the process of buying Figma for 20bn dollars, which isn't bad given the listless start the founding team suffered.

Thank you for joining me on this exploration of web development technologies! As a recruiter, your understanding of these tools is invaluable in finding the right talent for the ever-changing tech landscape.

If you have any questions or need assistance, feel free to reach out. Best of luck in your recruitment journey! 🌟

---

Learn more