Who is this for: Recruiters in Tech, Non-Technical Hiring Managers, and possibly, technical folks who would like a quick recap of some technical terminology.
"It looks like you have lots of experience with Spring Boot. Do you also have experience with Java?"
This is one of those questions that many Java developers have heard at least once while going through a pre-screen with a tech recruiter.
The problem with this question about experience with that particular technology is that it makes little sense (see the guide below for why). It is rooted in a very fundamental gap in communication between candidates and recruiters in tech. This gap is one of those things that I've seen so prevalent in the software industry for the past 18 years of being a part of it.
The gap that I am referring to is that recruiters are often unaware of what the different skill sets required by employers mean.
It's understandable why.
As a recruiter, you are given a list of skills that the client is looking for. These skills are numerous and many of the names are simply confusing. I mean, Angular is not the same thing as Angular.js? Come on!
If you do try to look any of these up, you will in all likelihood end up even more confused. What is Kubernetes? Wikipedia says that it is "...an open-source container orchestration system for automating software deployment…"
But wait…. what is a container orchestration system??
The real problem is a lack of down-to-earth, succinct resources that explain, in regular language, what each concept, technology, and tool mean and how they relate to other such concepts, technologies, and tools. There is a need for setting a context that is so often missing around the multitude of these terms.
To put things in perspective, I am not advocating for recruiters in tech to have a deep understanding of the skills and technologies they are recruiting for. This is especially considering the fact that there are hundreds of these terms and they change, seemingly, by the day.
What I am advocating for is to form a common understanding that would make the whole candidate sourcing process so much better for both the recruiter and the candidate.
Could you imagine how much smoother, more productive, and quite frankly - more delightful the conversation between candidates and recruiters would flow if there was this common basic understanding of concepts, technologies, and tools?
That is why I wrote the following short guide that explains and sets some much needed context around common technical jargon. "Short" because there is a lot more that needs to be covered.
Hopefully, though, this piece is a first step in the right direction and will serve as that much- needed resource for bridging the gap between recruiters and candidates in tech.
Please note that this is not meant to be an exhaustive list. What I have here is a minuscule subset of some common items. If you don't see a particular skill, tool, or technology, please reach out and I will either add it to this list or to future expansions on the topic.
For the technical folks reading this, yes, much of the below is an oversimplification of things. My goal here is to explain these very technical concepts to folks who are non-technical and so I have to take certain liberties with how I do this.
General Concepts
First, we're going to lay down a foundation for a few key concepts that are crucial to understand before we dive into specific tools and technologies. These concepts are
If you want to skip the general concepts, you can jump right ahead to the Terminology.
Programming Languages
These are the technologies used to write software. Think of a programming language as a set of instructions that can be given to a machine in order to execute this or that task. Every single application out there can be boiled down to a series of steps and tasks (albeit oftentimes very long and complex).
There are many different programming languages - each with its own strengths, weaknesses, level of complexity, and nuances. Some languages are considered "lower level" in that they interact more closely with the computer hardware whereas other languages are "higher level" in that they are further removed (abstracted away) from the actual hardware.
Programming languages can typically differ from each other a lot - much like human languages. However, there are in most cases underlying similarities and constructs that are foundational to most programming languages. For example, just like human languages typically have verbs, nouns, adjectives and other common elements, so do programming languages have concepts of loops, conditional statements, and variables. That commonality is defined by a language syntax.
There are programming languages that are very similar to other programming languages where being experienced in one lands itself very well to quickly picking up another.
Although there are hundreds if not thousands of programming languages in existence, there are about 30-40 of them that are the most widely popular in the market.
Some examples of these popular languages are: Java, JavaScript, TypeScript, Rust, Golang (Go), C#, C, C++, Python, Scala, Kotlin, Swift, Objective C
Runtimes
One key point to remember is that there are programming languages and programming runtimes. We use languages to describe what actions the application is going to take and what it is actually going to do. Runtimes, on the other hand, are the software that runs the application we have written in a particular language.
For example, the JVM (Java Virtual Machine) is a runtime. Once you write a program/application in Java, Scala, Kotlin or any other JVM compatible language, that program will run inside of a JVM in order to function. Before it is executed in a runtime, an application is just a blueprint, a recipe for something to happen. The way it can actually happen is by running inside of a runtime that can understand that particular language.
Another popular example is Node.js, which is also a runtime. We use JavaScript or TypeScript to write applications that can be executed inside of the Node.js runtime.
Some popular runtimes are: JVM and Node/Node.js
Databases
Databases are used…well…to store data. The word "database" is sometimes used to mean different things depending on the context it is used within. From a business, end user perspective, folks will often refer to an external view of a system as a database. For example, it is tempting to think of an applicant tracking system (ATS) as a database that stores clients. That's true to an extent. However, an ATS uses an underlying technology to store that information. That underlying technology is what we would typically call a "database" (sometimes also referred to as a datastore).
In essence, a database is software that provides the ability to permanently store data in a meaningful way and that provides ways for the management, organization, and retrieval of that data.
There are many popular vendors of database software - some that have been around for a while and some newcomers in recent years. Technologies such as SQL Server, Oracle Database, MySQL, PostgreSQL, MariaDB, MongoDB, CosmosDB, DynamoDB, Apache Cassandra, CouchbaseDB, CockroachDB are all database products. Some of these database solutions can be grouped together based on what problem space they are targeting. They can be classified under two main types - RDBMS or NoSQL.
RDBMS (Relational Database Management System) / Relational Database/ SQL Database/ Traditional Database
Relational databases have been around for a while and have had the opportunity to significantly mature. "Relational" because they are typically used to store data that has a lot of relationships between different entities.
For example, when we talk about the world of recruiting, there are candidates, hiring managers, teams, companies, payrolls, account managers, recruiters, roles, and so forth. Roles would be associated with teams, candidates, hiring managers, and companies. Candidates would have relationships with payrolls, account managers, companies, teams, etc, etc.
Relational databases are great at managing this type of related data.
All popular relational databases allow you to use SQL (Structured Query Language) for data retrieval. Think of SQL as a kind of language suited for the analysis and retrieval of data from these systems.
Because of the underlying similarity in what problem space these databases solve, the fact that they all leverage SQL, and the similarity in tooling they have, if you have extensively worked with one of these relational databases, it will likely not take you long to ramp up with another.
In other words, a candidate well-experienced with PostgreSQL will likely have a smooth transition to MySQL. The foundation is already there. It's typically just a matter of some technical differences.
NoSQL
NoSQL is a common catch-all description for types of databases that are not meant for relational data in the traditional sense (i.e. data entities with a lot of linear relationships).
NoSQL databases are called "No"-"SQL" because querying them is done using query languages specific to each of these databases instead of the SQL used with RDBMS (although sometimes it can be similar to SQL).
There are different types of NoSQL databases - Document, Wide-Column, Key-Value, Graph, and others. The differences between them are important and are beyond the scope of this piece. Suffice it to say that NoSQL databases are much easier to scale and support large volumes of data than RDBMS.
Examples of these databases are MongoDB, Cassandra, DynamoDB, Neo4j, and there are many others.
There are significant differences between how RDBMS and NoSQL types of databases store, process, and manage data.
This is why using one type of a NoSQL database does not necessarily imply expertise in another type. For instance, MongoDB and Cassandra are both NoSQL databases. However, one is document based and the other is a wide-column store. There are many differences in how these two store data and how that data is queried.
Lastly, there are what's called hybrid databases that have elements of both an RDBMS and NoSQL as well as columnar data stores used mostly for big data.
The Cloud and Cloud Providers
No term has been so widely misused and misunderstood in the past 15 years in the tech industry as that of the "Cloud".
In its simplest and most straightforward meaning, "cloud" refers to a computing environment that runs somewhere else (i.e. not in your datacenter) and that you don't have to manage (someone else does).
There are a number of cloud providers/vendors that are always at competition with one another. The three most popular cloud providers in the North American market are AWS, Microsoft Azure, and Google Cloud (GCP).
There are also IBM Cloud and Oracle Cloud both of which have a small share of the market by comparison. Alibaba and Tencent are two major cloud vendors popular in China. There are others that are more niche and focus on a smaller set of services (Digital Ocean, for example).
To bring this all home, let's say that I want to write an amazing web application in TypeScript to run in a Node.js runtime. There are still a number of things that need to happen before this application can be accessed by an end user.
The Node.js runtime needs to run in an accessible environment. When I was working on it, it might have run on my actual PC/Mac (local machine). In order for you as a user to access it though, it needs to run on a dedicated machine (server) in some environment that is meant for access by the outside world and with support for a large number of users.
Once upon a time, I would typically have to either deploy it on a physical machine in some data center that either belongs to or where space is rented by the company I work for.
Cloud environments are still based on data centers as there has to be a physical machine somewhere that, at the end of the day, runs this application. However, with the cloud, the data center physical infrastructure is now abstracted away under layers of complex software.
The result is that you can now purchase various computing services such as database, runtime, analysis, storage from the cloud provider without worrying about dealing with physical machines.
So that web application I wrote and that needs to run in Node.js, I can now deploy it in a service in the cloud. Once I do that (and configure it appropriately), the application becomes accessible to the user. There are many kinds of these services offered by the different cloud vendors. One of these is Kubernetes (I can either have full control over it or let the cloud provider control it). Another type of solution is a Serverless Function (AWS Lambda, Azure Function App, Google Cloud Function).
This is an oversimplification of things as there are different levels of "cloud" services such as IaaS (Infrastructure as a Service), PaaS (platform as a Service), SaaS (Software as a Service), and others. The point is that we are relegating whole layers of technology for someone else to manage so that we can focus on writing our applications, products, and solutions.
Key Points
Although cloud providers offer different technologies and solutions - the underlying foundations and best practices of what it means to architect, develop, and run software in the cloud are very similar.
Cloud skills are transferable. If you are well familiar with popular AWS services, it will be much easier to become familiar with comparable services in GCP or Azure.
When it comes to specific services in the cloud, the cloud ecosystem in each cloud provider is vast. It is nearly impossible to have any kind of expertise in all of the services that a cloud vendor provides. Rather, it is a lot more likely to become well versed in a particular set of services (in one cloud or across cloud providers).
Certificates - Getting certified in a particular cloud helps bridge gaps in understanding. However, it is not a replacement for real practical experience with said cloud environment.
Terminology
Angular - JavaScript framework for building websites (frontend)
Angular.js - JavaScript framework for building websites (frontend) - mostly deprecated and not to be confused with Angular. Although similar in name, it's a very different framework.
AWS - Amazon Web Services - major cloud provider
Backend - Typically refers to that part of the application that is deployed on a server (in the cloud or otherwise) and which does not have a user interface. Java, Node.js (with JavaScript or TypeScript), Go, Python are some of the programming languages and runtimes used for the backend.
CI/CD - Continuous Integration / Continuous Deployment pipeline. An automated set of processes that help in getting an application actually deployed and running so that they can be used. Setting up and managing CI/CD pipelines is typically in the DevOps field of expertise. Many developers will have experience with setting up and managing CI/CD pipelines though that will likely not constitute the majority of their work.
Cloud - Platform that takes care of managing various computing services that had to be managed by the company otherwise
Containers - Similar in idea to VM/Virtual Machines. Allows for creating many "virtual" environments on a physical machine or number of machines. The technology is different but the idea is that if you manage containers, you most likely know how to manage VMs. Kubernetes is a technology to manage (orchestrate) containers. One popular container technology is Docker.
DevOps - short for Developer Operations - sometimes used to describe a specific role while at other times used to describe a field of expertise. Larger companies will often have a role dedicated to DevOps while at smaller companies software developers/engineers might fulfill that work. In general, there is some overlap between the fields of software development and DevOps (hence Developer-Operations).
Docker - "Container" technology to package software so that it can be easily deployed in different virtual and physical environments. Think zip files. Zipping a bunch of files into one package, allows you to easily transfer and manage them. Same for Docker containers. We use them to package (containerize) software/applications to make it easier to run. There are other container systems that work similarly to Docker (Packer, for example). Docker is one that is probably the most popular.
Event Streaming - Type of technology and methodology for sending data between systems.
Frontend - Typically refers to that part of the application which is user facing. Most likely a web or mobile application. Most often written in JavaScript and using one more of the popular JavaScript/TypeScript frontend frameworks such as React, Vue, Angular, or Svelte. On mobile, there may be a mix of frontend and backend if device-native technologies are used (such as Swift or Objective C for iOS or Java/Kotlin for Android)
Full Stack Developer - Frequently misused, abused, and misinterpreted - most organizations understand this to be a developer that can work with both the frontend and backend. In practice, even if they have an ability to work with both, a developer will often focus on either the backend or the frontend within a particular project or role.
GCP - Google Cloud Platform - major cloud provider
Java - One of the most popular programming languages. Runs inside of a JVM (Java Virtual Machine). When companies ask for knowledge of "Java", they typically refer to knowledge of both Java as a programming language as well as the knowledge of popular and widespread Java ecosystem and frameworks such as Spring Boot.
JavaScript - No relationship whatsoever to Java even though it literally includes "Java" in its name. The reason it is named like that is due to historical reasons going into the decision making that went into naming JavaScript. JavaScript applications can run both on the frontend (in the browser) or on the backend (Node.js, Deno)
JVM - Java Virtual Machine - Runtime for Java and some other languages (Groovy, Scala, Kotlin being the most popular)
Kafka - Event streaming framework/technology. Kafka itself is open source but there are implementations of it by different vendors.
Kubernetes - Container orchestration platform - technology to manage many Docker (at least used to be based on Docker but now based on a different type of underlying container technology) containers
MariaDB - Open source RDBMS - based on MySQL
Microsoft Azure - Major cloud provider
MySQL - RDBMS offered by Oracle
Node/Node.js - Runtime for JavaScript on the server/backend. Sometimes Node.js used in the context of a programming language although technically it is a runtime.
NoSQL - Databases that do not use the relational model and are typically not queried with SQL
Oracle Database - Flagship RDBMS from Oracle
PostgreSQL - Open source RDBMS
RDBMS - Relational databases - experience with one database, lands itself nicely to other relational databases
React - JavaScript framework for building websites (frontend)
React Native - Extension of React for building cross-platform mobile applications. If one knows React Native, one knows how to work with React.
Serverless - Relatively new paradigm in computing. Refers to a way of running applications in a way where most of the heavy lifting of managing infrastructure is taken care of by the cloud environment thus allowing the development team to focus on their core competency of building their business applications.
Note that "Serverless" can sometimes refer to a very specific framework from a company under the same name. The serverless framework is used to automate the deployment of serverless applications.
Spring Boot - Framework for Java. If a candidate has experience with Spring Boot, that means they have experience with Java.
SQL - Structured Query Language - used to query data in relational databases. If a candidate has worked with any relational database, they've worked with SQL.
SQL Server - Flagship RDBMS from Microsoft
Svelte - One of the newest front-end frameworks. Rapidly rising in popularity.
TypeScript - Think of it as an extension to JavaScript (technicall, it is a superset). TypeScript brings some very useful features from other languages into JavaScript. Typically, an experienced JavaScript developer would be able to ramp up with Typescript fairly quickly - especially if they have background in other object oriented languages such as Java. Experience with Typescript typically means experience with JavaScript as well.
VM/Virtual Machines - Technology that allows to run many "virtual" servers/environments on top of one physical machine or spread across a number of physical machines/servers/computers.
Vue.js - JavaScript framework for building websites (frontend). Has similarities to both Angular and React.
Kommentare